AI coding agents have come a long way in the past 24 months, dramatically changing how quickly we can build software. Tasks that once took developers days or weeks can increasingly be completed in hours, and the development phase of the software development lifecycle (SDLC) is starting to shrink as a result.

But faster development doesn't necessarily mean faster delivery. As the time required to write code shrinks, existing bottlenecks are shifting and new ones are emerging both upstream and downstream. AI can do magical things, but organizations still need to figure out what they want to build, make decisions about how it should work, test and validate the results, get it safely into production, and support it once it's there.

In this article, we'll explore the human side of AI-powered development and why the ability to build software faster makes clear requirements, good decisions, engineering discipline, and long-term ownership more important than ever.

Everyone Wants to Go Faster

The appeal of AI-powered development is obvious. If we can dramatically reduce the amount of time it takes to write code, then we should be able to deliver software faster and at a lower cost. There's no denying this. The problem is that coding is only one part of what it takes to deliver enterprise-grade software solutions.

It's easy to look at the productivity gains we're seeing with AI coding agents and assume they translate directly into shorter project timelines. If something that used to take a developer a week can now be done in a day, why shouldn't the entire project move five times faster?

Figure 1: Fundamental Law of Development - Garbage Requirements In, Garbage Solutions Out

In practice, it doesn't quite work that way. Before we build anything, we still have to figure out what we're building and how it should work. Once it's built, we have to test it, secure it, deploy it, support it, and continue to evolve it over time.

AI can help accelerate many of those activities too, and we'll get into that later. But these phases of the SDLC don't all compress at the same rate. As coding gets faster, the work surrounding it becomes a larger percentage of the overall effort. And, more human involvement/oversight is needed.

That's why the conversation around AI-powered development needs to be bigger than just developer productivity. If we really want to deliver software faster and cheaper, we have to look at what happens to the rest of the SDLC when the build phase starts to shrink.

The Bottleneck(s) Are Moving

Anthropic recently published their AI-native SDLC playbook that illustrates just how much the traditional development lifecycle is starting to change. One of the biggest shifts is fairly obvious: as AI takes on more of the implementation work, the build phase gets considerably shorter. However, as you can see in Figure 2 below, the rest of the lifecycle doesn't necessarily shrink with it.

Figure 2: Before and After - The AI-Native SDLC (from Anthropic)

Some of the bottlenecks simply move. For example, if an AI coding agent can produce in a day what previously took a development team a week, waiting three days for someone to answer a question suddenly matters a lot more. So does waiting for requirements to be clarified, a design to be approved, test results to be reviewed, or a production release to be scheduled.

Other bottlenecks are emerging because of the speed of the build cycle. AI can generate a lot of software very quickly, which means teams have more output to review, validate, secure, deploy, and eventually maintain. Without changing the processes around development, we run the risk of moving faster in one part of the lifecycle only to create traffic jams elsewhere.

This fundamentally changes the productivity equation. Getting more code out of a developer isn't necessarily the same thing as getting more software into production. To realize the full benefit of AI-powered development, the rest of the organization has to adapt accordingly to keep pace.

Prompt and Pray Isn’t a Development Strategy

One of the more interesting misconceptions we've encountered with AI-powered development is the idea that requirements somehow become less important. Somehow, people have gotten it into their heads that you can just start with a basic idea, explain it to an AI coding agent, and let the model figure out the rest.

That approach can work surprisingly well for a prototype. However, it's a much riskier approach when you're building software that needs to support a mission critical business processes.

We've seen this firsthand with customers who come to us with an idea they believe is ready to build. But once we start asking basic questions about how the application should work, it becomes clear that there's still quite a bit to figure out. Who will use it? What does the process look like? What happens when something doesn't follow the happy path? What business rules apply? Where does the data come from? Who should have access to it?

Of course, AI can help answer some of those questions, too. We can use it to conduct discovery workshops, identify gaps, propose requirements, create prototypes, and turn what it learns into increasingly detailed specifications. In fact, this is one of the areas where AI could make the requirements process considerably faster and more iterative than it has been in the past.

Still, at the end of the day, someone still has to make the decisions.

AI can propose how a process should work, but the business needs to decide whether that's actually how it should work. It can generate a detailed specification from a handful of conversations, but someone needs to validate that specification before we start treating it as the source of truth.

