@adlrocha - How AI Is Redefining Software Engineering

From Coder to Agent Manager: how I stopped writing code by hand after more than a decade of daily practice.

After the detour we made the last few weeks exploring the state of the hardware and software stack of local AI inference, I want to come back to one of the topics I promised to address in my posts about agent engineering. In this post I want to try to answer a question that I’ve been asking myself since the last time I wrote a line of code by hand. This is a question that I feel has been bugging everyone in the tech sector in the last few months: how is the role of software engineers changing in the age of LLms, agents, and wide-spread intelligence?

Let me share my view on the matter.

How I got here

My relationship with AI coding tools has gone through different phases in the past year and a half. I think it is worth sharing my personal journey because I suspect most of you may have gone through similar phases.

My first phase in this journey was the “LLM as a rubber duck” phase. When ChatGPT, Gemini and Claude came out, I’d paste in some code, describe a problem to the model, and argue with it until I’d figured out what I actually wanted to do and the right architecture for it. It was great for brainstorming and the research phase.

In terms of code generation, at this point I still was writing the code by myself (that means actually typing it line-by-line like we were used to doing in the previous century). I was treating LLMs as a glorified StackOverflow. They were great at generating code snippets and ideas about how to implement something, but you couldn’t trust them to write full features that you could just copy-paste into your code base. It was a great knowledge base and a peer to discuss and think out loud.

Then Github Copilot and Cursor entered the scene. I honestly never adopted the tab-tab-tab approach that most people got so hooked to. What I found most useful in this phase was the ability to have an IDE companion in the same interface with whom I could chat about code and ask for suggestions and ideas with all the context loaded into it without me having to copy-paste code into a web textbox. In this phase, I was still writing most of the code by hand.

Then, around November last year, something completely changed.

Agents like Claude Code and Github Copilot’s agent mode were already around Summer of last year, but after trying them for a bit I wasn’t impressed, and my immediate reaction was of pure scepticism. Why would I want to use these agents if the code they were generating was sloppy? There were two things that really bothered me: I felt like I was losing track of my own codebase, and the code the agents produced didn’t feel like mine. It was correct in a generic sense as the code compiled and did what it was supposed to do, but it didn’t reflect the architecture decisions I’d made, best practices, the tradeoffs I’d considered, the reasons certain things were the way they were. TL;DR, it didn’t read as high-quality production code.

Christmas of 2025 was the inflection point for me. Everyone was talking about the new version of Sonnet and how crazy the improvement of quality of Claude Code’s output was. As many others, I used the quietness of Christman to take Claude Code for a spin again with a side-project that I had been looking to revive for a while, and I literally was blown away. To me it felt like overnight Claude Code was able to create high-quality code that I could have easily written myself (maybe because I am not a good coder, but still). For the first time I wouldn’t have been able to recognise code written by me from code written by an LLM.

From there on, my relationship with LLMs and how I think about my role as an engineer has changed completely. I stopped trying to supervise every line of code or trying to re-write it myself, and started focusing on what I was actually better at: the spec, the architecture, the judgement about whether the right thing was being built at all, going deep into the technical side of things. The agent handled the mechanical translation from intent to code and I was just focusing on the high-stakes logic and steering the agent towards the right solution while reviewing that the output was correct.

It is hard to admit it, but after more than a decade writing code by hand, for the first time I wasn’t typing the code I shipped myself. I was unexpectedly being “promoted” from an IC to an agent manager.

---

Software engineering is already changing

The clearest signal that engineering work has already changed isn’t anyone’s opinion, it’s visible in the source code of the tools we’re building with. I feel like the way we are building coding agents these days reflects the shape that software will have everywhere in the new future.

Karpathy’s LLM OS framing is no longer a metaphor. MatrixOS (which I’ve already brought up in some other posts of this newsletter) maps it literally: the model is the CPU, the context window is RAM, the filesystem is persistent storage. When you look at the Claude Code source or the internals of Hermes, opencode, and pi, you’re not reading prompt templates, it maps a set of new software modules that will become the de-facto for software architectures moving forward. Four-layer compaction hierarchies. Sleep-based memory consolidation. KV cache stabilisation through sorted tool lists. These are not AI features. They’re systems engineering problems that will be applied to every domain.

