AI-Augmented Development: What It Actually Looks Like in Practice

I’ve noticed that most writing about AI-augmented development sits at one of two extremes. Either it’s breathless enthusiasm — “AI writes all your code now, developers are obsolete” — or it’s defensive scepticism — “AI just produces buggy garbage and real developers don’t use it seriously.”

Both positions are wrong, and both are unhelpful if you’re trying to understand what the technology actually does for a working software team.

Let me tell you what a real development session looks like.

The Tools We Actually Use

We use two AI tools in regular rotation, for different parts of the workflow.

Claude Code is our primary tool for agentic coding — tasks where you want the AI to do a substantial chunk of work autonomously. It has a sophisticated understanding of codebases: it reads files, understands context, runs tests, and iterates on its own output. For a task like “implement a new reporting feature based on this spec,” Claude Code can do a significant portion of the work while I do something else, then I review what it’s produced.

Cursor is our AI-enhanced IDE. It’s VS Code with deeply integrated AI assistance — autocomplete that understands your entire codebase, an inline chat that can explain or rewrite code in context, and a diff view for reviewing AI-suggested changes. It’s better for interactive development where you’re actively working through a problem rather than delegating a defined task.

Neither tool is a magic box. Both require you to understand what you’re asking for and to review what you receive.

A Real Development Session

Let me walk through what building a feature actually looks like.

Last month we were adding a bulk email feature to a client’s CRM system — the ability to select a segment of contacts and send a templated email to all of them, with tracking. This is a fairly standard feature but there are enough moving parts to illustrate the workflow well.

Morning: Architecture

Before touching any AI tool, I spent about forty-five minutes working out the design. Where does this feature sit in the application architecture? The sending needs to be queued — you can’t fire off five hundred emails synchronously in a web request. The tracking needs unique identifiers per recipient per send, which has implications for the data model. The templating needs to handle merge fields safely without creating injection risks.

I wrote a short spec: data model changes, the queue job structure, the template engine approach, the tracking endpoint. Nothing elaborate — a page of notes that answered the structural questions.

Late morning: Generation

With the spec in hand, I opened Claude Code and gave it a detailed prompt: implement the bulk email feature according to this spec, using Laravel’s queue system with a dedicated job class, building on our existing Contact and EmailTemplate models, with these specific database columns.

I watched it work. It read the existing models, checked our existing queue configuration, generated the migration, the job class, the Mailable, the tracking model, and a basic controller — then ran our existing test suite to check it hadn’t broken anything.

It took about eight minutes. The equivalent from scratch, writing carefully, would have been two to three hours.

Early afternoon: Review

This is where I spent real time. Not rubber-stamping — reading.

The migration looked good. The job class structure was correct. But I caught three things in review:

First, the template merge field implementation used PHP’s str_replace with user-provided field names. That’s fine for our trusted admin users, but I wanted to be more explicit about sanitising field names before they became array keys. Not a critical vulnerability in context, but a habit worth enforcing.

Second, the tracking pixel endpoint didn’t rate-limit. Someone could spam it to inflate open counts. Added a simple rate limiter.

Third, the job class didn’t handle the case where a contact had unsubscribed between when the batch was queued and when their specific job ran. The AI had implemented the check at batch creation time, but unsubscribes need to be checked at send time. Fixed.

None of these were catastrophic. One was a potential security issue, one was a data quality issue, one was a user-facing correctness issue. All three were exactly the kind of thing a fast code generator — human or AI — might miss.

Late afternoon: Tests

I asked Claude Code to generate a test suite for the feature. It produced eighteen tests covering the happy path, edge cases for empty segments, template validation, queue dispatching, tracking recording, and unsubscribe handling.

I added five more tests for the specific cases I’d fixed in review — confirming that the rate limiting worked, that late unsubscribes were respected, that the sanitised field names behaved correctly.

Total test count: twenty-three tests, all passing.

What AI Does Well

The pattern from that session is consistent across the work we do.

Boilerplate and scaffolding. Database migrations, Eloquent models with their relationships and casts, form request validation classes, resource controllers — all of these follow established patterns that AI tools handle excellently. Writing this kind of code by hand is necessary but not intellectually demanding. AI doing it frees up attention for the parts that require thought.

CRUD operations. Any straightforward create/read/update/delete feature is something AI can implement well from a good spec. The patterns are clear and well-represented in training data.

Tests. This is probably AI’s most underrated strength in development. Given code to test, AI tools generate thorough test suites quickly. We consistently hit higher test coverage on AI-augmented projects than on conventional ones, because the marginal cost of writing another test has dropped substantially.

Refactoring with clear direction. “Extract this logic into a service class” or “replace these three similar methods with a single parameterised one” — these are tasks AI handles well when you can describe precisely what you want.

What AI Does Poorly

Architecture. I can’t overstate this. AI tools don’t know your business, your users, your performance requirements, or your regulatory environment. Asking an AI “how should I structure this application?” is like asking someone who’s read many cookbooks but never cooked dinner to plan a menu for fifty people with dietary restrictions. The output will sound plausible and be wrong in ways that matter.

Security decisions. AI will implement security patterns correctly when instructed to. It won’t identify all the security decisions that need to be made. The list of “things that need to be secure” requires human judgment about your threat model.

Business logic. The subtlest bugs we’ve caught in AI-generated code involve business logic — cases where the code does what the prompt said but not what the business actually requires. These bugs require understanding the domain, not the technology.

Novel problems. AI tools are trained on existing code. For a genuinely novel technical problem — an unusual data processing requirement, a non-standard integration, something at the edge of what the framework was designed for — AI tools are much less reliable and require more careful review.

The Actual Numbers

On projects where we’ve tracked it carefully, AI-augmented development runs three to five times faster for implementation work. That’s a real number, not marketing.

Test coverage is higher — we routinely hit 80%+ on projects where 60% would have been the realistic target without AI assistance.

Bug rates in production are not significantly higher than on conventional projects, because the review discipline we apply is genuine. The bugs we catch in review are real, and catching them before deployment is the whole point.

The limiting factor is no longer “how fast can we write code.” It’s “how fast can we make good architectural decisions and review the implementation carefully.” Which means the human work that remains is the work that was always the most valuable part.

That’s worth sitting with for a minute.

You can read more about the specifics of our process on the how-we-work page. If you want to see what this approach looks like on real projects, the case studies section has details on several of them. And if you’re wondering whether AI-augmented development could work for your project, let’s talk about it.