Ultimately, the requirements gathering process is going to change and that's probably a good thing. Indeed, Anthropic’s AI-native SDLC model provides an interesting perspective into what that looks like. What we shouldn't do is confuse changing the process with eliminating it. Giving an AI agent a vague idea and hoping it fills in the blanks correctly isn't a shortcut to better software. It's a recipe for disaster.

From Working Code to Working Software

Getting code to work on your local machine has never been the same thing as getting software ready for production. As AI makes the first part easier, that distinction becomes even more important.

Testing is a good example. AI can generate unit tests, create test cases, identify edge cases, automate regression testing, and even help diagnose and fix the issues it finds. That's a significant opportunity to improve both the speed and coverage of testing.

But automated test coverage isn't the same thing as confidence. Human beings still need to determine whether we're testing the right things. Business users need to validate that the solution actually supports the process it was designed for. Security, performance, integrations, accessibility, and the user experience all need to be considered. A passing test suite doesn't necessarily tell you whether people can actually use the software to do their jobs.

The same principles apply whenever it's time to deploy our solutions to production. AI coding agents can help generate infrastructure as code (IaC), configure deployment pipelines, automate security checks, produce documentation, and remove a lot of the manual effort that traditionally surrounds a release. But enterprise software still needs appropriate environments, access controls, monitoring, rollback plans, and production support. For the foreseeable future, this will require human oversight.

None of this means we should slow AI-powered development down by wrapping it in layers of manual approvals. Quite the opposite. If development is going to move faster, the practices around testing, security, and deployment need to evolve with it.

Again, the goal isn't simply to produce working code faster. It's to build the processes and guardrails that allow us to turn that code into production-ready software at the same pace.

The Long Tail of Enterprise Software

One of the less obvious consequences of AI-powered development is that we're probably going to build more software. A LOT more.

Applications that might not have justified the time or cost of a traditional development project have suddenly become much easier to justify when the initial build takes days or weeks instead of months. From a business perspective, that’s wonderful news because it opens the door to solving smaller problems and addressing opportunities that may have sat in the backlog for years.

However, every application we create comes with a long tail. Once software reaches production, someone has to own it. Dependencies need to be updated. Security vulnerabilities need to be addressed. Integrations and APIs change. Business requirements evolve. Users find new edge cases. Performance needs to be monitored. Enhancements need to be made. And eventually, someone has to decide when it's time to modernize or retire the application altogether.

AI can help here too. We can (and should) expect agents to take on more of the routine work associated with monitoring, troubleshooting, documentation, upgrades, refactoring, and ongoing maintenance. That could significantly reduce the cost of owning custom software over time.

Figure 3: Example of An AI-Led SDLC Process with Microsoft Azure and GitHub

But cheaper maintenance doesn't eliminate the need for ownership and discipline. If AI allows an organization to build five times as much software, even dramatically more efficient maintenance practices may struggle to keep up. Without some thought about ownership, standards, governance, and lifecycle management, today's development acceleration could easily become tomorrow's application sprawl.

The real economics of AI-powered development therefore can't stop with the cost of the initial build. We also have to consider what it will take to operate, maintain, evolve, and eventually retire everything we're now able to create.

And that investment can't be measured in tokens alone. Getting the full benefit of AI-powered development also requires an investment in the people and processes surrounding it. Organizations will need to rethink workflows that were designed around a much slower development lifecycle, establish smarter processes for testing and release management, revisit governance strategies, and make sure people have the skills and authority to make decisions at the pace AI enables.

The technology may make software dramatically cheaper to produce and maintain. But realizing those savings will require some very human work to rethink how we build, govern, and take care of it.

Closing Thoughts

Despite the doom and gloom you read and hear about in the news, there's a lot to be excited about with AI-powered development. The ability to build software faster and at a lower cost opens up opportunities that simply weren't practical when every new application required months of development and a significant budget.

But faster coding doesn't automatically create a faster and more efficient organization.

As the build phase continues to shrink, the work surrounding it becomes more visible. We still have to decide what to build, translate ideas into clear requirements, validate what AI produces, get it safely into production, and take responsibility for it over the long term. AI can help with every one of those activities, but it doesn't eliminate the need for judgment, ownership, and discipline.

That's why I think the human side of AI-powered development deserves just as much attention as the technology. Organizations that want to take full advantage of this shift will need to invest in more than models, agents, and tokens. They'll also need to rethink how their people make decisions, how their processes work, and how quickly the rest of the organization can move when development is no longer the slowest part of the equation.