Agents now write most of our code, and the panic about what that means for engineers is aimed at exactly the wrong half of the job. A mental model I keep coming back to, what it says about the engineer we are all becoming, and why the engineers with the most to gain are the ones just starting.
Every couple of weeks I write a note to our engineering team called Compass. It is where I think out loud about how our craft is changing, and lately one mental model has been doing more work for me than any other. It came out of a question that kept surfacing at our last Tech Townhall, asked in a dozen different ways; if AI writes the code now, what exactly is my job? I think the honest answer starts by splitting software engineering into two loops.
The inner loop is what happens on your machine. You write code, you run it, you see whether it works, you fix it, and you go again. It is tight, fast, and individual, and it is precisely the territory where AI is already dominant. Code generation, test generation, debugging, refactoring: agents are better and faster than humans at this loop, and that stopped being a controversial claim some time ago. At Meesho, 70% of our lines of code are now AI-generated. For practical purposes, the inner loop is solved.
The outer loop is everything else, and everything else turns out to be most of the job. Should we build this feature at all? Does this design scale? What are the second-order effects on other teams? Is this change safe to ship given what is happening in production right now?
How do we respond when it breaks at 2 AM? What is the right tradeoff between speed and reliability this quarter? The outer loop is judgment, context, stakeholder awareness, production intuition, and system-level thinking. AI is nowhere close to owning it today, and while I hold that view loosely, because this field has humbled everyone who made confident predictions about it, the direction is clear enough to act on: the faster the inner loop gets, the more the outer loop is where an engineer's value concentrates. Beneath this lies a quiet truth: engineers have always desired outer-loop work. No one entered this profession to repeatedly build the same CRUD API.
Once you see the two loops, a lot of the current anxiety becomes easier to read. When people say AI is replacing engineers, they are looking at the inner loop and panicking. What is actually underway is a transition in leverage. As the machines get better at the inner loop, each engineer commands more of the system, and the ceiling on what one person can responsibly own keeps rising. That is why a growing share of our pods now run with a single engineer. That engineer's whole job is the outer loop, with agents handling the inner loop underneath them. Everything we build internally, from documentation that gives agents context to work independently, to tests that let them self-validate, to review automation that triages output so humans only see what genuinely needs human judgment, is in service of widening that leverage.
What the outer loop looks like on a real night
The framing can sound abstract until you watch it play out, so let me make it concrete with three situations every engineer here will recognise. In each of them, the inner loop has already finished its work. The code exists, the tests pass, the machine is done. And in each of them, the actual decision has not even started.
Roll back, or patch forward?
Something breaks in production. Within minutes, an agent has read the stack trace, found the offending change, and produced a fix. The patch is ready. That is the inner loop, and it is now nearly instant.
But the patch being ready is not the decision. The decision is whether to roll back or patch forward, and that question has nothing to do with code. Rolling back is fast and well understood, but what happens to the requests that already went through the new path? In systems that move money and goods, some writes are irreversible by design; reverting a deploy rewinds the code, but it does not rewind the world. Patching forward keeps the state consistent, but now you are shipping new code into an already degraded system, at whatever hour it is, with whatever test confidence you have. The engineer on call is weighing blast radius, data consistency, traffic at that hour, and how much they trust the validation around the fix.
And the incident is not over when the graph recovers. The morning after carries a second decision that nobody assigns as a ticket: is this the third time a bug of this exact shape has appeared? A quick fix makes the symptom go away. A class fix makes the entire category go away, and it usually means stopping, writing the problem down, and spending two days on something no ticket asked for. Agents are excellent at closing tickets. Deciding that the ticket is the wrong unit of work is still ours.
The PR is green. Do we commit to it?
An agent-generated pull request lands. Tests pass, review comments are addressed, and by every measure the machine can check, it is done. The outer-loop question is whether the organisation is ready to absorb it: a sale event two days out, a downstream migration in flight, a release freeze approaching.
Now, a fair objection: most of that is context, and context can be fed to an agent. Release calendars, migration schedules, freeze windows: increasingly, agents will know all of it, and will flag it unprompted. I expect that, and I welcome it. What does not transfer is the weighing. Whether a change ships forty-eight hours before a major event is not a fact to retrieve but a risk to own: how much confidence the team has earned in this service, what a failure would cost at that specific moment, and who answers for the call if it goes wrong. An agent can surface every consideration and still not be the one accountable for the decision. A merge is a commitment made on the organisation's behalf, and commitments need an owner.
A one-line ask. What is the actual spec?
A feature request arrives from the product, a sentence or two of intent. The agent can expand it into a fifteen-page spec in minutes: API contracts, edge cases, data models, a rollout plan. The inner loop has never been more eager to build.
The outer-loop questions are the ones the spec cannot answer about itself. What is this ask actually for, and is there a smaller thing that serves the same goal? What should version one deliberately refuse to do? Which of those beautifully enumerated edge cases deserve engineering, and which should be handled by policy or an operations process instead? Scoping is the art of deciding what not to build, and it happens in conversation with people, against goals that live entirely outside the codebase. Hand an agent an ambiguous requirement and it will resolve the ambiguity with a confident guess. Resolving it with the person who wrote the requirement is the engineering.
The junior engineer question, answered honestly
Whenever I share this model, the sharpest question comes from early-career engineers, and I want to be direct about it. Junior engineers today are mostly trained on inner-loop skills: writing code, fixing bugs, closing tickets. If the inner loop is the machine's job now, where does that leave the apprenticeship?
Before the anxiety, notice the windfall. For as long as software has existed, the binding constraint on a young engineer's growth was access to experience. You learned judgment by sitting near people who had it, and there were never enough of them to sit near. That constraint just fell. Every engineer now has something close to an architect on tap. The questions you once queued up for a senior engineer's calendar, why this pattern over that one, how this service should be structured, what a given tradeoff actually costs, can be interrogated for hours, at any depth, at midnight, without spending anyone's patience. Years served used to be the separator. Now it is intent and enthusiasm: the appetite to ask the next question, and the next one after that. That is why I would put it this way. The inner loop pays out feedback in seconds: run it, and you know. The outer loop pays out in quarters. Choose the wrong thing to build, and no test fails; you find out months later, in production at 2 AM, in the quarter review, in the seller who did not get paid. Fast feedback is exactly why machines got good at the inner loop and slow feedback is why judgment stays scarce. AI has compressed the inner-loop apprenticeship from years to months, and the engineers who use that compression to level up on outer-loop thinking will accelerate their careers faster than any previous generation could. The opportunity is enormous, but it has to be grabbed deliberately.
What does grabbing it look like in practice? Watching engineers make this transition well, I have noticed it is not a promotion and it does not wait for permission. It is four specific shifts in how you look at your own work, and we have watched each one happen in front of us.
Shift one: see the class
Stop solving the ticket and start asking what queue it came from. The inner-loop habit is to finish the task in front of you; the outer-loop habit is to notice that the task belongs to a class. One of our engineers knew the on-call ritual by heart. An alert fires, and before any real thinking starts you copy the alert, dig up the query behind it, find the right dashboard, scroll the automated root-cause guess, and hunt for which commit might have broken things. Eight tabs and twenty minutes, every single incident. The inner-loop move is to get faster at the ritual. His move was to see the ritual itself as the problem, because every incident, for every engineer, began with the same twenty minutes of assembly. So he built a tool that takes nothing but the alert link and returns one screen: what the alert actually measures in plain English, the live metric charted against its threshold, the machine's root-cause hypothesis cross-checked against the real code and recent commits, and every relevant link pre-filled for that service and time window. Note what the tool deliberately does not do. It does not pick the fix. It assembles the evidence so the engineer's judgment starts at minute one instead of minute twenty. He solved the class, and left the judgment exactly where it belongs.
Shift two: see the system
Learn what surrounds your code, not just the code. Early-career work naturally narrows your view to your own service, and the outer loop begins the moment you look up. One engineer realised that the questions which open every design review and every incident, who calls this service, what breaks if it goes down, who owns it, had no single answer anywhere. So he built one: an interactive map of hundreds of connected services and their dependencies, generated from documentation the org already had. The build took an afternoon, because the agent did the typing. Seeing that the map was missing, and that the raw material for it already existed, was the part no agent supplied.
Shift three: set the gates
When you automate something, the real engineering is deciding what the automation is never allowed to do on its own. One of our teams automated crash fixing on internal app builds. A tester hits a crash and taps one button; the agent finds the commit that caused it, works out the root cause, writes a fix along with a regression test, and opens a draft pull request. It sounds like the humans have been removed from the loop, and if you look closer the opposite is true, because the team made three deliberate choices. The agent only touches internal builds, never production. It only starts after an engineer explicitly approves. And its output is a draft that a human must review and merge, so nothing ships on the agent's word alone. Those three choices are engineering. A junior engineer exercises judgment on their own work, one task at a time. The shift is turning that judgment into rules the tool enforces for everyone who uses it: what is in scope, when it may act, and where a human must sign off.
Shift four: spot the gaps
The inner-loop relationship with AI is prompt in, code out. The outer-loop relationship starts with a sharper question one of our engineers asked: what does the agent not know about our systems? An agent starts every session as a stranger to your systems, but unlike a new hire, it never raises a hand. Where a person would ask, the agent assumes, and its assumptions compile. Every service carries unwritten rules that live in no document, and an agent that misses one produces code that looks perfect and quietly breaks. His answer was to treat the repo's own history of shipped fixes as an answer key: replay old problems against the agent, compare its attempt to what humans actually shipped, and turn every miss into a short rule that future agents must check against. In his testing, a small model carrying those learned rules caught a hard bug that a far more expensive model missed. The insight was never the model. It was knowing what the model was missing.
The skills that appreciate from here
If you extend this transition forward, the shape of the job changes again. Today an engineer runs agents inside a loop they control. The next step is already visible in the tooling: self-reinforcing agentic loops, systems where agents plan, build, test, and correct one another, running whether or not anyone is watching. The profession is moving from working inside one loop to steering many of them, and knowing when to intervene in a loop, and how, may become the most important capability an engineer has.
Steering is a real skill with real content. Agents, models, and the loops they run in are now part of the system you are responsible for, and they have failure modes, blind spots, and behaviours worth studying the way we once studied databases and networks. The four shifts above are its early forms. Seeing the class and seeing the system tell you what a loop should be pointed at. Setting the gates decides where a loop must stop for a human. Spotting the gaps is knowing what a loop cannot see about your world. Steering sounds like a distant abstraction. It is already the job description.
And underneath all of it, the oldest capabilities are appreciated too: judgment under ambiguity, taste, and ingenuity against problems with no precedent to pattern-match against. Agents are extraordinary where the past resembles the future. Engineers earn their keep where it does not.
The apprenticeship now
There is one caution I attach to all of this, because the judgment everything above depends on can quietly atrophy if you accept everything the agent produces unread. Reading and questioning what the agent made is the apprenticeship now. Earlier I described an engineer who built an engine that turns an agent's misses into written rules. Run the same loop on yourself. Every time you catch the agent being confidently wrong, write down what tipped you off. That list is your judgment made visible, and watching it grow is how you know the apprenticeship is working. And own what you ship. No agent has ever been paged at 2 AM. If it merges under your name, it breaks under your name.
That is the job of the future engineer, you are not writing for-loops. You are deciding what gets built, how it fits together, whether it is safe to ship, and what happens when it breaks. The inner loop is the machine's job. The outer loop is yours. Get great at it.
A question to take back to your team: what is one decision you made this week that no agent could have made for you, and what would it take to teach it? If your answer is “nothing,” you are living in the inner loop. If your list is long, you have found your outer loop. Bring that list to your next design review or retro and argue about it, because the model sharpens in the disagreement. The conversation is the practice.
