The New Bottleneck in Software Is Understanding.

Execution used to be the expensive part of building software. It is not anymore.

That one change broke a few things nobody is talking about properly. So let me try.

There is the understanding layer, and there is the execution layer.

Understanding is deciding what should exist. What the data model looks like. Where one service ends and another begins. What happens when the payment API times out. Who is allowed to read this row. What breaks first when traffic goes up 10x.

Execution is turning all of that into actual code, config, pipelines, servers.

For most of this industry’s life, execution was the expensive one. Writing a service took weeks. A schema migration took a sprint and a maintenance window.

Think about what that cost did to our behaviour.

If execution is expensive, being wrong late is brutal. You find out in week nine that your primary key should have been composite, and now you are unwinding nine weeks of work.

So teams thought first. Design reviews. Long arguments about normalization. Boring questions about read/write ratios and retention and blast radius, all asked before anyone opened an editor.

Nobody did this because planning is noble. They did it because the alternative hurt.

And here is the part nobody planned for. That pain produced good engineers. You could not survive five years of expensive execution without picking up a real feel for how systems behave.

You write a prompt. You get a working app with auth, a database, a deployed frontend, and tests that pass.

Not a toy. Something that actually runs.

For people who already knew what they were building, this was a huge speedup. Good for them.

For everyone else, something different happened. Non-tech founders started shipping products. Clients of top consultancies stopped hiring consultancies and built in-house. My own classmates ship full apps in a weekend.

None of them were forced through the understanding layer. Nothing in the process asks for it anymore.

Being wrong is cheap now. Until it isn’t.

Here is how that plays out.

A company builds an internal tool, decides it does not need developers anymore, and ships it. People use it every day. It works.

It also has one endpoint with no auth that returns the entire customer table. They are one crawler away from hearing about it from a journalist.

The software worked the whole time. Working was never the same thing as correct.

When something runs, all you have learned is that one scenario holds up. Happy path, one user, good network, small data, nobody attacking you.

You still do not know:

• whether that query drops from an index seek to a full scan at 10 million rows
• whether the retry loop is idempotent, or whether it charges the customer four times
• whether the bucket is actually private
• whether sessions expire, and what a stolen token buys someone in the meantime
• whether you built a write-heavy design for a read-heavy product
• whether it does what the user needed, or what they said in the kickoff call

None of this shows up in a demo. All of it shows up later.

Most beginners can get a project to 80% with AI alone. That is real. 80% is a lot.

The mistake is assuming AI takes you the rest of the way.

It does not, and not because the model is weak. The last 20% is made of decisions that need context the model does not have. Your traffic. Your budget. Your compliance rules. Whether your team can debug this at 3am. What you are willing to give up, and what you are not.

That 20% decides if it scales, if it is secure, and if it solves the actual problem.

It is also where the money is.

I freelance. Every rupee I have earned came from the 20%. My whole class can build the 80%, and that part is basically free now, so it is priced like it. Very few of them can get close to 100%.

That gap is the job.

Resumes died first.

Candidate A designed the system and can tell you what happens when the queue consumer falls behind. Candidate B prompted the whole thing into existence and had ChatGPT write the bullet points.

On paper? Identical. In a 30 minute screen? Often still identical.

So interviews are shifting from “can you build this” to “why is it like this.” Why this schema. What breaks first under load. What would you delete. That is hard to fake, because the follow-up question gets you.

The second part is worse, and it lands on freshers.

A senior with an agent runs the whole thing end to end now. No need for 5 juniors and 2 unpaid interns to handle the low level work. That work was the most clearly specified work in the building, which is exactly why it got automated first.

And those junior years were how people used to build understanding in the first place.

The first few steps from that ladder are gone and people are expecting you to make a jump on the first try.

Nothing forces you through the understanding layer anymore. So walk through it on your own.

Get curious about the layer below whatever you are touching.

A SQL query returns four rows. Go find out what the database actually did in between. It parsed your statement, planned it, picked an index scan or a sequential scan based on statistics that might be stale, took locks, read pages that may not have been in memory, maybe spilled a sort to disk.

Every one of those is a place your app will be slow one day. You cannot debug what you cannot picture.

Do the same with your tools. You use a coding assistant every single day. How does it hold context across a long session? How does it index your repo? What happens when the window fills up, and what does it choose to forget?

Knowing that is what puts you in a position to build things like that.

And point the same AI at your knowledge, not just your output. Ask it for three designs for one requirement and make it argue for each one. Ask it to attack your schema. Ask what this pattern costs you in eighteen months.

It used to be:

Now it is:

No new model fixes that one. If you are not clear on what you want and why, a better model just gets you to the wrong place faster.

AI can be the best assistant you will ever have. It can also quietly kill your judgement, until you are the guy who hits accept on whatever shows up on screen and calls it engineering.

Both are on the table. Which one you get depends on whether you are still doing the understanding yourself.

The phrase is not mine. I picked it up from Geoffrey Litt, in Understanding is the new bottleneck. I read it, and I have not been able to stop thinking about it since.

His post is about staying in the loop on your own project. How do you actually understand the code an agent just wrote for you, when it writes faster than you can read? He has real techniques for it: explainer docs, quizzes you have to pass before you ship, small interactive worlds you can poke at until the system makes sense. The line that stuck with me is that you understand not just to verify the agent, but to participate.

I kept turning that over and landed somewhere else with it. He is writing about one developer and one codebase. I wanted to write about what the same shift does to the rest of us. Who gets hired. What a fresher is supposed to do now. Where the money actually sits.

Go read his version, it is better on the how. This one is my take on the so what.