Skip to content
the-real-work-was-never-the-code.mdx — vim — zsh
@devblog:~/posts$ cat the-real-work-was-never-the-code.mdx
---
title: “The Real Work Was Never the Code
description: “AI didn't change what software engineering is about. It finally revealed what the job always was: orchestration, judgment, and turning ambiguity into clarity.
date: 2026-01-19T10:00:00
reading_time: 7 min read
tags:[AI][Software Engineering][Career][Future of Work][Productivity]
---

Around 2009, I was working at Sapotek, a Mexican startup focused 100% on Flash development. ActionScript was my world. We built apps, interactive sites, rich media experiences, all the cool stuff that made the early web feel alive. Flash was everywhere, and honestly, the future looked pretty bright for those of us who had mastered it.

Then Apple decided Flash wasn't welcome on the iPhone.

It wasn't a dramatic moment where someone called a meeting to announce "Flash is dead, pack your things." It was more like watching a tide slowly go out. Fewer projects coming in. Clients starting to ask about alternatives. The writing on the wall getting clearer every month until you couldn't ignore it anymore.

So I pivoted to PHP and web development. Learned new frameworks, new patterns, new ways of thinking about building things for the web. My career continued just fine. I eventually became an IT manager while still coding on the side. I never stopped learning, never stopped adapting, because that's just what you do in this industry if you want to survive.

I've seen this movie before. I know exactly how it ends for those who don't adapt.

Now I'm watching the same pattern unfold with AI. The foundations of how and with what we work are changing again.

The Next Layer in a Long History of Layers

Grady Booch said something that keeps echoing in my head: "The entire history of software engineering is one of rising levels of abstraction."

Think about it. Assembly to C. C to Java. Manual memory management to garbage collection. Each step along the way, we stopped caring deeply about something that used to be considered essential knowledge. Nobody writes assembly by hand anymore except for very specific niches, and nobody considers that a loss.

For me, AI is just the next layer in that same evolution. Developers don't need to write 100% of the code anymore, we just need to describe what we want and validate what comes out. In my perception, for web development at least, writing everything by hand is simply not needed anymore. The mundane code, the CRUD operations, the forms, the validations, the boilerplate that we've all written a thousand times, AI handles all of that perfectly fine.

Now, I'm not saying AI can handle everything. Low-level stuff like compilers and operating systems still needs human eyes. Critical niches like finance, healthcare, and security require a level of scrutiny and accountability that you can't delegate to a machine, yet. But for everyday web development and most of the niches out there, the stuff most of us do day in and day out? Let the AI cook while you focus on what actually matters.

My Daily Work Looks Completely Different Now

My workflow used to be reading documentation, fighting with syntax errors, and manually writing code line by line. Alt-tabbing to the browser to see the change, back to the IDE, back to the browser, the SQL query is wrong, back to the IDE. That was the job. That's what being a developer meant for most of my career.

Now? I'm orchestrating agents, managing workflows, and running two or three features in parallel while different AI models work in the background. I'll let Gemini handle the frontend components while Claude Opus 4.5 takes care of the backend logic. Spin up a specialized agent for database work. Review all the outputs, make sure everything connects properly, and ship.

The actual process looks something like this: I start with a PRD, a product requirements document with user stories describing what the feature should do. I generate the initial draft with AI help, then I review it carefully to make sure we're actually building the right thing. That's validation layer one, and it's probably the most important one because no amount of perfect code matters if you're solving the wrong problem.

Then I let the LLM run and implement the feature based on that PRD. When it's done, I do a code review. And I'll be honest here, I don't review 100% of the code anymore. I focus on the parts that matter most: the critical business logic, the security touchpoints, the architectural decisions that will affect maintainability down the road. The rest I trust to the process.

Finally, when a PR is created, I have CodeRabbit review it in CI. Another set of eyes catching issues I might miss, patterns that don't match our codebase, potential bugs that slipped through.

Three layers of validation: PRD review, selective human review, automated review. I'm not reading every line anymore because that's not where my value lies. My value is in judging what deserves attention and making sure the whole thing actually solves the problem it's supposed to solve.

The Skills That Actually Matter Now

If a junior developer asked me today "what should I focus on learning in 2026?", I wouldn't tell them to master React or learn TypeScript deeply. Those things aren't worthless, but they're not where the real leverage is anymore.

I'd tell them to focus on problem resolution, on becoming a better thinker, on developing management skills even if they never want to be a manager, and most importantly, on learning to communicate ideas clearly. All human skills. None of them are about syntax or frameworks.

The future of software engineering isn't about knowing which new function got added to the latest framework release. It's about understanding flows, developing new ways of thinking, finding new ways to deliver value. There's this concept floating around called the "Ralph Wiggum software engineer", where you're essentially orchestrating AI to handle the implementation while you focus on the thinking and validation layers. That sounds like a joke, but it's closer to reality than most people want to admit.

What a Single Developer Can Do Now

Here's a concrete example of what this shift actually means in practice: I'm currently working on an ERP system with AI agents designed for small business owners. This is a substantial project, the kind of thing that would normally take years to see the light of day even with multiple developers working on it.

I built it for my company in 6 months. Just me. Learning new agentic frameworks along the way, figuring out agent setups and orchestration patterns, developing entirely new workflows that didn't exist a couple years ago. Actually, I said years? I mean months. That's how fast this is moving.

That simply wouldn't have been possible before. Not even close. The scope of what a single developer can accomplish has expanded dramatically, and we're still figuring out what that means.

The Bottom Line

The future of software engineering isn't syntax, and honestly, it never really was. We just couldn't see that clearly because we were too busy fighting with the mechanical parts of the job.

The real work was always about turning ambiguity into clarity. Figuring out what to build and why. Judging what truly matters when you can't do everything.

AI just made that obvious by taking away the parts that were obscuring it.

So embrace the change. AI is here to stay, and even if it somehow turns out to be "just a bubble" like some skeptics claim, it's fun as hell right now.

Become a layer. Stop being a typer.


How has AI changed your daily workflow? I'm curious if others are seeing the same shift from writing code to orchestrating systems. Find me on Twitter or GitHub.

NORMAL • Press ? for help