I'll be honest with you: for a long time, I didn't buy it.
The AI hype in software development felt exactly like that — hype. I was relishing in the stories of how companies were switching to AI and falling on their faces--like McDonald's hiring portal going into production with a backdoor username password set to admin/admin. I always said that AI was little more than a massive regression function with access to all the internet as its training data.
Then something changed. Not overnight, and not because of a single headline. But over the last six to nine months, the tools got better — significantly better — and the gap between what AI promised and what it actually delivered started to close in ways I couldn't ignore. I remember just over a year ago I called out a developer who commited code which had some emojis in the comments, making it rather obvious that there was AI being used to write the code. Today though, I'm encouraging that same developer, and all of my teams, to use AI more aggressively.
I'm not writing this to tell you AI is perfect. I'm writing this because it doesn't need to be.
The Quality Floor Has Risen
Here's the thing nobody wants to say out loud: most of the software out there doesn't need to be perfect. If it did most of what is in production wouldn't be. It needs to be suitable. It needs to work, meet requirements, not having blocking defects and be maintainable. There's a massive market for "good enough done fast" and a surprisingly small one for "flawless but took three times as long."
What's changed recently is that the tooling, like context engines powering AI development tools have reached a tipping point. These aren't the autocomplete suggestions of two years ago. Modern AI agents can take in the full scope of what you're building — your architecture, your patterns, your intent — and produce entire, fully functional applications. Are they perfect? No. But they're suitable, and suitable is a baseline that a lot of teams would be thrilled to start from rather than build toward.
For business leaders reading this, think of it this way: if AI can get your development team 80% of the way to a working feature in a fraction of the time, the remaining 20% of refinement becomes a much more valuable use of your team's expertise. That's not a threat to your developers. That's a force multiplier.
AI Doesn't Need Stack Overflow — And That Changed Everything
This was my biggest concern for the longest time, and I suspect it's one that resonates with a lot of technical leaders.
My fear was straightforward: AI models were trained on mountains of existing content — Stack Overflow posts, documentation, open-source code. They were brilliant with .NET 8 because the internet is full of .NET 8 content. But what happens when .NET 10 or 11 comes along and there's almost nothing for the models to learn from? I believed we were approaching an apex — that AI tools would plateau because they'd run out of human-generated knowledge to absorb.
I was wrong, and I proved it to myself.
At Fragomen, we developed a custom framework for form generation that we call Fragomen Markup Language — FML for short. This isn't something that exists on Stack Overflow. There are no blog posts about it, no GitHub repos, no training data. It's a proprietary framework with its own custom properties, nomenclature, and structure.
When I started working with AI agents on FML, I expected them to struggle. Instead, by providing a short description of the type of form we wanted to generate, the AI was able to produce character-perfect FML files. It understood the framework's custom conventions, respected its constraints, and in some cases demonstrated a better working grasp of the system than I had myself — and I built it.
That experience started to reframe the entire conversation for me. These tools aren't just pattern-matching against a training set anymore. They're reasoning about structure, interpreting intent, and adapting to novel systems. Anthropic recently ran an experiment where an AI agent built a functional C compiler without human interference. We're well past the parlor trick stage.
The Tools Are Finally Catching Up to the Promise
There's a third shift happening that deserves attention, especially from people who tried AI development tools early on and came away unimpressed.
I'll admit it — I thought chat-based coding agents were the worst possible interface for development work. Copilot chat felt like throwing rocks at a problem and hoping something landed. You'd describe what you wanted in plain language, get back something vaguely related, manually correct it, and wonder if you'd have been faster just writing it yourself. A lot of us were.
But the frameworks for AI-driven development are evolving rapidly. We've gone from throwing rocks at a problemto carefully crafting razor-sharp arrows which are able to hit they issues we are targeting with percision. The interfaces are more sophisticated, the workflows more intentional, and the degree of precision you can achieve when directing an AI agent is genuinely impressive. Agentic coding workflows, structured prompt patterns, context-aware scaffolding — these aren't future-state concepts. They're here now, and they're improving at a pace that should get your attention.
For anyone who wrote off AI development tools after an underwhelming experience a year or two ago it's time to look again and not just with $10 a month copilot subscritions. You may need to invest what at first feel like eye water amounts compared to other software tools. But spending $200 or $300 a month for something that improves productivity by even 10% is worth it -- and when used right that is the low end of the productivity gains I'm seeing.
The Real Challenge Ahead: Rethinking How We Work
Now, here's the part I find most interesting — and most underexplored.
If you accept that AI is genuinely capable of producing suitable, functional code at speed and scale, then the next question isn't about the AI. It's about us. Specifically, it's about how we change the Software Development Lifecycle to take full advantage of what these tools offer without creating new problems in the process.
There are two tensions I see playing out right now.
The first is a quality and accountability challenge. As AI generates more of our code, we need guardrails to ensure that people aren't releasing code they don't understand. The productivity gains evaporate quickly if you're shipping black-box features that nobody on your team can debug, maintain, or extend. Adopting AI-driven development responsibly means pairing speed with comprehension — and that's an organizational discipline, not a technical one.
The second tension is more subtle, and I think it's the one most teams will struggle with. For years — entire careers, in many cases — we've fought for smaller, more granular work items. Break it down. Make tickets atomic. Reduce scope. That instinct served us well in a world where every line of code was written by a human who needed clear, bounded context.
But AI-driven development may require us to rethink that approach entirely. When an AI agent can produce a complete, integrated feature in one pass, putting that output through a full SDLC built for tiny, incremental tickets creates enormous busywork. You end up with process overhead that actively destroys the productivity gains the AI just delivered. We need to have a serious conversation about what right-sized work looks like in an AI-augmented world — and the answer is probably very different from what we've been practicing.
The Bottom Line
I spent a long time being skeptical, and I don't regret that. Healthy skepticism protects teams from chasing trends that don't deliver. But the best skeptics know when to update their priors, and that time is now.
AI in software development isn't a silver bullet, and anyone selling it as one is doing you a disservice. What it is, right now, today, is a genuinely capable tool that has crossed the threshold from novelty to utility. The quality is there. The adaptability is there. The frameworks to use it effectively are emerging fast.
The question isn't whether AI will change software development. It already has. The question is whether your team and your processes are ready to change with it.