This is where engineering is moving. Not toward writing more code, but towards designing the systems that write it and that leverages intelligence towards a specific task

I am not a fan of Garry Tan myself, but I think he is doing a decent job exploring what this new paradigm of software engineer could entail: fat skills (reusable markdown documents that encode judgment and process), a thin harness (the minimal loop that runs the model), resolvers (routing tables that load the right context at the right moment), and a sharp line between decisions that belong in latent space and operations that need to be deterministic. When I read those posts they felt familiar, because I already had a lot of those pieces in my own projects. As I’ve been repeating for a while now, we are all facing the same problems in this space, and converging to similar solutions.

---

From code to agent manager

Fine, I think we all agree that the discipline of software engineering is changing fast, but what does this mean for the engineer itself if they don’t have to write code by hand anymore?

MilksandMatcha and 0xSero wrote recently about the single-agent ceiling, the moment every developer hits when a project graduates from a toy to something practical. One agent, one context window, 35 minutes in, the context is bloated, the code is wrong, and you’re counting remaining tokens on your left hand.

Their fix is multi-agent architecture. The metaphor is a kitchen: the head chef (orchestrator) takes the order, breaks it into scoped tickets, and hands each one to a line cook (subagent). Each line cook gets a fresh context window, minimum viable context, does one thing, returns the output, and clocks out. Real numbers: single-agent workflow on a Figma task averaged 36.5 minutes with a 100% failure rate. Multi-agent: 5.2 minutes, success on the first try.

But the metaphor does something more important than describe an architecture. It reframes the engineer’s job. “Take off the apron,” they write. “Put on the chef’s coat. You’re running the kitchen now.”

Garry Tan makes the same point from a different direction. In his follow-up post on resolvers, he works through what it actually means to run an agent system with 40+ skills and 25,000 files (I really think this is an overkill and I am not using this approach myself, but I’ve seen this pattern in several people already). He arrives here: “What I actually built is closer to management. Skills are employees. The resolver is the org chart. Filing rules is an internal process. Trigger evals are performance reviews.”

The problem isn’t that models aren’t smart enough. “We’ve been building organisations with no management layer. Just a pile of talented employees and a vague hope they’ll coordinate.”

This is what the job actually looks like now. Not writing code. Running an organisation of skills, contexts, and subagents. Designing the handoffs. Deciding what belongs in latent space and what needs to be deterministic. The engineer who does this well isn’t the one with the best typing speed.

I have to admit that I myself am not there yet. I still run a small kitchen with a pool of trusted agents that are adapted to my daily workflows, but with nuances, I tend to agree that at a high-level this is where the industry is moving: an IC engineer is more and more becoming an architect, a manager, and a founder.

---

What we are replacing is the middle man

The field is splitting. Not cleanly, more like the rough shapes that are becoming visible.

But before the taxonomy, the more important point: engineering skills are becoming a multiplier, not just a job description. The barrier to shipping code has dropped. What that actually means isn’t that engineers are less valuable, I don’t think software engineers are going anywhere. I don’t think we are going to be replaced as the narrative suggests. It’s that deep technical knowledge now powers up roles that previously had no access to it. Product, GTM, finance, management, all of these are being redefined by people who can reason architecturally and build end-to-end without a team. The engineer who can drive a project from idea to deployed product, alone, is a different kind of professional than what that title implied five years ago.

Marc Andreessen made a related point in his conversation with David Senra earlier this year. His argument is that from the 1960s onwards, companies increasingly came to be scaled by engineers rather than by professional managers, not because engineers are better managers by nature, but because technical founders can adapt when the environment shifts rapidly, and managers cannot (as they don’t have the deep knowledge or technical foundation to adapt to rapid changing technologies and environments). Managerialism made sense when things were not changing. When things change fast, managers are completely lost because they have no idea how to handle disruption. You are way more likely to build something important if you take a founder and teach them management than if you take a manager and try to teach them to think like a founder.

His argument was centered on companies. But the same logic applies one level down, to individual careers. When the environment changes this fast, and the ground is shifting faster now than it was when Andreessen was making this observation, the people who remain anchored in deep technical understanding are better positioned to adapt than the people whose edge is coordination of stable systems.

---

The new archetypes

Which brings the archetypes into focus. There are still a few distinct shapes emerging:

