AI-Assisted Development: How I Actually Use It as a Developer

I have been writing code professionally for over six years. For most of that time, my workflow looked roughly the same. Read the requirements, think through the architecture, open a blank file, and start typing. Every interface definition, every configuration block, every repetitive data mapping, I wrote it all by hand. I was fast at it. I had snippets, templates, muscle memory. I could scaffold a new API endpoint in my sleep.

Then AI coding assistants arrived, and I ignored them for longer than I should have.

The early demos looked impressive but felt like toys. Generate a to-do app. Write a sorting function. Autocomplete a for loop. None of that was useful to someone who already knew how to write a for loop. The value proposition seemed aimed at beginners, and I moved on.

I was wrong. Not about the early tools, because those really were limited. But about what this technology would become in a short period of time, and more importantly, about where it fits into a working developer's day-to-day.

The Boilerplate Tax

Here is something nobody tells you early on. A significant portion of a developer's day is not spent solving hard problems. It is spent on boilerplate. Interface definitions. DTO mappings. Configuration files. Migration scripts. Test fixtures. CORS headers. Environment variable validation. The hundredth REST endpoint that follows the exact same pattern as the last ninety-nine.

I used to maintain personal template repositories. Cookiecutter projects, Yeoman generators, shell scripts that scaffolded entire project structures. I had a private Gist collection with snippets for every pattern I used regularly. Retry logic with exponential backoff, pagination helpers, error response formats. Every experienced developer I know has something similar. A personal toolkit built over years to avoid retyping the same patterns.

AI replaced all of that overnight.

Not in a vague, futuristic way. In a concrete, practical way. I describe what I need in plain English, and the boilerplate appears. Correctly structured, following the conventions of whatever framework I am working in, with the right imports and type annotations. The amount of time I used to spend on mechanical code generation has dropped dramatically. A task that took twenty minutes of careful copy-paste-modify now takes two minutes of describing intent and reviewing output.

How My Workflow Actually Changed

My workflow did not change in the way I expected. I thought AI would write entire features while I watched. That is not what happened. What happened is more interesting. The ratio of thinking to typing shifted dramatically in favour of thinking.

Before AI, my day was roughly 30% thinking and 70% typing. Now it is closer to 70% thinking and 30% reviewing. The typing still happens, it is just the AI doing most of it. My job shifted from being a code writer to being a code architect and reviewer. I spend more time on system design, edge cases, security implications, and performance characteristics than I ever did when my fingers were busy producing syntax.

A typical session now looks like this. I describe what I need at a high level. The AI generates a first pass. I read it carefully, not skimming, actually reading, and I catch the things it gets wrong. Missing error handling for a specific edge case. An inefficient query pattern that would fall over at scale. A security assumption that does not hold in production. I point these out, it adjusts, and we iterate. By the third or fourth pass, the code is production-ready.

The critical part is the review. That is where real-world experience matters more than ever.

What AI Gets Wrong (And Why It Matters)

AI is remarkably good at producing code that looks correct. It compiles. It passes basic tests. The variable names make sense. The structure is clean. And sometimes, buried three layers deep, there is a subtle bug that only someone with production experience would catch.

I have seen AI-generated code that used new Date() in a server-side function without considering timezone. Code that built SQL queries with string concatenation instead of parameterised queries. Code that caught exceptions and silently swallowed them. Code that implemented retry logic without a circuit breaker, which would hammer a failing service even harder when it was already down.

None of these are exotic bugs. They are the kinds of mistakes that a developer who has been on-call at 3am learns to avoid instinctively. AI does not have that instinct. It has pattern matching trained on millions of repositories, including the ones with bad practices.

This is why the narrative that AI will replace experienced developers is backwards. AI makes them more productive. It makes newer developers faster at writing code but does not give them the judgement to know when the code is wrong in ways that only show up under load, in production, at scale.

The Baffling Moments

For all its blind spots, AI occasionally does something that genuinely catches me off guard.

A developer on a team I follow shared a case where they asked an AI to optimise a database query that was timing out on a 200-million-row table. The AI suggested rewriting it as a recursive CTE with a materialisation hint. The developer had been planning to add an index and call it a day. The CTE approach ran in 400 milliseconds instead of 45 seconds. The developer had 15 years of PostgreSQL experience and had never considered that approach for that particular query shape.

