The Last Mile of Development: What AI Actually Changed About Shipping Software

Four months. Team of eight. That was the initial estimate for building an AI-powered document generation system for one of our customer’s Quality Control team. The scope was complex—identify which documents needed updates, determine the correct sections to modify, ensure compliance standards were met. Standard enterprise software development timeline.

We delivered it in four weeks with three people.

Before you dismiss this as another inflated AI success story, understand what actually happened. AI didn’t magically write production-ready code. Our team didn’t suddenly become 10x engineers. What changed was something more fundamental: how we worked, what we focused on, and how we collaborated with the business.

That project, along with a recent code migration where AI cut initial implementation time by 70%, taught me something the current discourse on AI coding tools misses entirely. AI has genuinely transformed the first 70% of software development. But the last mile—the gap between code that works and code that ships reliably—remains fundamentally human work. More importantly, that last mile now demands a completely different way of working together.

The code migration project made the pattern clear. We were moving a legacy system to a modern architecture—exactly the kind of tedious, pattern-heavy work that AI should excel at. And it did. The initial overhead—setting up project structure, scaffolding components, converting standard patterns— happened 70% faster than our historical baseline. Claude Code and Cursor handled the repetitive heavy lifting while we focused on design decisions.

Then we hit the complex scenarios. 

Edge cases involving legacy data formats. Integration points with third-party systems that behaved unpredictably. Performance optimizations that required understanding system behavior under load. Security considerations for handling sensitive data. This work didn’t accelerate. AI couldn’t meaningfully help because these problems required deep contextual knowledge that wasn’t in any training dataset—it lived in our heads, our documentation, and our production war stories.

This matches what research from Microsoft and GitHub found: developers using Copilot completed certain tasks 55% faster than control groups. The key word is “certain tasks.” Addy Osmani, who leads Chrome Developer Experience at Google, calls this “the 70% problem”: AI can complete roughly 70% of a coding task, but the remaining 30%—edge cases, security, production readiness—requires genuine engineering knowledge.

That 70/30 split isn’t a limitation to overcome with the next model release. It’s a feature that reveals what actually matters in software development. AI crushes the scaffolding phase. Humans handle everything that makes software work in the real world.

The speed gains are real, but they create a new problem. Martin Fowler, Chief Scientist at ThoughtWorks, captures it perfectly: You have to treat every AI-generated code block as a pull request from “a rather dodgy collaborator who’s very productive in the lines-of-code sense of productivity, but you know you can’t trust a thing that they’re doing“. The research backs this up with uncomfortable clarity. Researchers at NYU found that approximately 40% of Copilot-generated code contained security vulnerabilities when tested against standard weakness criteria.

These aren’t bugs to fix in the next version. They’re inherent to how generative AI works—pattern matching against training data produces code that works in isolation but fails to integrate with existing systems, established conventions, and organizational constraints.

What surprised me most about some of the acceleration we saw in our projects wasn’t the security reviews or code quality issues—we expected those. It was how the entire relationship with business stakeholders transformed. In traditional development, we’d spend weeks explaining what we planned to build, defending architectural choices, managing expectations about timelines. Stakeholders would nod along, trusting we knew what we were doing, then see results months later.

With AI-accelerated development, that pattern broke completely. 

In the QC document generation project, we had working prototypes within days. Not mockups or demos—actual functional code processing real documents. Suddenly, conversations weren’t about what we’d build conceptually. They were about what changed since yesterday. Business users could give feedback on actual behavior, not specifications. Issues that would have festered for weeks in the old model got caught and fixed within 48-hour cycles.

This shift from “explaining intentions” to “showing progress” compressed feedback loops from weeks to days. It sounds great—and it is—but it requires something most engineering teams aren’t prepared for: developers who understand business functionality deeply enough to make architectural decisions at conversation speed.

Here’s what made three people deliver faster than a planned team of eight: we weren’t just writing code anymore. We were orchestrating AI output while maintaining continuous dialogue with the business.

Daily visibility replaced conceptual discussions. Every morning, the QC team lead would review what had changed overnight. Not in a formal demo—she’d just pull up the system and test workflows. “This document detection works, but it’s flagging false positives on amendments.” We’d adjust the logic, push an update, and she’d retest by afternoon. This happened daily, sometimes multiple times per day.

Traditional software development doesn’t work this way. You plan, you build, you integrate, you test, you demo. Feedback cycles measured in weeks. When AI handles the initial implementation overhead, those barriers collapse. You can show meaningful progress day-over-day, but only if developers understand what “meaningful” means to the business.

