Every few months, the same argument comes back: will AI replace developers?
I do not find that question useful. It is too dramatic to guide daily work. The better question is smaller and more uncomfortable: which parts of my job are becoming cheaper, and which parts now need sharper judgment because of that?
Boilerplate is cheaper. First drafts are cheaper. Explaining unfamiliar code is cheaper. Test scaffolds, migration notes, refactor suggestions, and documentation drafts are all cheaper than they were two years ago.
That does not make software easy. It moves the pressure somewhere else.
The boring work is changing first
The first impact is not glamorous. It is not a fully autonomous engineer shipping a product while everyone sleeps. It is a hundred small cuts of friction disappearing from normal development.
Need to understand a folder you have never opened?
Give me a high-level map of this module.
List the important files, what each one owns, and where the risky parts are.
Do not suggest changes yet.Need a first pass at tests?
Read the existing test style in this project.
Add coverage for the empty state and validation failure.
Keep assertions focused on user-visible behavior.Need to review a large diff?
Summarize this diff by behavior change.
Flag anything that changes public API, persistence, security, or error handling.That is useful work. A developer who refuses to use any of it is choosing to spend time on things that no longer need to be fully manual.
But there is a trap here: faster output feels like progress even when the direction is wrong.
The hard parts did not disappear
AI can fill in code inside a boundary. It is much weaker at deciding whether the boundary should exist.
That is where senior engineering still matters. You still have to decide whether a feature belongs in a controller, a service, a queue, a package, or not in the product at all. You still have to know when a “simple fix” is actually hiding a data-model problem. You still have to notice when a test passes because it copied the implementation instead of proving behavior.
The tool can suggest suspects during debugging. It cannot decide what evidence is enough.
For example, if a production sync job starts duplicating records, a tool might quickly find three plausible causes:
- A retry path is not idempotent
- A unique index is missing
- A timestamp comparison changed timezone behavior
That list is helpful, but it is not a fix. The developer still needs to reproduce the issue, inspect real data shape, isolate the failing path, patch the right layer, and prove the duplicate cannot happen again.
The work moves from “can I write the code?” to “can I prove this is the right code?”
Supervision is now part of the craft
Working with AI is closer to supervising a fast junior developer than using a compiler.
If you give vague instructions, it will fill the gaps. If you give too much freedom, it may solve a different problem. If you skip review, it may ship something that looks reasonable and fails in an edge case.
Good supervision has a shape:
Goal: fix the mobile overflow in ProjectCard.
Scope: component and CSS only.
Constraints: do not change project data or props.
Process: inspect existing patterns first, then propose a small plan.
Verification: run component tests and build.That prompt is not fancy. It is just a clear ticket with guardrails.
This is the part developers should practice. Not magic words. Not tricks. Clear intent, scoped work, good context, reviewable output, and verification.
Where human judgment still wins
The more code a tool can produce, the more valuable judgment becomes.
Architecture matters because bad structure compounds. Testing matters because generation without checks is just speed without safety. Product judgment matters because users do not care that the implementation was fast if the feature is wrong. Code review matters because someone has to own the final state of the system.
This is also why “work with it, not against it” does not mean blind adoption. It means learning where the tool helps and where it needs a short leash.
Use it to explore. Use it to draft. Use it to compare options. Use it to find boring mistakes.
Then read the code. Run the tests. Check the edge cases. Make the final call.
The useful response
Competing with AI on typing speed is a bad frame. The useful move is to get better at the parts it does not own: understanding systems, choosing tradeoffs, protecting quality, and communicating intent.
Developers who adapt well will not become less technical. They will need stronger technical judgment because they are reviewing more output, faster.
That is the shift I care about: less value in manually producing every line, more value in knowing what should exist, why it should exist, and whether it is safe to ship.