I watched Claude Code generate in 30 seconds what would have taken me more than an hour. A complete set of integration tests, all structurally sound, all following the project’s conventions. And yet, on another project a few weeks later, a feature I could build in a day sat in review for a week, got reworked, sat in review again, and barely shipped ten weeks after the first line of code was written.
This isn’t an article about whether AI coding tools work. They do. I’ve used Claude Code, GitHub Copilot and Cursor across three real projects over the past year: a Java claims management system, a JavaScript/TypeScript personal assistant, and a Python multi-agent system built on LangGraph and A2A. The tools are genuinely impressive, and I’ll show you exactly how.
But the industry narrative conflates “coding faster” with “delivering faster,” and my experience across these three projects tells a different story.
Across three projects, both conditions held on exactly one. In this first part of a three-part series, I explore the AI-augmented SDLC ecosystem — what the tools can do and where they genuinely shine. In Part 2, we look at the bottlenecks that prevent faster coding from becoming faster delivery. In Part 3, we pull together the pattern and discuss what actually makes AI-augmented SDLC work.
The Three Projects
To ground this in specifics, here’s the landscape:
| Claims Management | Personal Assistant | A2A Multi-Agent System | |
|---|---|---|---|
| Language | Java | JS/TS | Python / LangGraph |
| Greenfield? | Greenfield | Greenfield | Brownfield |
| Requirements | Clear spec | Informal, prototype-driven | Informal + high uncertainty |
| My role | Solo developer | Architect / tech lead | Developer on a team |
| Coding as % of time | ~50% | ~10-20% | ~10-15% |
| AI tools | Claude Code + Copilot | Claude Code + Copilot | Claude Code + Copilot |
That row, coding as a percentage of total time, is the number that matters most. Hold it in your mind as you read.
The Tools: What AI Coding Assistants Can Do
Before getting into where delivery breaks down, I want to be clear: these tools represent a genuine step change. This isn’t an anti-AI article. It’s a calibration.
Both Claude Code and Copilot handle complex, multi-step instructions with remarkable facility across Java, JS/TS, and Python. They write code, refactor code, explain code, and, critically, they integrate with the broader development ecosystem through MCP (Model Context Protocol) servers.
On these projects, MCP integrations included:
- LangChain docs for live lookups of the latest LangGraph features, which was essential given how fast the API was moving and how prone the models are to hallucinating outdated patterns
- Atlassian for creating and updating stories and tasks without leaving the coding flow
- Chrome DevTools for driving LangGraph Studio’s UI to run multi-step conversational tests from natural language descriptions
Beyond MCP, the tools excel at pattern discovery: finding how a problem like OAuth integration was already solved elsewhere in the codebase before implementing it fresh. They enforce consistency and prevent duplication in ways that grep and institutional memory never could.
The code review workflow deserves special mention: paste a screenshot of review comments, the AI evaluates their validity, and implements fixes where warranted. This turned a context-switching tax into a fluid process.
Where Claude Code Had an Edge
Claude Code offered constructs that Copilot seemed to lack at the time of writing (Copilot’s January 2026 release may close some gaps):
Skills are markdown files encoding domain expertise that persist across sessions. On the Java project, I created six testing skills: unit tests, Testcontainers, Spring REST Docs, ArchUnit, BDD with Cucumber and Playwright, and JMH with Gatling. Each skill codified the conventions and patterns a senior engineer would bring to that specific testing type: not just “write a test,” but “write a test the way this project writes tests.” Skills live in the project repository, so any developer using Claude Code gets the same quality guardrails.
Subagents allow spawning background agents for parallel, isolated work. On the Java project, I built three custom agents:
- A coverage analyst that scanned the codebase for meaningful test gaps: not line coverage metrics, but actual untested behavior prioritized by cyclomatic complexity.
- A test scaffolder that set up infrastructure: Testcontainers base classes, Maven source sets, plugin configurations.
- A database migration test writer that read all Liquibase changesets and generated a test for each one.
These ran as background tasks while I continued working in the foreground. The analyst produced a prioritized report: 14 untested service methods, 8 undocumented endpoints, 3 untested native queries, 2 architecture violations. Subagents handled the scale problem without exhausting the context window. Each operated in isolation with its own context.
Plan mode switches to exploration and planning before committing to code. I used it across all three projects to evaluate multiple approaches in parallel, which naturally triggered subagent spawning. It prevented premature implementation, which is ironic given that premature implementation turned out to be a recurring problem on the other projects.
Hooks played a supporting role, triggering actions on events like auto-formatting and pre-commit checks after every logical change was completed.
The Testing Showcase
The full session on the claims project illustrates what’s possible when everything aligns:
The coverage analyst and test scaffolder ran in parallel. I reviewed the analyst’s report. The ArchUnit skill generated architecture tests. Two failed immediately, confirming real violations in the codebase. The REST Docs skill generated documentation tests for 8 endpoints as a background subagent. The migration test writer produced 13 migration tests. I identified 5 critical BDD scenarios (this required business judgment the tools couldn’t provide). The BDD skill generated feature files, page objects, and step definitions. JMH benchmarks were written for the highest-complexity methods, and a Gatling simulation was created for load testing.
Skills carried domain expertise. Agents handled scale. The developer made judgment calls. This separation of concerns is what made it work.
And it only worked because the claims project had clear requirements and stable foundations.
Where It Worked: The Claims Management System
The claims project is the control case. It proves AI tools can accelerate delivery when conditions are right.
But “clear requirements” didn’t fall from the sky. The functional specification existed, but it targeted a different technology stack entirely (.NET backend, React frontend). Before writing a line of application code, I used AI tools to process the spec itself: deepening my understanding of the domain, evaluating Java against .NET for this specific problem (Spring Modulith’s event-driven architecture turned out to be a natural fit for the claim lifecycle), designing the bounded contexts and module boundaries, and establishing quality guidelines with specific thresholds for coverage, mutation testing, and performance.
The result was a set of foundational documents: an architecture built around 12 bounded contexts with event-driven integration, quality guidelines specifying mutation score targets of 90% for the rules engine and 85% for financial calculations, and a project-level CLAUDE.md that encoded the development philosophy (functional programming with pure functions for business logic, mutations only at service boundaries) along with concrete patterns and constraints. These documents became the shared context between me and the AI tools for every subsequent coding session.
This matters because the “pre-coding is settled” condition was achieved, not given. AI tools helped settle pre-coding before they accelerated coding itself.
I was also the sole developer, meaning zero coordination overhead and no review bottleneck. Post-coding activities were representable as code: REST Docs generated documentation from tests, ArchUnit enforced architecture as executable rules, Testcontainers provided realistic integration environments, BDD scenarios served as living acceptance criteria, and performance benchmarks were automated.
Roughly 50% of my time on this project was actual coding. That’s a large enough fraction for AI tools to make a meaningful difference. And they did. Delivery was genuinely faster.
Both sides of the equation held. Pre-coding was settled through deliberate investment. Post-coding was automatable: testing, documentation, and architectural compliance were all expressed as code that the AI tools could generate and maintain.
This is what the marketing materials promise. It’s real. It’s just not the whole story.
In Part 2: The Bottlenecks of AI-Augmented SDLC, we look at what happens when pre-coding and post-coding conditions break down — and why faster coding can actually make things worse.