The job is moving from writing every line to deciding what should exist. That is not a smaller job. Typing was never the hard part.
What changes is where the difficulty sits.
What actually got easier
Three things that used to take days now take minutes:
- 01The first version. A working screen with real data, before you have decided whether it is the right screen.
- 02The unfamiliar part. The language, the service or the format you have never touched.
- 03The work you kept postponing. Tests, documentation, the tidy-up nobody volunteers for.
That is a genuine shift. The first version used to be expensive enough that people defended bad ideas because of what they cost to build.
What did not get easier
Knowing what to build
A model will build whatever you describe, including the wrong thing, quickly and confidently. Deciding what deserves to exist is still yours.
Judgement about the whole
Generated code answers the question you asked. It does not know the decision made three months ago, the customer who cannot use a certain flow, or the part of the system that must never be touched on a Friday.
Being responsible for it
When something breaks at two in the morning, "the model wrote it" is not an answer. Whatever ships is yours.
A model raises the floor on producing code and does nothing to the ceiling on understanding it. The gap between those two is where the expensive mistakes live.
Treat it as a contributor, not an oracle
The teams doing this well hold generated work to the same bar as anything else:
- —Read every line before it ships. If you would not sign off a stranger's version of it, do not sign off this one.
- —Ask for the smallest useful piece. A whole feature in one response cannot be reviewed properly, so it will not be.
- —Say what it must not do. Constraints matter more than description: which files to leave alone, which patterns to follow, what to do on failure.
- —Keep the tests honest. Code written by a model and tested by the same model, unread, is two guesses agreeing with each other.
The skills that gain value
Ranked by how much they matter now compared with three years ago:
- 01Describing a problem precisely, including what is out of scope.
- 02Reviewing work you did not write, quickly and sceptically.
- 03Choosing a shape for the system that survives changes you cannot predict.
- 04Taste. Deciding that a working thing is not yet good enough.
Every one of them is a judgement skill. None of them is typing.
What this means if you are starting now
Not knowing how to code stopped being the barrier. Not knowing what a good version looks like became it.
The fastest way past that is to build small things end to end and pay attention to where they hurt. Understanding follows the pain, not the tutorial.
Start here this week
Take something a model built for you and read it line by line until you can explain every part in plain words. The lines you cannot explain are exactly your next lesson.
The lessons are organised by that pain, and the tools directory groups the options by the job rather than by hype.
