There is a lot of noise online about AI coding tools right now. Most of it is one of two flavors. Either AI is going to replace all developers next quarter, or AI cannot really write code and the entire trend is hype. Both are wrong. The truth is more practical and a lot less dramatic, and the only way to figure it out is to actually use the tools on a real build for an extended period of time.
I have been doing exactly that for the last several weeks on a personal project that lives outside my normal client work. The project is a database driven web application with multiple data sources, scheduled background jobs, a custom frontend, and a real schema. Five years ago, I would have estimated maybe two months of solid evening work to get to a usable v1. With AI tools as a real part of my workflow, I am ahead of that schedule, but not by the order of magnitude that the marketing claims would suggest. What follows is what actually happened.
Where the tools genuinely help
The clearest gain has been in the part of the work that used to be the most tedious. Writing a poller that hits an external API, parses the response, normalizes it against an internal schema, and writes the result to a database, is largely the same shape of code every time. Different APIs, different schemas, but the same underlying pattern. Having an AI tool that can write the first draft of that poller in a few minutes, including the error handling, the retry logic, and the idempotent insert pattern, saved me genuine hours per integration.
What used to be a slog is now closer to a review exercise. The AI produces a first draft. I read it carefully, push back on the parts that do not match how I want the project structured, ask for the rewrite, and end up with a clean implementation faster than I could have written it from scratch. Not magically faster. Maybe two times faster on the kind of code where the patterns are well known.
The other clear gain has been in the friction reduction of small refactors. Renaming a function across many files. Updating a query when the schema changes. Adding a parameter to a function and updating every call site. The AI handles these without complaint and without missing edge cases that I would have missed in a manual find and replace.
Where the tools do not help
The places where AI coding tools have not helped me at all are the places that matter most.
Architectural decisions. Whether a piece of state belongs in the database or in the application code. Whether two related concepts should be one table or two. How to structure the public API of a library so that callers do not get tangled up in implementation details. These decisions look small and they compound. A wrong call here costs you weeks of refactoring in three months. AI tools are happy to write code in either direction, but they will not push back on a bad architectural choice unless you specifically ask, and even then the pushback is shallow because the tool does not have your full context.
Edge cases that depend on real world knowledge. On this build, one of the most painful debugging sessions involved figuring out that a third party API was returning rates in a different unit than I had assumed. The AI cheerfully wrote code that conformed to my assumption. The bug was not in the code it produced, the bug was in my premise, and the AI had no way to know. The fix was hours of staring at numbers, comparing against the actual venue UI, and realizing the unit was off by a factor of one hundred. AI did not help me solve that. The discipline of reading the source UI did.
Naming things at the right level of abstraction. The AI tends toward names that describe the implementation. I tend toward names that describe the intent. Resolving that mismatch consistently across a codebase takes deliberate work, and you have to do it during review, not just trust the first draft.
Knowing when to stop building. The thing about a tool that can produce code quickly is that it is easy to keep producing code. There is a moment in a build where the right move is to ship what you have and use it for a week before adding anything new. AI tools have no sense of that moment. They will happily generate the next feature whether or not it is the right move. The discipline of stopping is yours.
How I actually integrate them into a workflow
I write the architecture first. The schema, the data flow, the rough shape of how the pieces fit together. AI does not enter this phase. The thinking is mine.
Then I write the first piece of code by hand. Usually a representative example of the kind of code the project will be made of. Doing the first one by hand teaches me the patterns and produces a reference example that subsequent AI generated code can be aligned against.
From there, AI does first drafts of new pieces that match the established pattern. I review every diff before accepting it. The review is real review, the same level of attention I would give a junior developer’s pull request. Maybe more, because the AI does not have the context that comes from sitting in the project for weeks.
When something breaks, I debug myself first. I read the actual source. I check what the API is actually returning. Only after I know what the bug is do I bring the AI in to help write the fix. Letting the AI debug from scratch wastes time because it tends to guess at causes rather than verify them.
The realistic productivity claim
If a developer told me they were getting a 10x productivity boost from AI tools, I would assume they were measuring tokens written and not features shipped. My experience, on a real build over real time, is closer to a 1.5 to 2x boost on the kinds of code where the AI is genuinely good, and roughly no boost at all on the parts of the work that determine whether a project ships well or badly.
That 1.5 to 2x is not nothing. Over a project that would have taken two months, it might shave a few weeks off the timeline. That is meaningful. But it is not magic.
The Milwaukee angle
If you are a Milwaukee business looking at the AI coding tool conversation, here is the practical version. Better tools mean a competent agency can do more work in the same time. They do not mean an incompetent agency suddenly produces good work. The skill of evaluating an AI generated implementation and steering it toward correct is itself a skill that takes years to develop. It is the same skill as evaluating a human developer’s work, applied to a slightly different input.
Agency pricing might come down a bit on commodity builds. Pricing on serious custom application work, where architecture and judgment matter, will stay where it is. The bottleneck has never been typing speed.
What working solo with AI feels like
Working on a meaningful project alone, late at night, with an AI tool that can carry some of the implementation load, is a different experience from working alone five years ago. There is a quality of conversation about the code that did not used to exist. I find myself thinking out loud more, because there is something on the other end of the conversation that responds in a useful way.
It is not a peer. It does not push back the way a senior engineer would. But it is a kind of structured rubber duck that occasionally hands me back the duck with the answer written on it. That is useful, and it has changed the texture of solo work in a way I would not give up.
The tools change the texture of what I can do in those late night and weekend hours, layered on top of client builds. They do not change that the work happens at the edges of my normal week. That is the honest version of the AI coding tool story.
If you are running an agency or a software project and you want to talk through how to integrate these tools without getting sold a fantasy, that is a conversation I would be glad to have. There is a lot of bad advice on this topic. The good answer takes longer than a tweet thread to explain.