Skip to content
Brian Sithu
Go back

AI is an amplifier, not an equalizer

Cover image for AI is an amplifier, not an equalizer

Every company has the same coding agents. The output is not the same. AI multiplies what you already bring, and it multiplies the gap with it.

Brian Sithu

Written by

Brian Sithu

View profile

On this page

05 sections

There was a hope that AI would level the field. Give everyone the same model and the difference between a strong engineer and an average one shrinks. I do not see that happening. I see the opposite.

Same tools, different use

Every company I know has access to the same things. Codex, Claude Code, Cursor, whatever ships next week. The licenses are cheap and the models are the same for everyone. If the tool were the advantage, there would be no advantage.

What differs is how the tools are used. Most people try an agent, get a mediocre result on the first prompt, and file it under hype. A few people live in these tools. They run them on every task, learn where they break, and rebuild their workflow around what they are good at. They write plans the agent can follow. They know when to give it a whole module and when to give it one function. That knowledge does not come with the license. It comes from hours of use.

Two teams with the same subscription can end up a year apart.

Faster ideas, not better ones

AI gets ideas out of your head faster. It does not give you better ones.

If I know what I want, an agent turns a paragraph into a working prototype before lunch. If I do not know what I want, it turns a vague paragraph into a confident, working, wrong prototype just as fast. The model executes the thinking I bring. It does not replace it.

So the old inputs still decide the outcome. Clear thinking about the problem. Real data instead of assumptions. Colleagues who push back. Curiosity about why something works, not only whether it does.

Curiosity matters more than it used to, because iteration is now nearly free. You can try five approaches in the time one used to take. A curious person uses that. They ask what happens if, try it, look at the result, and ask again. Someone who stops at the first answer that compiles gets one answer faster. Someone who keeps asking gets five answers and picks the best. Endless iteration only pays if you have a reason to keep going.

The gap grows

Put the two together and the math is unkind. A multiplier applied to different starting points widens the distance between them.

A high performer brings judgment, context, and taste. AI removes the typing, and what remains is mostly the part they were already good at. They get much faster at producing good work.

A weaker performer brings less to multiply. AI removes the typing for them too, but the bottleneck was never the typing. They produce more, and more of it needs review. Often the reviewer is the high performer, whose time just became more valuable.

This is my reading, not a measurement. But I have not seen a team where AI closed the gap. I have seen several where it opened one.

What to build, and whether it matters

For most of software history, the hard question was whether you could build it. Could the team ship this feature, this integration, this product, in time and on budget. That question is fading. For a large share of ordinary software, the answer is now yes, and quickly.

The question that remains is older and harder. What should you build, and does it matter?

That is a question about taste and about users. Knowing which problem is worth solving. Knowing when a feature adds weight instead of value. Sitting with a user long enough to see the problem they did not describe. None of that is in the model. All of it decides whether the fast, cheap, working code is worth anything.

When building was expensive, bad ideas died in planning because nobody could afford them. Now bad ideas ship. The filter moved from capability to judgment.

What I take from it

AI rewards the people who were already good, and it rewards the people who invest in it. It does not rescue anyone from not thinking.

If you want the multiplier, use the tools every day until you know their edges. Then spend what you save on the parts that did not get cheaper: understanding the problem, talking to users, and deciding what is worth building at all.



Previous Post
The brain gets better at what you actually do