In 2025 I was writing about 75% of my code by hand. In 2026 that number is closer to 2%, and it's still dropping. This is the year LLMs have truly arrived for me, and I think I'm in the minority who feel it that strongly, because the gains are concentrated in places like software where outputs are easy to verify.
A friend of mine is a dentist. When I told her my job these days is primarily using AI models, she gave me a look of polite disgust. She doesn't quite believe in them. Maybe they aren't useful to her in any meaningful way yet. But anyone who works in software knows how good these models have really gotten. I suspect the general population still thinks of AI as the free version of ChatGPT they tried once. It's also probably easier to improve "intelligence" in verifiable domains like maths and programming than in fuzzier ones, which leads to strange peaks and troughs where the user has to constantly test what the model is actually good at.
I was chatting with a coworker at Blutui about where I see the field heading, and it gave me the idea to write this blog. It's either going to age into a "I told you so" or get shamefully deleted….. there's a reason it's hosted on my own site haha.
whoami
I started my career as a software engineer in 2023, and I've been using AI the entire time: embedding tables, RAG pipelines, fine-tuning. A lot of that work fed into Blutui's AI components and other AI integrations across the Blutui suite. More recently I've been writing skills for AI agents to better understand the Blutui syntax. It's been interesting to watch the progression, from prompt engineering in the early days (literally injecting text before the user's query), to AGENTS.md files, and now to thinking carefully about efficient token usage through skills and harnessing the API with MCP servers. Alongside that I've been doing plenty of regular software engineering, unrelated to AI. That mix is what makes me feel like I have a reasonable base to talk about where the role is heading.
The short version of my view: the engineer isn't disappearing. The engineer is becoming an orchestrator.
What software engineering looks like from the outside
Any time I explain what I do for work to someone outside the field, they're bored almost immediately. I've heard things like "so you sit at a desk for eight hours a day writing colourful text on a black screen?" with the subtle, polite sarcasm of someone describing a nightmare job back to you. And to be fair, without the understanding underneath it, that's exactly what it looks like.
But the process of understanding code, once you've gone through the pain of learning it, is quite neat. It's like learning a new language, or anything difficult. Every tiny thing you learn feels like a giant physical step you have to haul yourself up. It's brutal at the start, but the more steps you climb, the easier the next one gets, until one day you can just read code, or Mandarin, or whatever you chose.
There's also a particular joy in getting stuck on a problem, sleeping on it, and getting the epiphany in the shower or more likely the toilet the next morning. That feeling is one I've been having less and less since LLMs got good. I'm not sure yet whether that's a loss, or just a change of where the joy lives.
Two people with a CS degree walk into a bar…
I think there are roughly two types of people who end up in computer science, and you can spot both in any engineering team. There are the people who care about the process, and the people who care about the outcome. Not that the outcome people don't care about craft, or that the process people don't ship, but you'll always notice the split. One group spends a weekend getting every line of their Neovim config exactly right. The other group opens VS Code and gets on with it.
AI-assisted development, in my opinion, favours the second group. Frontier models in 2026 are more than capable of writing most of your code, so some of the craft of writing it yourself is being squeezed out. But the craft of reviewing code, owning it, and shaping the system around it has never mattered more.
To paraphrase Addy Osmani: you can use LLMs however you want, but you need to own the code. The responsibility to understand what changed sits with you, not with the model.
Writing code is now cheap. Notice I'm not saying good code, or good architecture, or anything of that sort, just code. To ship something to production you still need the right harness around the model: a clear spec, a review process, and a real understanding of how the change fits the rest of the repo. Those are steps you'd have had to do anyway, even without AI. The understanding phase used to come for free because you wrote the code yourself. Now you have to work for it deliberately.
This is where spec writing earns its place on the chart of how I spend my day. With agentic development, the single highest-leverage skill is writing a clear description of the problem you want solved: the technical outcome, the constraints, the things that should not change. Use planning mode. Make the model ask clarifying questions. Eliminate ambiguity before any code is generated. If you can produce enough of these specs without them stepping on each other, you can write features in parallel at a rate that would have seemed absurd two years ago. Peter Steinberger the creator of OpenClaw is an extreme example of this.
In many ways, the role of the software engineer is moving from someone who writes code to someone who reviews it.
What about the people who haven't written code yet?
The obvious objection here is if reviewers need to have written code to review it well, where does the next generation of reviewers come from? I don't have a clean answer. I suspect the honest version is that junior engineers will still need to write code by hand for a while, the same way pilots still train on manual flight even though they rarely use it in cruise. The training and the daily job are allowed to look different.
There is an art … to flying. The knack lies in learning how to throw yourself at the ground and miss
The software engineer is becoming what the modern airline pilot is: a trained operator whose main job is to take over when the automation fails.
Modern planes can essentially fly themselves. There was a time when three people sat in the cockpit, but by the late 1970s and early 1980s that was down to two as avionics improved. Some people now argue you could run a commercial flight with a single pilot. Whatever you think of that, the direction of travel is clear. Cruising and even landing are largely automated. So why do we still put pilots in planes? For when things don't go to plan.
Writing code manually may not be needed most of the time in the future. But you still want someone trained, watching what's happening, ready to take over when it goes sideways. That's what the software engineer becomes: the final control layer over the automation. Take that layer away and you're vibe-coding.
Some predictions
Agentic infrastructure. I'm fairly confident this is coming soon. A way for AI agents to allocate infrastructure and deploy applications end-to-end. Imagine asking for a website and having the agent write the code, build a deployment strategy, pick the most cost-effective infrastructure for your traffic and budget, and ship it, then come back and tell you what it cost and why. The pieces mostly exist already. What's missing is the harness that makes the whole loop safe and predictable enough to hand over.
Fully AI-run companies. This one is more of a stretch, but I'll say it anyway. A company where an agent runs the business with little to no human intervention. The intuition is that the slowest part of most workflows today is the handoff between a human and an agent. If you remove that handoff, things move much faster, assuming you've solved the guardrails problem, which is the assumption doing all the work in that sentence. Anthropic's Project Vend is a fun early data point here. It also went wrong in interesting ways, which is the part worth paying attention to. The question isn't whether an agent can run a small business. It's what happens at the edges when something unexpected shows up. (That, again, is the pilot's job.)
Why I'm still excited
Personally, these models make me more excited about building software, not less. Every random idea I have, I can now scaffold quickly and find out whether it's actually any good. I do this work because building things is fun, and the fun isn't gone, it's changed. The epiphany in the shower used to be about solving the puzzle. Now it's about which puzzle is worth picking up next, because I can actually attempt more of them than I ever could before.
I'm looking forward to seeing what people build once iteration is this cheap. A lot of bad ideas are about to get tested, and a few great ones are going to fall out of the pile.
Email: dionpinto000@gmail.com