The Last 20% Is Still the Job

Right now, the 80/20 rule is on steroids.

You can one-shot something with AI and get what looks like 80% of the work done in a few minutes. A component appears. A refactor compiles. A module gets extracted. The output looks clean. It feels fast. It feels like the hard part is over.

But most of the time, that "80%" is actually the easy 20%.

AI can one-shot a convincing draft, but the work that makes software valuable still lives in judgment, boundaries, and tradeoffs.

That is the point.

AI is very good at producing a plausible first pass. It can get you to something that demos well, reads well, and even survives a shallow review. And that matters because speed matters. Momentum matters. Getting to a draft quickly is real progress.

But the remaining work is still where engineering earns its keep.

Where this shows up

I keep seeing this in work that looks simple on the surface, like extracting a module so it can be reused and shared.

AI can help you pull code out into a neat package very quickly. It can suggest a shape, clean up duplication, and give you a reasonable starting API. For a moment, it feels done.

But here is the catch: reusable code is not valuable because it was extracted. It is valuable if it survives contact with real usage.

That is where the actual work starts.

The hard part did not go away

What should the interface be so it stays simple without boxing future consumers into a bad design? Which assumptions from the original code are safe to carry forward, and which ones were only true in that one context? Where do ownership boundaries sit? Who gets to change this module later, and who pays the cost if the abstraction is wrong? What breaks if other parts of the system already rely on today's behavior?

Those are not cleanup details. That is the work.

Backward compatibility alone can turn a "small extraction" into a serious engineering problem. A one-shot draft might give you a reusable-looking module, but it will not automatically know which behavior is accidental and which behavior other systems quietly depend on. It will not feel the scar tissue from previous migrations. It will not know which naming choice will confuse every future caller. It will not know which edge case only shows up under production load or in the ugliest customer path.

An experienced engineer knows that shipping a shared module is not just moving code around. It is making a promise.

And promises are where the cost lives.

Why this matters now

This is why I think a lot of people are getting over-impressed by one-shotting. The output can be genuinely impressive and still be incomplete in the most important ways. It can remove a lot of typing. It can remove a lot of blank-page friction. It can even remove a lot of tedious implementation work.

What it usually does not remove is the need for judgment.

You still need someone to decide whether the abstraction is real or premature. Someone to notice that a generic API is actually leaking assumptions from one team. Someone to decide whether preserving compatibility is worth the complexity. Someone to know when a clean-looking solution is too brittle to be shared.

That is not leftover work. That is the part that makes the result tight and valuable.

The reassurance

If you are an engineer feeling a little uneasy watching AI crank out code so quickly, I think the right reaction is not panic. It is clarity.

The easy part got cheaper.

That is good news.

But the hard part, the part where you apply taste, judgment, tradeoff awareness, and real-world context, is still extremely valuable. Maybe more valuable now, because more people can produce convincing first drafts and fewer people can tell whether those drafts should ship.

In practice, AI is compressing the distance between idea and draft. It is not eliminating the distance between draft and good.

That gap is still the job.

Use AI. Let it get you moving. Let it do the obvious work fast.

Just do not confuse a strong first pass with a finished piece of engineering.