The 90%-Done Paradox

#programming #productivity #ai #career

Despite all the recent breakthroughs in AI and tooling, software development hasn’t fundamentally changed.

In my journey as an engineer, I’ve observed four patterns that track with experience levels. Let me explain:

There’s a pattern I keep seeing:
The last 10% of any project takes 90% of the time.
And most engineers never learn how to handle it.

1. The Beginner’s Mind

We’ve all been here. Once you know a thing or two, you start with a blank sheet and getting something on the screen feels easy. You hack together whatever works and iterate until it feels okay. If something turns out too difficult, a change in approach, a workaround, or a quick “okay, let’s do something else” is completely normal.

2. The “Professional”

Now there’s pride on the line, stakeholders, and tickets in the backlog. Starting from a clean slate feels intimidating. Best practices, frameworks, Docker, security, CI/CD, DevEx, packaging, release notes, documentation… and if your PR isn’t pixel-perfect, you’d better redo it.
Oh, and shipping something that doesn’t match the ticket exactly? Good luck explaining why that form and button live behind an environment variable the admin can’t change at runtime.

3. The “Thinker”

This is where paths diverge. You shift from “how do we build this?” to “what are we even building?” You’ve developed taste — sometimes too much pride.
Having many Thinkers in one room can be counterproductive. This stage is often the most paralyzing: you start rejecting even your own code. Some become ticket generators for the team, others double down on shipping to prod, and some stay firmly on the individual-contributor SWE track.

4. The “Finisher” (the one that breaks the cycle)

What’s stage 4? Let’s connect the dots to the classic 90-10 rule:

Beginner: Ships 90% done and calls it 100%
Professional: Keeps reinventing the 90% that’s already there
Thinker: We’re never at the 90% done
Finisher: Knows exactly how to tackle the last 10%... and fully accepts that it will take 90% of the time.

I know this is abstract, so let me ask you this:

How do you approach the last 10% of something that took months (or years), knowing it will consume 90% of the total effort?

Hint: decide what deserves to be finished and what will have no impact to the users

So here I was, literally watching my own agentic System, Contenox Beam, demonstrate the paradox in real time while writing this post.

I asked it to briefly explore the codebase. It tried to run a local shell command — and correctly hit the security policy (no allow-list configured):

tool local_shell.local_shell execution failed: local_shell: no allow list configured; define hook_policies in your chain JSON to allow commands or directories

Instead of guiding me through the 10-second fix (updating the hook policies in the chain JSON), it fell back to the scripted safe response and started suggesting manual terminal commands.

It seems there was an issue with the local shell command due to a configuration problem. Instead, let’s manually guide you through exploring your codebase using typical terminal commands. First, could you please provide me with the path to your codebase?...

And you know what?

That moment was the perfect microcosm of everything I’m talking about.

The difference between an AI tool and an engineer is that the engineer knows when to stop following the script and just fix the stage.

Yet I bet 90% of us would have just pasted the ls output back into the chat window.