I had a similar moment with a Cloudflare Worker. I was dealing with a problem where static pages resolved from the asset manifest before middleware could rewrite URLs for subdomain routing. I had been stuck on it for a day, trying different middleware approaches. The AI suggested patching the compiled Worker script itself, injecting URL rewriting before the framework's asset resolution. It was unconventional, slightly hacky, and it worked perfectly. I would not have arrived at that solution as quickly on my own because I was stuck in the mental model of solving it within the framework's intended extension points.

Another one. A fintech engineer posted about asking AI to parse an ISO 8583 financial message. The AI not only parsed it correctly but flagged that the message contained a field combination that technically violated the spec. A processing code that should not appear with that particular message type. The engineer had been working with ISO 8583 for years and had missed it because that particular combination had always been accepted by their gateway.

These moments are rare, but they keep you honest. The AI is not always right, but it occasionally sees angles you have stopped looking for.

The Review-First Mindset

The single biggest shift in my workflow is that I now treat every piece of generated code the way I would treat a pull request from a talented but inexperienced developer. I assume it is probably fine, but I read every line before it goes anywhere near production.

This is not optional. I have a personal rule. Nothing AI-generated ships without a manual review pass. Not a quick scroll-through, but an actual review where I ask myself the same questions I would ask reviewing a teammate's PR:

• Does this handle the error cases I know about from production?
• Is there a security implication the AI might not have considered?
• Will this perform acceptably at the scale we operate at?
• Does this follow our team's conventions, or did the AI hallucinate a different pattern?
• Are there edge cases specific to our domain that the AI could not know about?

This review-first approach is why AI makes experienced developers faster rather than redundant. The generation is cheap. The judgement is expensive. AI provides the former and experience provides the latter.

Where AI Falls Flat

Architecture decisions. Full stop. AI can implement a pattern you have chosen, but it cannot tell you whether you should use event sourcing or CRUD for your particular domain. It cannot weigh the operational cost of running Kafka versus the simplicity of a database-backed queue. It does not know that your team has one person who understands Kubernetes and three who do not, and that this should influence your deployment strategy.

It also struggles with anything that requires understanding the business domain deeply. It can write a function to calculate tax, but it does not know that your finance team rounds differently for New Zealand versus Australia, or that a specific client has a contractual exception that overrides the standard calculation. Domain knowledge is still entirely human territory.

Debugging production issues is another weak point. AI can suggest possible causes for an error, but it cannot correlate that a spike in 502 errors started exactly when the DevOps team rotated the TLS certificate and the old cert was still cached in three edge nodes. That kind of reasoning requires context that lives in people's heads and Slack threads, not in code.

Practical Tips for Developers Adopting AI

If you are a developer considering integrating AI into your workflow, here is what I have learned through daily use.

Be specific with your prompts."Write a REST endpoint" gives mediocre results. "Write a POST endpoint that accepts a JSON body with name, email, and message fields, validates input lengths, rate-limits by IP using Cloudflare KV, and returns structured error responses" gives you something close to production-ready on the first pass.

Use it for the boring parts. Test fixtures, data transformations, configuration files, migration scripts. Anything where the pattern is well-established and the risk of subtle bugs is low. Save your own cognitive energy for the parts that require genuine thought.

Never skip the review. The five minutes you save by not reading the generated code will cost you five hours when a subtle bug hits production. AI-generated code is a draft, not a final product.

Teach the AI your codebase. Modern AI tools can read your existing code. Point them at your project structure, your conventions, your configuration. The output quality improves dramatically when the AI understands the context it is generating for.

Do not fight the tool.If the AI keeps suggesting an approach you disagree with, consider whether it might be seeing something you are not. Sometimes it is wrong. Sometimes you are stuck in a pattern because "that is how we have always done it." The best results come from treating it as a collaborator, not a subordinate.

The Uncomfortable Truth

The developers who are most threatened by AI are not the ones who cannot code. They are the ones whose primary value was typing speed and boilerplate knowledge. If your contribution to a team is that you can scaffold a new microservice from memory in thirty minutes, AI can now do that in thirty seconds. But if your contribution is knowing which services should be microservices and which should stay monolithic, knowing where to put the circuit breakers, knowing which database to use for which access pattern, that judgement is more valuable than ever because now you can act on it faster.

The developers who will thrive are the ones who use AI to eliminate the mechanical overhead and redirect that time into the work that actually matters. Understanding the problem, designing the solution, and making sure what ships to production is correct.

I spent a good chunk of my career building a personal toolkit of templates, snippets, and generators to avoid repetitive work. AI made that entire toolkit obsolete in about six months. I am not upset about it. I am faster than I have ever been, and I spend more of my day doing the part of the job I actually enjoy. Solving real problems instead of typing the same patterns for the thousandth time.