How AI Actually Changes the Way You Write Code

In late 2022 I installed GitHub Copilot to settle an argument with a colleague. I fully expected to uninstall it within the week. Three years later my editor has changed twice, the models underneath have changed more times than I can count, and the way I build software has quietly turned inside out. I have shipped production features with Cursor, pointed Claude Code at a Django monolith older than some of my coworkers' careers, and spent one humbling Saturday unwinding what an agent did to a billing module while I was insufficiently paying attention.

This piece is what I wish someone had handed me on day one. Not the vendor pitch, and not the doom thread either. Just the specific, observable ways your daily work changes once a model sits inside your editor, checked against the best public research available and against my own scar tissue.

You write less code and read far more of it

The first change is the one nobody warns you about. Before AI, my job was mostly production: think, type, run, repeat. Now my job is mostly evaluation. On a typical feature day I write maybe a fifth of the characters I used to, and I read three or four times as much, because every suggestion, completion and generated diff is a small pull request from a stranger who is confident, fast and occasionally wrong in ways a human never would be.

Here is what that shift looks like across an ordinary day:

None of this made me worse at programming. It changed which muscles get used. The typing muscles atrophy a little. The reading, naming and judging muscles get a workout they never used to get.

What the research measured, side by side

The public studies on AI coding look contradictory until you notice they measured different situations. One famous trial found huge speedups. Another equally rigorous one found a slowdown. Both are correct, and the gap between them is the most useful thing you can understand about these tools.

Read the first two rows together. Greenfield work in unfamiliar territory: dramatically faster. Deep work inside a mature codebase you already know: often slower. The detail that should keep every engineering manager up at night is the perception gap in the METR trial. Developers who were measurably 19% slower still believed, afterward, that AI had made them 20% faster. I recognize that feeling from my own weeks. The tool feels like progress even when the clock disagrees.

Five concrete changes to how you work

You write specifications now, not syntax

A prompt is a spec, and vague specs produce plausible garbage. My prompts have grown from one line to small briefs: constraints, file references, the edge cases that matter. My written English now gets code-reviewed by reality every single day.

Review becomes the job itself

Faros AI measured merged pull requests nearly doubling while review time also nearly doubled. That matches my calendar. Reading a 400 line generated diff is a distinct skill from reading a colleague's work, because the model's mistakes carry no smell of hesitation.

Your trust develops a radius

After enough repetitions you learn the map. Regex, SQL, test scaffolding, data munging, glue code: strong. Concurrency, timezone math, your internal APIs, anything touching money: verify every line. I keep a literal note titled “places the model has lied to me” and it has 31 entries.

Boilerplate stops shaping your design

I used to avoid certain patterns purely because they were tedious to type. That tax is gone, which is liberating and slightly dangerous. GitClear's finding that duplicated code jumped while refactoring collapsed is what happens when generating a fresh copy is easier than reusing an old abstraction.

You meet a brand new species of bug

Two thirds of surveyed developers name the same frustration: answers that are almost right but not quite. This bug compiles, passes a casual read, and often passes the happy-path test. It fails at 2 a.m. in production, on the leap day, for the customer in Auckland. Human bugs cluster around laziness and typos. Model bugs cluster around confident, well-formatted misunderstanding, and 45% of developers report spending more time debugging AI output than they expected to.

Where it earns its keep, and where it bites

Consistently worth it

• Tests you would never have written. My coverage on side projects went from embarrassing to respectable, because generating a test suite costs minutes.

• Unfamiliar stacks. I shipped working Rust and Terraform this year. Pre-2023 me would have budgeted weeks for either.

• Legacy archaeology. Pasting a gnarly 2014-era function and asking what it does, and what breaks if I touch it, saves hours of tracing.

• Mechanical sweeps. Renames, migrations, converting callbacks to async, updating forty call sites: tireless and fast.

• One-off scripts. Log parsers, CSV wranglers, quick CLI tools. Code that lives for an hour is the perfect assignment.

Where it costs you

•  Big diffs hide defects. DORA links AI adoption to a persistent drop in delivery stability, and larger change sets are the suspected mechanism. My incident history agrees.

•  Duplication accrues silently. The model happily writes a fourth date-formatting helper instead of finding your existing three.

•  Delegated skills get rusty. Six months after handing regex fully to the model, I noticed I had to think hard about syntax I once knew cold. One in five surveyed developers report eroded confidence in their own problem solving.

•  Review fatigue is real. Evaluating other minds' code all day is draining in a way that writing your own never was.

•  Familiar code can be a net loss. If you already know exactly what to type, explaining it to a model, then correcting the result, is pure overhead. METR measured this precisely.

The workflow that survived three years of churn

Tools kept changing under me. Copilot gave way to Cursor for most editing, agents joined for larger tasks, and models rotated every few months. These six habits are the ones that stayed useful through every generation:

1.  Write the failing test or the interface first. Before prompting, I pin down what correct means: a test, a function signature, or a typed interface. It anchors the model and, more importantly, it anchors me.

2.  Prompt with constraints, not vibes. File paths, the library versions in use, the error-handling convention, what not to touch. Thirty seconds of context routinely saves three correction rounds.

3.  Cap every generated diff at junior-PR size. If I would not approve a 600 line pull request from a new hire in one sitting, I do not accept one from a model. Small diffs are where my defect catch-rate stays honest.

4.  Read it like a hostile review, then run it. I check the edges the model loves to fumble: empty inputs, error paths, off-by-one boundaries, timezone handling. Then I actually execute it, because compiling was never the bar.

5.  Do the naming and final shaping yourself. Renaming variables and reorganizing the result forces the code through my own head. It is how the mental model of the system stays mine instead of the machine's.

6.  Two failed prompts means write it by hand. The costliest hours I have lost were spent re-prompting in circles. A hard stop after two misses keeps me from the sunk-cost spiral the METR participants fell into.

Who genuinely gets faster

Averages hide everything here. The same tool, on the same afternoon, can save me two hours and then cost me one. The pattern that finally emerged for me lines up neatly with the published data:

My honest verdict after three years

I would not go back, and I say that as someone who has been personally burned. The Saturday I spent reverting an agent's creative rewrite of our billing retries taught me more about these tools than any benchmark, and I still reached for the same agent on Monday, just with a tighter leash.

What I know now that I did not know in 2022: the tool amplifies whoever you already are. DORA calls AI an amplifier and that phrasing is exactly right. My disciplined weeks got noticeably more productive. My sloppy weeks produced sloppier code faster than my hands ever could. The speed is real, the perception gap is also real, and the developers thriving with these tools are the ones who kept their skepticism and upgraded their review habits, not the ones who accepted the most suggestions.

The craft did not die. It moved. It used to live in my fingers, in knowing the syntax and typing it quickly. It now lives in my judgment: knowing what to ask for, recognizing a lie in well-formatted code, and having the taste to say no to a diff that works but does not belong. If you are deciding whether to invest in these tools, invest, but budget as much time for learning to read their output as you ever spent learning to write your own.