Start with the Right AI Model

Early Release: The following content is an early preview and should be considered a work in progress. Information may be missing or incomplete until the final release

The evolution of AI-assisted development didn’t happen overnight. If we rewind a bit, the journey really begins in the familiar territory of the IDE, the singular place that developers have been writing code for decades. In the early days of developer assistance, the most sophisticated help you could get was autocomplete. Type a few characters and your IDE would suggest how to finish a variable name or complete a function call. It was simple, predictable, and worked pretty well for the time.

Then a few years ago, the chat interface found its way into the IDE. This turned out to be more of a transitional moment than the destination. Developers could finally ask questions right in the sidebar of their IDE like, “How do I sort this array?” or “What’s the best way to split a complex string in Java?”. Sure enough, the AI model would respond with an explanation and some example code. It was like having a (very) knowledgeable colleague available around the clock, ready to help debug or explain a tricky concept.

But just as quickly as we entered this new phase of development, the next evolution was right around the corner. AI got smarter and more capable in short order and it quickly paved the way for true coding agents.

In this current generation of coding agents we are seeing explosive consumption of different models for coding tasks. Vibe coding sort of rocked the world overnight with the claim that “everyone is now a developer”. But just because AI can write code, doesn’t mean that it’s efficient or secure. Additionally, we still have plenty of runway for advancement…from fully agentic coding workflows to true software engineering through AI (we aren’t there yet).

Despite the media hype, developers aren’t becoming obsolete. In fact, the role is evolving into its next generation as well. But to ensure that this evolution is a success we can not continue to do “more of the same”, it’s time to completely rethink the developer experience in the age of AI. This next developer experience 3.0 starts by choosing the right (AI) model.

Choosing Your Model Strategy

So let’s talk about what it actually means to choose the right AI model for development tasks. This is where things get a bit philosophical, because there are essentially two competing schools of thought, and organizations tend to fall pretty firmly into one camp or the other.

The first camp believes in developer freedom. Their philosophy is simple; give developers whatever tools they want to work with. If someone on your team swears by a particular model because it understands their coding style or excels at the specific language they’re working in, let them use it. This approach prioritizes productivity and developer happiness, trusting that skilled engineers will make smart choices about their tools.

The second camp takes the opposite view; strict controls with only select models approved for use. This isn’t about being heavy-handed for the sake of it, it’s usually driven by legitimate concerns about security, compliance, and maintainability. After all, when you’re dealing with enterprise code, you can’t just let everyone connect to random AI services that might be ingesting your proprietary code and using it for training purposes.

While experimentation is good and it’s important to provide some flexibility to developers directly…AI is still in its infancy and we need to be mindful of that. Maybe one or two models is a good starting point when it comes to code generation. However that doesn’t mean that organizations are locked into that same model for other (non-code based) workflows.

The Practical Starting Point

For most enterprises, the decision about which AI models to adopt doesn’t start from scratch. There’s already infrastructure in place, existing vendor relationships, and, let’s be real here, budget allocations were set months ago. This reality tends to shape the path of least resistance.

Most organizations tend to have an existing contract already with Microsoft or Google for their productivity tools. Maybe you’re using Microsoft 365 for email or Google Docs for collaboration. When you’re already paying for these ecosystems, extending that relationship to include their AI models becomes the logical first step. It’s easier to get budget approval, the procurement process is streamlined, and there’s often institutional knowledge about how to work with these vendors.

This is why you’ll often see Microsoft’s Copilot or Google’s Gemini emerge as the starting point for many enterprises. They’re not necessarily chosen because they’re the absolute best option for every use case, though they’re both certainly capable models, but because they represent the path of least friction. And you know what? That’s not a bad thing. Getting started with AI is more important than agonizing over finding the theoretically perfect solution.

That said, there’s another player that deserves serious consideration, especially when it comes to software development specifically; Anthropic’s Claude. Claude Code, in particular, has become remarkably popular in development circles. It has a well-earned reputation for understanding complex codebases, providing thoughtful explanations, and generating code that’s not just functional but actually well-structured and maintainable. It does often come at a premium cost, but many developers genuinely prefer working with Claude for coding tasks, and that preference is worth paying attention to.

Getting Models Into Developer Hands

Once you’ve selected which model(s) will be used, the next step is making them accessible to developers in the environments where they work. This might sound straightforward, but it’s where things can get surprisingly complicated. If you think back to the shift left conversation from chapter one, one of the main struggles was around unified IDE support. With AI, and the recent rapid rise of MCP, models can be plugged into many different places within the developer experience.

Want to get started with a traditional IDE like Visual Studio Code? No problem. Looking for something more cutting edge like Cursor or Windsurf? Those are supported too. Still writing code in the terminal? There is a path forward for you as well. The great news about all of this is that there are so many ways you can empower developers, but you have to be intentional about it.

Designing a (modern) developer experience is all about finding balance between flexibility and security. You want developers to move quickly and ship code faster. But we want to balance that with compliance requirements and a well defined attack surface. While choosing an AI model might have been shaped by existing contracts or relationships, it’s pretty common for organizations to be more flexible when it comes to IDE choice…even across different teams.

What Actually Matters

Here’s something important to keep in mind as you navigate all these decisions; the specific combination of model and IDE is actually less important than the outcomes you’re trying to achieve. At the end of the day, what matters is whether your teams are shipping secure code more easily and with fewer issues.

Think about what success looks like. It’s not about being able to say “we use the newest model” or “we’ve integrated AI into every possible tool”. Success is when your developers can move faster without sacrificing quality or security. It’s when the number of bugs making it to production decreases. It’s when code reviews become more focused on architecture and business logic rather than catching syntax errors and style violations. It’s when your team can actually get home at a reasonable hour instead of grinding through repetitive tasks late into the evening.

Technology is just a means to an end. The end is better code, delivered more efficiently, with less developer burnout and security issues along the way.

Language Considerations

Before we wrap up this section, there’s one more consideration that I’d like to revisit (from the last chapter); not all programming languages are created equal when it comes to coding agents.

Most coding agents are heavily trained and centered around modern programming languages. If you’re working in Python, JavaScript, TypeScript, Go, or Rust, you’re probably in great shape. These languages have massive amounts of publicly available code repositories on the internet, which means the AI models have had extensive training data to learn from. The assistance you’ll get is detailed, accurate, and often genuinely impressive.

But most enterprises have a large pool of languages in the mix because they’ve been in business for a long time. When it comes to more traditional languages like C or C++, coding agents still have a ways to go. They’re not useless by any means, but you’re not going to get the same level of sophisticated assistance that you would with more modern languages.

This isn’t necessarily a dealbreaker, but it is something to set expectations around. If a significant portion of your codebase is in older languages, AI will be helpful but not transformative. On the flip side, if you’re building new systems or gradually refactoring your codebase, the benefits of AI become more real.

The landscape of AI-powered development is still evolving rapidly. What’s true today might be outdated in six months. But the fundamental principle remains, start with the right model for your organization’s needs, make it accessible to your developers in the ways they actually work, focus on outcomes rather than technology for its own sake, and set realistic expectations based on your specific technical stack. Get those pieces right, and you’ll have laid a solid foundation for what will become the developer experience 3.0.