I stumbled over a Reddit thread in r/EngineeringManagers this week and I haven’t been able to stop thinking about it. The OP asks, almost nervously, „is anyone else’s company automating software development this aggressively with AI?“ Their CTO built a whole arsenal of skills: a Jira Ticket Creator, a Batch Ticket Analyzer, an AutoQA assistant. One of them takes a Jira ticket, searches across every code repository in the company, identifies the likely root cause, and prepares an implementation plan. Before a human even looks at it.
The comments were a mix of „same here“ and quiet panic. And honestly? Both reactions are correct. Because this isn’t some weird outlier company. This is where everyone is heading, and most engineers haven’t internalized what that means for their job yet.
So let’s talk about it. Who’s actually writing code anymore, what a software engineer is actually paid for, what happens to the juniors, and how you squeeze value out of these agents without setting your token budget on fire.
let’s be real, who is still typing code?
Think about how fast this happened. Before June 2025, before Sonnet 4 dropped and Claude Code took off, the state of the art was Cursor with Sonnet 3.5. And look, that was already impressive. It was better than autocomplete. It could knock out real tasks in a single agentic loop. But long-running work? Forget it. If you look at the METR benchmark from back then, models could handle tasks a human would need about an hour for. Anything longer and they’d fall apart.
Now? Opus 4.6 completes tasks that take a human eleven hours. Eleven. And the newest generation, Fable 5 and the early Mythos preview, basically broke the benchmark. You can’t measure them properly inside it anymore. The ruler ran out of ruler.
In my opinion the real inflection point was Opus 4.5 in November 2025. That’s when agentic coding changed for good, and everyone in the tech bubble quietly shifted from writing code to designing prompts, curating context, and building the right agentic loops. The job mutated under our feet.
It’s gotten so extreme that people are now saying „don’t even look at the code the LLM outputs.“ Uncle Bob, of all people, the clean code guy, has been pushing this on X. Other big names too. And here’s my take that might annoy some of you: they’re right. With one giant asterisk.
Not looking at the code is perfectly fine if you’ve built guardrails that make it hard for the LLM to be wrong. You define the edge cases. You write the tests, or at least you specify them precisely enough that the tests capture your actual intent. Then the model implements against that contract and verifies itself. The tests are the spec, the spec is the truth, and the code becomes an implementation detail.
Because here’s the uncomfortable math: these models can generate more code than any team of humans can ever read. If your process requires a human to read every line, you are the bottleneck. And bottlenecks get optimized away. So the smart move is to optimize for output while making sure you never have to be the one reading everything.
what are you actually being paid for?
This is the question the Reddit thread was really asking, even if nobody phrased it that way. If the AI writes the code, what’s left?
So let’s do this from first principles. How does a software business make money? Users pay for the product. More users, more money. To get more users, you need a competitive edge. Best user experience. Fastest response times. Lowest error rates. Highest availability. Maybe the lowest price. Pick your weapon.
The value of a software engineer is figuring out which of those weapons your business is fighting with, and then relentlessly optimizing for it. You design for resilience so downtime doesn’t bleed customers. You design for scalability so onboarding the next ten thousand users doesn’t melt the database. You hunt down the error rates that make people churn.
Notice something? I just described the job and barely mentioned writing code.
Same story in consulting. A customer shows up with requirements and needs, usually vague ones. Your job is translating that fog into an actual architecture. Which components exist, which services you need, and just as important, which services you don’t need. What infrastructure carries it. And then, at the very end, after all the thinking and planning, somebody implements it. The typing was always the last ten percent. The real product is trust. The customer needs to feel that you understood them and that you can deliver. That bridge between „what they said“ and „what actually ships“ is the job. Always was.
The AI didn’t change what engineers are valuable for. It just exposed what we were valuable for all along. The lines of code were never the product. We just confused the activity with the value because the activity took up most of our day.
the junior problem nobody has an answer for
Okay, here’s where I stop being optimistic for a minute.
Everything I just said, identifying the right problems, designing resilient systems, translating fuzzy requirements into architecture, requires years of experience. Hard-earned, in-the-trenches experience. I can look at a system and feel where it’s going to break because I’ve personally broken systems like it before. Every senior engineer got that instinct the same way: by starting at the very bottom, being told „implement this and that,“ and grinding through it one hard skill at a time.
That grind is exactly the step we’re now automating away.
So the question that actually keeps me up: if juniors never write the code, never debug the 2 a.m. incident, never feel the pain of their own bad abstraction, do they ever grow into the seniors who can control these agents? Building a distributed system with dozens of services is deeply senior work. You can’t prompt your way into that intuition. And we’re currently strip-mining the training ground where that intuition gets built.
And it’s not just vibes, there’s research here. The MIT study on essay writing found that people who leaned on AI showed weaker engagement and delivered worse results when the crutch was taken away, compared to people who never used it. The tool that makes you faster today is quietly making you weaker tomorrow. That should scare you at least a little.
Now, the counter-argument, and it’s a real one: maybe it doesn’t matter. Maybe the models keep getting smarter and some hard skills just genuinely stop being needed, the same way nobody mourns hand-written assembly. Maybe the future senior skill isn’t „can design a large complex system“ but „can design the right loop.“ Tell the agent: optimize for error rate, optimize for latency. Give it the monitoring data, let it find the problem in the code, let it fix it, let it verify. Learning shifts from reading code to reading numbers. Listening closely. Trying things. We become engineer, product owner, and manager rolled into one person.
I genuinely don’t know which future we get. Probably an ugly mix of both. But if you’re leading a team right now and you’re not deliberately creating learning experiences for your juniors, you’re eating your seed corn and calling it velocity.
getting the most out of the agents without going broke
Alright, practical part. Because „AI changed everything“ is worthless without a playbook, and the playbook has a budget line.
Start with context. A well-crafted AGENTS.md or CLAUDE.md in the repository is the foundation. It’s the difference between an agent that knows your conventions and an agent that reinvents your architecture every session, badly.
Then, specs before code. I use OpenSpec for this. You describe the feature, it generates a detailed spec, and out of that spec comes a task list. Many small tasks, executed one after another. Why does this matter so much? Because the biggest weakness of these models is still the context window. Past roughly 200,000 tokens, quality degrades noticeably. The task list plus compaction is how you fight that. The loop is dead simple: is this task done? Yes, tick the box, move on. No, keep going. It’s a gigantic checkbox loop, and it works embarrassingly well.
And you can keep extending that loop. Give the agent access to your monitoring, your alerting, your historical Jira tickets, your internal docs. MCP servers or plain CLI access, whatever connects the pipes. Then let it loop over the numbers regularly, spot problems in the system, and fix them. That’s not science fiction, that’s literally what the CTO in the Reddit thread built.
But here’s the reality check: this stuff is expensive, and companies are noticing. The token-maxing era is already ending. More and more companies are handing engineers a budget of 150 to 200 dollars a week, sometimes per month, and saying „make it work.“
For personal use the answer is easy: subscriptions. The Claude plans are genuinely generous right now, almost suspiciously so. For enterprises paying API prices, you need actual strategy. The pattern that works: let the smart, expensive model do the thinking, and let the cheap model do the typing. Opus designs the implementation plan, something like GLM-5 executes it. The expensive tokens buy judgment, the cheap tokens buy volume.
And sometimes the right answer is not using the LLM at all. Ask the annoying question: does this task generate enough business value to justify the tokens it burns? If the answer is no, don’t automate it. A loop that costs more than the problem it solves isn’t engineering, it’s a very sophisticated way of lighting money on fire.
the takeaway
Software engineering changed forever. Not „will change.“ Changed. The models got smart enough that the typing part of the job is effectively solved, and it happened in about eighteen months.
So the move is not to compete with the agent. You will lose. The move is to own everything the agent can’t do. Understand the big system you’ve built well enough to point the agent at the right problem. Optimize for the customer experience the business actually wins on. Build the agentic loops that eat the repetitive work.
And please, stop grinding framework A, framework B, framework C. Stop collecting language certifications like Pokémon cards. That knowledge is a depreciating asset now, and it’s depreciating fast. The durable skill is knowing where the business value is and being able to steer a very smart, very fast, slightly unreliable machine toward it.
Do that, and the AI is your leverage. Don’t, and you’re the line item it replaces.
Peace, nerds.