The researcher. Goes deep on how models and systems actually work. Understands attention mechanisms well enough to reason about KV cache invalidation, reads the Claude Code source and immediately sees the connection to OS design. Narrow role, always in demand, genuinely irreplaceable. There’s no substitute for the person who understands why the architecture is what it is. Companies like Anthropic and the big labs are hiring lots of these, and if the promise of AI realises they’ll need more to tame their models.

The hardcore specialist and engineer-in-the-loop. The best distributed systems engineer, security engineers, or the best C++ engineer still has real value. But raw coding depth is being commoditised, not eliminated, but less of a moat on its own. If the only edge is writing faster or cleaner code than an agent, that edge is shrinking. Companies will still need some of these to keep agents under control, but they’ll need less of these than today. Even as the volume of agent-written code grows, someone still needs to review the architecture, audit the security model, and catch the places where the agent did something technically correct but fundamentally wrong. Fewer engineers will do this work, but the ones who do it well will be load-bearing in ways that are easy to underestimate until something breaks.

The fast-learning generalist. This is where the market is opening up in ways that I think we are not realising yet. AI compresses the time from “I don’t know this domain” to “I can build something useful in it” dramatically. An engineer who can pick up a new field quickly, apply sound architectural judgement without already being an expert, and drive a project end-to-end, that profile is becoming more valuable. The post I wrote about being scared of irrelevance rather than AI comes to mind: the engineers who will be irrelevant are the ones who narrowed so far they can’t transfer.

The founder. They have an engineering background but can pick up a project end-to-end and permeate throughout the whole company: from finance, to product, GTM, and people ops. These are the unicorns. They are great, but they may not fit every company, and they may be more suited for early stage and small companies, or nimble autonomous teams.

Of course, AI doesn’t only benefit software engineers. A film editor, a musician, a lawyer who understands the technical substrate of what they’re working on, anyone who can add deep craft and leverage AI for the rest is now competing at a level that used to require a team. The flip side: if your edge was output volume rather than judgement, that edge is gone.

---

The forgetting problem

I recently read this post that describes in a great way one thing I’ve been really worried about (and that I’ve seen others writing with concern about): “The West forgot how to make things, now it’s forgetting how to code”, which draws on a striking historical pattern. After the Cold War, the US stopped producing Fogbank, a classified material used in nuclear warheads. When they eventually needed to restart production, the tacit knowledge had atrophied so thoroughly that they essentially had to rediscover how to make it from scratch. Stinger missile production ran into the same problem after Ukraine demonstrated the need. Something similar happened with the outsourcing of chip manufacturing to China in the last decades, the West is losing its edge on the semiconductor industry.

The pattern is clear: build capability over decades, find a cheaper substitute, let the human pipeline atrophy, enjoy the savings, then watch it collapse when a crisis demands what you optimised away. The post argues we’re running the same risk with code. And the concern about juniors is real. When juniors skip the formative debugging sessions, the mistakes that build the intuition for where things actually go wrong they don’t build the tacit expertise. When the generation that has it retires, that knowledge doesn’t transfer. This is what really worries me about where software engineering is moving

Koshy John introduces the counter-side of this argument in this post: “For years, people have confused software engineering with code production. That confusion is now getting exposed.” The value was always in the judgement: making sound decisions, identifying missing abstractions, debugging reality. And that judgement is built through friction. Through struggle. Through getting things wrong and fixing them.

My intuition is that the people who navigate these issues best are the ones who stay curious about why things work, even when they don’t need to know how to build them from scratch. You can use AI to build the four-layer compaction hierarchy without understanding it. Or you can use it to understand it, and then build something better. The engineers who choose the second path I don’t think will ever be replaced. The ones who choose the first are renting an edge, and the Fogbank example is a reminder of what happens when you rent long enough to forget you ever owned it.

---

How are you dealing with this change?

Many of the topics I touched on in this post are present in the public discourse (a.k.a Twitter), and are brought up in one way or another in conversations with colleagues and friends. But I would be curious about the first-hand experience and thoughts of the readers of this post.

If I can collect enough testimonials from my readers it would make for a pretty nice follow-up post: my take on the matter v.s. readers’ realities. If you want to contribute with your experience and thoughts shoot me a comment or an email. And in any case, see you next week!