.jpg){kind=link}
Writing code got faster. That is the honest summary of what assisted development has changed for most teams, and it is a real change.
What it has not changed is which practices keep software working over years. Some of them now matter more than they did, because the bottleneck moved.
Review matters more, not less
When code took a long time to write, the author understood every line by the time it existed. That is no longer guaranteed.
Code that was generated quickly can be read quickly and approved quickly, and the result is changes going in that nobody fully understands. The rule that has served me best is simple: you own what you merge. If you cannot explain what a block does and why it is there, it is not ready, regardless of who or what wrote it.
Tests are the thing that did not get cheaper to be wrong about
Generated code is confident. It compiles, it looks idiomatic, it uses plausible function names, and it can be subtly wrong in ways that reading does not catch.
Tests are the mechanism that catches that, and they are more valuable now precisely because more code arrives per hour and less of it has been thought about line by line. The one place to be careful is letting the same process write both the code and the tests for it, which can produce a suite that faithfully asserts the bug.
Small changes still win
A large diff is hard to review whether a person or a tool produced it. Assisted tools make large diffs easy to produce, which quietly pushes teams toward changes that are too big to reason about.
The discipline of one change per commit, and a pull request a colleague can hold in their head, is worth more now than it was.
Names and structure are for humans
The value of a good name has always been that a person reading it later understands the intent. That has not changed, and the reader is still a person, usually at an inconvenient hour.
Consistent structure also makes generated contributions better, because the surrounding code is the strongest signal for what a new addition should look like. A codebase with clear conventions gets better assistance out of the same tools than one without.
Delete more than you think
Fast generation makes it cheap to add and no cheaper to maintain. The volume of code a team carries determines how hard it is to change anything, and that arithmetic did not improve.
The most useful thing I do in a codebase most weeks is remove something.
Understanding is still the job
The part that has not moved at all: knowing what the system does, why it is built that way, and what breaks if you change it.
Tools produce code. They do not produce understanding, and understanding is what you are paid for at three in the morning when something is down. The teams getting the most out of assisted development are the ones who treated it as a faster way to express a decision they had already made, rather than as a way to avoid making it.