Developers became business translators. In the code migration, we couldn’t just tell Claude Code “migrate this component.” We had to understand what the component did for users, which behaviors were intentional versus bugs we’d worked around, what performance characteristics mattered, which integrations were critical versus vestigial. AI could rewrite the code quickly; we had to ensure we preserved the right behaviors and improved the right things.

The QC project demanded even more. Our team needed to understand document compliance workflows, regulatory requirements, and how quality analysts actually used these systems. We weren’t translating business requirements into technical specs—that’s the old model. We were making real-time judgment calls about what AI-generated solutions would actually work in production.

The tight feedback loop became the competitive advantage. Developers who understand the problem domain, can evaluate AI output quickly, and know when to override versus accept suggestions. BCG’s research found mid-level developers reap the greatest benefits from AI tools— enough experience to evaluate and refine generated code, but not so much that AI offers only marginal improvements. That matches what I’ve seen: senior judgment combined with AI acceleration creates the real multiplier effect.

The cautionary data matters too. A randomized controlled trial from METR found that experienced developers working on codebases they knew intimately completed tasks 19% slower with AI assistance, despite predicting beforehand that AI would speed them up by 24%. The overhead of prompting, evaluating, and context-switching exceeded the benefits.

The lesson isn’t “AI tools are bad.” It’s “context determines value.” In our projects, we were building new systems and migrating legacy code—exactly the scenarios where AI’s pattern-matching strengths shine. Developers working deep in complex codebases they’ve maintained for years face different trade-offs.

What doesn’t change, even at AI-accelerated pace? The fundamentals of production software.

Architectural coherence. Kent Beck, creator of Extreme Programming, observes that today’s AI assistants lack taste. AI excels at adding features but struggles with refactoring for simplicity. Left unchecked, complexity accumulates until the system becomes unmaintainable—and ironically, until AI tools become less helpful because they can’t navigate the mess they helped create.

We had to resist the temptation to just keep asking AI to “add this feature” and instead regularly refactor generated code into clean, maintainable modules. That judgment—knowing when to consolidate, when to abstract, when to stop adding—comes from experience, not training data.

Security and integration review. Every AI-generated component in our code migration went through security review. Every integration point got tested against edge cases. Every performance assumption got validated under load. AI accelerated initial implementation; human expertise ensured it actually worked in production.

Domain understanding. Business team’s continuous involvement and validation was crucial not because we couldn’t write code—AI helped with that—but because only they knew what “correct” looked like for document compliance workflows. Our job was translating their expertise into working software, rapidly.

What does accelerate is feedback and iteration. Prototypes reach business users in days instead of weeks. Changes happen at conversation speed. The bottleneck shifts from “how fast can we write code” to “how deeply do we understand the problem we’re solving.”

This is why Sarah Drasner, Senior Director of Engineering at Google, argues that industry discourse misses the point: “Folks across the industry are paying too much attention to early greenfield, vibe code stages of the developer journey. Crucial work in large systems happens extremely well with experienced engineers—folks who can think in complex systems, steer, debug and leverage AI the deepest.”

AI hasn’t replaced developers. It’s redefined what developer expertise means.

The old model: write code, explain what you built, ship after extensive testing. The new model: orchestrate AI output, show daily progress, validate continuously with business users. Both require technical skill. The new model additionally demands business fluency and judgment under pressure.

McKinsey found that top-performing organizations achieve 16-30% productivity improvements with AI coding tools, but only with what they call a “complete overhaul of processes, roles, and ways of working.” Bain’s research found similar patterns: typical gains hover around 10-15%, while organizations achieving 25-30% gains pair AI tools with end-to-end process transformation.

Our projects succeeded not because AI wrote better code than humans, but because we restructured how we worked. Daily visibility. Continuous validation. Developers who understood both the technical architecture and the business problem. Tight feedback loops that caught issues in hours, not sprints.

This is what “different” actually looks like: developers who can move at AI speed while maintaining human judgment. Teams that can show progress day-over-day and adjust based on real user feedback. Organizations that recognize the bottleneck has shifted from coding speed to domain understanding and architectural discipline.

Kelsey Hightower, former Distinguished Engineer at Google, frames the opportunity clearly: AI tools present a chance for developers to evolve. “If you were a developer, you could have gotten really far in your career with no empathy, no customer service, lack of communication… That’s over.”

The last mile still requires human expertise. But that expertise now operates at a fundamentally different pace, with different expectations, and different skills. The developers and teams who master this hybrid approach—fast prototyping combined with deep domain knowledge and architectural discipline—will dramatically outpace those who don’t.

The last mile has become the most crucial—it demands more from the humans who walk it.