Six weeks with a coding assistant, honestly

After six weeks of paid, daily use as an independent developer, here is what the assistant actually changed in my workflow — and what it quietly did not.

I have been paying for an AI coding assistant for six weeks. Not evaluating it; using it, at work, on real client code, every day. This is a plain field report — not a review, not a rating, not an argument. Just what I noticed after long enough that the novelty had worn off.

I want to be honest about the setup first, because it changes what any of this means. I am a lightly-technical solo consultant, mostly writing Python and Typescript, mostly for small teams that pay me to build the boring internal tools nobody else wants to touch. I am not a Google engineer with a fifty-thousand-file monorepo. I am not a hobbyist. My results will not generalise to you exactly, but they may generalise a little.

What actually changed

Three things changed measurably.

Boilerplate collapsed. Writing a new API endpoint used to be a fifteen-minute exercise: route, validation, permission check, unit test, doc-comment. It is now a two-minute exercise. Not because the assistant is cleverer than me, but because it is faster than me at typing a shape I have described a hundred times before. This turns out to be one of the largest gains and one of the least glamorous.

Small refactors became cheap. Renaming a variable across a codebase, extracting a helper, converting a class to a dataclass, adding a missing type annotation — all of these went from "worth doing on Friday afternoon" to "worth doing immediately." The result is that my recent code is quietly better organised than my old code, in a way that is only obvious when I go back to a project I hadn't touched in six months.

Reading unfamiliar code became less exhausting. When I open a file I did not write, I now ask the assistant for a plain-English summary before I start reading, and I ask it to point at anything that surprises it. Not every summary is useful; enough of them are that the friction of "onboarding to a new codebase" has dropped meaningfully for me.

What did not change

Two things I had expected to change did not, or barely did.

Architecture decisions. The assistant is a bad partner for "should this be one service or two." It has opinions, but they are shallow, weighted toward whatever pattern is most represented in its training data, and they do not know your specific team, your specific customers, or the political constraints inside the client's engineering org. I have twice tried, in earnest, to talk through an architecture decision with it. Both times the useful part was the act of writing the question down. The answer was, essentially, wallpaper.

Deep debugging of my own code. When I know a bug exists and I can reproduce it, the assistant is fine. When I have a vague sense that something is wrong and I want a second pair of eyes to find it, the assistant tends to invent plausible causes and confidently propose fixes to them. I have wasted more than one afternoon following its suggested fix down a road that had nothing to do with the actual bug. I now trust it only when I already have a reproducer.

The assistant is a superb typist and a mediocre engineer. Deploy it accordingly.

Two habits I ended up building

Write the intent first. Before every non-trivial assistant use, I write a two-line prose summary of what I want to happen — not what code to produce, but what the resulting behaviour is. This slows me down for about twenty seconds and improves the output out of all proportion. It also means that when I read the diff, I know what to compare it against.

Read every diff. Not the same as accepting every suggestion — the opposite. I now treat the assistant's output the way I would treat a junior developer's pull request: assume it is close to right, look for the one line that is subtly wrong, and never merge without eyes on every line. This is not a criticism of the assistant; it is a criticism of the failure mode of trusting any generated code you did not read.

What surprised me

The single most surprising thing was social, not technical. My tone with clients changed. Because I could ship the boring parts of any request faster, I could ship them within the same call as the request itself. This produced a kind of quiet delight in my inbox that I did not previously experience, and it changed how I structured my week — from "big blocks of head-down work" to "quick loops with the client between blocks."

I am not sure yet whether this is an improvement in the long run. Some kinds of work want long blocks. Some clients want fast loops. What is clear is that the tool did not just make me faster at old work — it changed what kind of work I was willing to accept.

What I would tell someone deciding

If you spend most of your day writing routine code in a language and framework you know cold, the tool is likely to pay for itself in under a week, and you will build habits with it that make you a better engineer in the long run.

If you spend most of your day doing architecture, debugging, code review, or writing in a domain the assistant has not seen much of — the tool is a nice-to-have and you should not expect it to change your life. Do not let the enthusiasm of people in the first camp make you feel behind.