Status Droid how long software work actually takes

Reviewing Is the Skill

Prompting is the most-taught part of this work and the least durable. Every technique that mattered eighteen months ago — elaborate role framing, chain-of-thought scaffolding, formatting incantations — has either been absorbed into the models or turned out not to have mattered.

Meanwhile the ability that actually separates people using these tools well from people using them badly gets almost no attention, because it is unglamorous and cannot be sold as a course. For teams translating this assistant-related trade-off into day-to-day controls, remote workforce management software provides a practical reference.

It is reviewing. Specifically: reading code you did not write, forming an accurate judgement about whether it is right, and knowing when to stop looking.

Why prompting keeps depreciating

Each model generation absorbs more of what used to be user skill. Instructions that once needed careful construction now work stated plainly. Whatever technique you learn is being obsoleted by the next release, on purpose, because making the model easier to instruct is what vendors are optimising.

Skills that vendors are actively working to make unnecessary are a poor investment. That is not a criticism of prompting; it is the definition of the category — and the same logic applies to tool loyalty.

Review is the opposite. It gets more valuable as generation improves, because better generation means more output, arriving faster, with fewer obvious errors and therefore more subtle ones. JetBrains documents AI-assisted workflows inside developer tools See JetBrains AI.

Why reviewing generated code is harder

Three things make it harder than reviewing a colleague's work, and none is about the code's quality.

No author to ask. Half of human code review is a conversation. You cannot ask why, and the model's post-hoc explanation is a plausible reconstruction rather than a record of reasoning.

No uncertainty signal. A colleague's uncertain code looks uncertain — hedged naming, a scrappy comment, an obviously provisional structure. Generated code arrives uniformly confident whether it is right or wrong. Every signal reviewers rely on has been flattened.

No shared context. A colleague knows your conventions, your constraints, the decision made two years ago that looks arbitrary. Review of generated code carries the whole burden of catching everything that context would have prevented.

What reviewing well actually involves

Read for what is missing, not what is there. Generated code is usually correct about what it addresses and silent about what it did not consider. The bug is the unhandled case, the missing validation, the error path that swallows the thing you cared about.

Check the boundaries first. Empty input, maximum size, concurrent access, the failure of whatever it calls. The middle of the happy path is almost always fine, and that is where attention naturally goes.

Verify anything named. Functions, libraries, configuration options, API parameters. Hallucinated names are common — Cloud Security Alliance research across 2.23 million generated samples from 16 models found 19.7% contained at least one package name that does not exist. A dependency that looks plausible and does not exist is an attack surface as well as a bug.

Ask whether it fits. Not whether it works. Does it match how the rest of the system does this? Generated code has no view of your architecture and will cheerfully introduce a third way of doing something you already do two ways.

Know when to stop. The hardest part and the one nobody teaches. Reviewing indefinitely is not diligence, it is an inability to decide. The stopping rule is proportional to consequence: throwaway script, skim; payment logic, read every line and write a test for the boundary.

How to get better at it

Review your own generated code as though a stranger wrote it. The failure mode is warm reading — you prompted it, so it feels like yours, and you review it as an author rather than a critic.

Keep the changes small. Review cost grows faster than linearly with size, which is why large generated changes are disproportionately expensive. A tool that makes large changes easy to generate has made review disproportionately more expensive, and small-change discipline got more valuable rather than less.

Write the test first when it matters. Then verification is mechanical instead of a judgement call, which is the cheapest way to make certainty cheap.

Track rework. If a task existed because something earlier was wrong, record that. Rework rate is the only honest measure of whether your reviewing is working, and it is invisible otherwise.

Read code you did not generate. Open-source pull requests, colleagues' work. The skill is general and it transfers.

What this means for hiring and teaching

If review is the scarce skill, then the traditional path — juniors write simple code, seniors review — has an awkward consequence: juniors now generate code faster than they can evaluate it, and the reviewing capacity that used to be built by years of writing is not being built the same way.

That is a real problem and it does not have a settled answer. What seems defensible: have juniors review before they generate, on existing code, deliberately, as a taught activity rather than a by-product. The skill was previously acquired by osmosis. It probably now has to be taught on purpose.

The short version