Is coding still worth it?
By Zeel Jain
FIELD GUIDE - THE NEW CODER
Coding isn't dying. It's getting promoted.
Mid-level coding jobs are getting compressed. The total demand for software is exploding. Here is the four-layer stack that lets you ride the second curve instead of fighting the first.
10x
Cheaper to ship now
4
Layers above the AI
Now
Is the best time to enter
One curve compresses. Another one opens.
Yes, AI is compressing the middle of the engineering job market. It writes the boilerplate, CRUD endpoints, and React forms that used to fill a junior developer's first six months. But the same shift that compresses one slice of the job market opens a much bigger slice above it.
Every solo founder, small-business owner, and non-technical person who never had a CTO can now build software they could not have built two years ago. That market did not exist before. It exists now, and it needs people who can do the part AI cannot: translate fuzzy problems into shippable specifications, review what the model produces, and make the architecture calls that decide whether a product scales or collapses.
The bar for entry has fallen. The ceiling on what one person can build has risen. Both shifts make coding more valuable than it was a year ago, not less. The question is no longer, "Should I learn this?" It is, "Which layer do I learn first?"
The shift: stop optimizing for the part AI just made cheap. Optimize for the four layers stacked above it - the ones that compound as the world needs more software.
LAYER 01 · GUIDE
Telling AI what to build.
Intent in, buildable specification out.
The first layer is the least expensive place to start, yet it is the one most people skip on their way to "real coding." That is the mistake. Turning a fuzzy human problem into instructions a model can execute against - with clear intent, explicit constraints, and surfaced edge cases - is now the work. The clearer your guidance, the less you have to fight the output.
The shortcut: stop pasting two-line prompts and hoping. Give the AI the full picture: what the user is trying to do, what already exists, and what shape the output should take. The specification it produces is the contract that decides whether the next twenty minutes of code generation are useful or wasted.
Example: A PHOTOGRAPHER WANTS A BOOKING FLOW
You tell Claude: "I run a portrait photography studio. I need a way for clients to book sessions, pick a package, and pay a deposit. Don't write the code yet - write the specification my AI can build against."
STRENGTHS
- The clearest leverage available today: clear intent multiplies output.
- The lowest barrier to entry. If you can write a paragraph, you can guide.
- It forces you to think before generating, so many bugs die at the specification stage.
LIMITS
- Garbage in still produces garbage code - only faster.
- Without the next three layers, you cannot tell when the AI is wrong.
- It is easy to mistake speed for skill. Output volume is not output quality.
Use this when: you have an outcome in mind, but the next move is a blank file. Start with the specification, not the code.
LAYER 02 · REVIEW
Catching what the AI missed.
Generated code in, dangerous gaps out.
Generated code can compile without working correctly. The bugs are not always syntax errors; they may be missed null checks, hallucinated APIs, swallowed exceptions, or race conditions in a webhook handler that appear only under production traffic. This layer is where fundamentals start to matter again. You cannot review what you do not understand.
The shortcut: treat every AI output as a junior developer's first pull request. Read it as a senior reviewer would. Where does state live? Where does input come from? What happens on the unhappy path? What was assumed but never verified? The review layer separates people who ship from people who ship and then get paged.
Example: A CHECKOUT FUNCTION WITH RS 50K OF REAL PAYMENTS NEXT WEEK
You tell Claude: "You wrote this checkout function for me last week. It runs without errors, but I am pushing Rs 50K of real payments through it next week. What did you miss?"
STRENGTHS
- It becomes the fastest career-leverage layer once Guide feels routine.
- It teaches patterns; you will start spotting these bugs before the AI does.
- The reviews you perform are the senior-level skill the market pays for.
LIMITS
- You cannot review code you do not understand. Fundamentals are unavoidable.
- Asking the AI to review its own code catches only some of the bugs.
- Skipping this layer is how the headlines about AI shipping bugs get written.
Use this when: AI gives you something that looks right, and the cost of "looks right but isn't" exceeds five minutes of review.
LAYER 03 · DESIGN
Choosing the right shape.
Feature specification in, system shape out.
Once review feels routine, bugs start showing patterns, and those patterns trace back to architecture. Whether a feature uses a cron job or a queue, whether data lives in a cache or a database, and whether a call is synchronous or fans out: these decisions shape nearly all the code that follows. AI can list the options, but it cannot make the call. That decision requires knowledge of your traffic, team, tolerance for failure, and cost ceiling.
The shortcut: before a feature is built, stop and choose its shape. Lay out two or three valid architectures, score them on cost, recovery, and load, and select one before any code is written. The "10x" leverage people talk about lives here more than in any prompt.
Example: A FRIDAY DIGEST EMAIL TO 5,000 USERS
You tell Claude: "I am building a feature that sends a Friday digest email to 5,000 users, summarizing their week. Should I use a cron job, a queue, or generate it on demand? Walk me through the trade-offs."
STRENGTHS
- It is the highest-leverage layer most engineers skip. The right shape can create 100x savings.
- The decisions made here shape the next year of the codebase.
- AI listing options is useful; choosing between them is the job.
LIMITS
- It requires real exposure to systems at scale, not only textbook knowledge.
- It is easy to over-engineer; sometimes a cron job is the right answer.
- Your traffic, team, and budget shape the call. AI does not know any of them.
Use this when: a feature is about to be built and the next twelve months of maintenance depend on which shape you choose.
LAYER 04 · DOMAIN
Knowing what's worth building.
Context in, the build only you would notice out.
This is the layer AI cannot reach. It is not because models are weak, but because the required input does not exist on the internet: the shift handover where nurses lose context, the way outpatient department queues collapse at 11 a.m., or the specific paper form that bottlenecks discharge. Domain knowledge compounds every year you remain in an industry, and it is the one moat AI cannot reproduce simply by training on more data.
The shortcut: stop competing on the generic build. Pick an industry you already understand, or are willing to work inside for two years, and let that depth become your unfair advantage. The other three layers make you fast. This one makes you irreplaceable.
Example: A HOSPITAL ADMINISTRATOR WITH 12 YEARS OF EXPERIENCE
You tell Claude: "I am a hospital administrator with 12 years of experience. I want to use AI to build something that actually helps my team. Help me find the build AI could not tell anyone else to make."
STRENGTHS
- It is the one layer that compounds year after year and that AI cannot copy.
- It lets a solo builder out-execute a generic team in a specific market.
- After enough exposure, the question of what to build becomes obvious.
LIMITS
- It takes years to build context, and that context does not transfer between industries without relearning.
- It is easy to mistake personal experience for the whole industry. Talk to other people in the field.
- Without the first three layers, you can have a great idea but no way to ship it.
Use this when: the question has shifted from "How do I build this?" to "What is even worth building?"
The four layers at a glance.
How to start.
Pick Layer 01 and ship something this week. Do not choose a tutorial project. Choose your own real problem - the one you have already half-described to a friend over dinner. The first build will be ugly, and some of it will not work. The exercise is not the build itself; it is discovering which of the next three layers you need most.
Do not optimize the stack. Do not pick the perfect language. Do not watch another roadmap video. The roadmap appears when you start running into walls: Review when you ship a bug that takes the weekend to fix, Design when the second version of the app collapses, and Domain when you realize the winning version is the one only you would have built.
The reel said the bar for entry is getting lower while the potential impact is getting higher. That is true. What it left out is that the bar drops every month and the ceiling rises every month, which means the cost of waiting also rises. Six months from now is a worse time to start than today.
Close this tab. Open Claude. Pick the layer you are on. Build the next thing.