by Bruno Campos

🎭 The Job Is Changing Under Our Feet

If you’ve spent any real time with agentic tools, you’ve probably felt it: your job changing shape while you were busy using it. I wrote about this in The Agentic Enlightenment Ladder, the climb from sceptical copy-paster to someone orchestrating a small fleet of agents. That post was about the tools. This one is about you, and what you turn into once you’ve climbed a few rungs.

Because here’s the thing nobody quite says out loud. Once you’re up that ladder, you stop writing most of your code. You describe, you delegate, you read, you approve. And if you’re honest, most of your “coding” day is now reading, not typing. So what does that make you? Still a “software developer”? The title fits worse every month.

I want to make a claim and spend the rest of this post earning it: the programmer’s role is quietly shifting from producing code to deciding what code deserves to exist. The typing was never really the job. It was just the interface we happened to have.

Let me come at that from two directions before I bring them together.

♾️ Abstraction Only Goes One Way

I like to think of abstraction as a kind of entropy. It only ever increases. As a society, and as an industry, we are quietly doomed to understand less and less about what makes the things we love actually work. And crucially, that is not a tragedy. It’s the whole point.

Every generation of technology buys its power by hiding the layer beneath it. You get to stop caring about the thing below so you can think about the thing above. We do this constantly, and we’ve made our peace with almost all of it. The only reason AI feels different is that the letting-go is happening right now, in front of us, instead of a comfortable decade ago.

People shudder and say “I don’t know how AI works” or “I want to know what it’s actually doing.” Fair enough. But let me ask you something first.

⌨️ Exhibit A: The Letter “a”

Do you actually know what your computer does when you press a single key? Genuinely, end to end?

Here’s the short version, and it is genuinely humbling. You press “a”. Under the cap, a switch closes at one intersection of a grid, and the keyboard’s own little microcontroller (yes, your keyboard has its own computer) scans that grid, waits a few milliseconds for the contact to stop physically bouncing, and emits a code for the key’s position, not the letter. Not “a”. Just “the switch at row X, column Y went down.” That code races down the cable and, one way or another, yanks the CPU off whatever it was doing: a hardware interrupt, mid-stride, forcing the processor to save its place and jump through a table of addresses to a tiny handler in the operating system. The OS reads the code, then a keymap layer combines it with your held modifiers and your chosen layout (QWERTY, AZERTY, whatever) and only now decides this means the character “a”, which to the machine is simply the number 97. The window system hands that number to whichever app you’re focused on. The app drops 97 into a text buffer and says “please redraw.” To draw it, a shaper looks up which glyph 97 maps to in your font, a rasteriser takes that glyph’s mathematical outline and scan-converts it into a little grid of grey values, and those pixels get painted into a slab of memory called a framebuffer. Your GPU reads that memory out, over and over, sixty-plus times a second whether anything changed or not, serialising each pixel down an HDMI or DisplayPort cable. And at the far end your monitor, which has its own processor, decodes the stream and drives the panel: switching on one row of tiny transistors at a time and setting a voltage per subpixel that changes how much of the backlight’s red, green and blue leaks through the liquid crystal. That mix of three brightnesses is one pixel. Enough lit pixels in the right shape, and you finally see: “a”.

And here’s the kicker. At no single point in that entire chain was there ever a letter “a”. There was a switch position, then a scancode, then a keycode, then the number 97, then a glyph ID, then a spray of pixel values. The CPU running “your program” is only ever doing one thing: fetch an instruction, decode it, execute it, repeat, billions of times a second, shuffling numbers between registers and memory. That is machine code. Your beloved Python, your Rust, your TypeScript, all of it is compiled or interpreted down to those same dumb little opcodes, because that is the only language the silicon actually speaks. Assembly is just a human-readable coat of paint over the numbers.

Do you know all that? Some of you do. And if you do, I’d bet it’s because it’s interesting to you. A hobby. A rabbit hole you enjoyed (🙋‍♂️ that’s me). It is almost certainly not because your job required it. You write your nice high-level language, you type some magic words into the magic box terminal, and out the other end comes compiled code you can ship to production and (allegedly) make millions. You already let go. You already accepted ignorance of everything below your chosen layer, and you did it so long ago you don’t even feel it as ignorance anymore. You just call it “not my problem,” which is exactly right.

We do this inside tech, too, constantly. There are people employed as engineers right now who can’t rattle off the git commands to save their life, because their GUI does git push --set-upstream origin <branch> in a single satisfying click. Ten years ago someone would have tutted at that. Today it’s just Tuesday. The friction got abstracted away and the world kept turning.

AI is not some alien break in this pattern. It’s the next click of the same ratchet. The only thing new is that the layer being hidden this time is the code itself.

🕹️ Maybe AI Isn’t the Answer. It’s the Interface

Here’s a second way to read what’s happening, and I think it’s the more useful one.

Look at the wave of “AI wrapper” products that launched over the last couple of years. Strip away the marketing and most of them aren’t selling you AI at all. They’re selling you the same core product that already existed, with a new way in. The solution isn’t the AI. The solution is whatever it always was. The AI is the interface.

There are genuine exceptions, the companies actually training models, distilling them, fine-tuning, wiring up serious retrieval. Those folks are selling the AI itself. But they’re rarer than the hype implies. For most of what you touch, the LLM is a doorway, not the room.

And once you see it as an interface, something clicks: we have been here, over and over. The story of computing is really just the story of how we humans talk to machines, and that story has changed shape maybe five times.

🗣️ A Short History of Talking to Machines

In the very beginning it was brutally physical. You flipped switches and patched cables and set circuits by hand, you fed the machine its state directly, and you read the answer off blinking lights and translated it yourself. Then came punch cards and batch jobs: you’d write your program onto stiff bits of cardboard, hand the stack to an operator, and come back hours later to find out you’d made a typo on card 43. Interaction, but with a delay measured in coffee breaks.

Then came the terminal, and honestly, in my opinion, the purest form of talking to a computer we’ve ever had. A blinking cursor and a handful of commands. You no longer cared about the hardware underneath. You just told it things and it did them. (Terminal supremacy, always and forever. I will not be taking questions.)

Then the graphical interface arrived, and with it the era of the mouse and keyboard, and for decades that was simply the best we had. Now, pause here with me, because this is the important bit.

What does it actually mean for the GUI to be your interface? It means that to use any given program, you first have to learn it. You have to learn the hidden menus some developer chose, at some point, in some meeting, and buried three clicks deep under an icon that made sense to them. Take Photoshop. I have almost no hours in it, and every time I’m forced near it I have a small panic attack. There are entire university courses whose real content is “how to operate this one specific program.” And that program just happened to be the popular one. If a better one came out tomorrow, every one of those people would have to relearn it: new menus, new buttons, new layout, new muscle memory. Think of anyone who grew up in Microsoft Word being handed Google Docs. Unless they use it daily, they still don’t quite feel at home. Same job, different hidden menus, and the brain has to re-file everything.

I’m dragging us through this to make one point: developers, and therefore their programs, were always making the best of the IO they had. (“IO” is just input/output, the channels you use to get information in and out of the machine: what you can do to it, and what it can show back to you.) The IO of that era was a mouse with two buttons, a keyboard of a hundred keys, and a 4:3 screen. You physically could not put every function on display at once, so you hid them. Menus and shortcuts weren’t a design choice so much as a survival tactic for the interface of the time.

Then the IO changed again, and hard. Multi-touch smartphones showed up and suddenly the input wasn’t a precise mouse and a hundred keys, it was one or two fingers and a small pane of glass. Fingers are fat and imprecise. Screens got tiny. Every assumption broke. Now the buttons had to be on screen, big enough to hit, and a whole new design language, new APIs, new UX theory had to be rebuilt from the ground up. And you’ll remember the teething years: apps that were really just desktop websites in a trench coat, clunky and hostile, until slowly the language of the new interface set, and we got the polished mobile world we now take for granted. And, right on cue, universities started offering degrees in building good apps.

Which brings us to now. There is a new interface, and it is natural language. Not menus, not shortcuts, not commands, not finger taps. You just say what you want. And make no mistake, this is first and foremost a change to user experience, and we have absolutely not figured out how to use it well yet.

Take it from me, I hate having to write a long paragraph of prose to do something I could have done with two clicks in a UI I already knew cold. That’s genuinely worse. But I also love that I no longer have to learn a tool’s hidden menus at all if it exposes an API or an MCP, because I can just tell it what I want and it goes and does it. Both of those are true at once, and that’s exactly what a messy transition feels like. We are, right now, firmly in the “desktop website in a trench coat” phase of natural language. The clunky in-between.

At some point we’ll let go of our pre-2022, pre-defined ideas of what an interface even is, and settle into something genuinely new. And one thing worth saying clearly: the new interface doesn’t have to replace the old ones, and that’s completely fine. It shouldn’t even be the goal. We still have phones and apps. We still have websites and desktops. We still, blessedly, have the terminal. Natural language just joins the shelf. But the way we write and interact with code is going to change all the same. A new interface has manifested. And maybe, just maybe, your screen won’t be 80% covered by something you barely use anymore.

🔀 What Happens When We Actually Trust It

Which is a good moment to talk about that screen.

Look at how most people who use these tools actually work today. A directory tree pinned on the left. An enormous editor window hogging the middle. And a modest little chat box off to the side, where their LLM of choice waits. Notice the proportions. The thing eating most of your visual real estate is still, fundamentally, a text editor. Even for heavy AI users, the code is front and centre and the AI is a sidekick in the margin.

But watch where the time goes. Plenty of us now spend most of the day in that little 20% side panel, talking to the model, and only glance at the 80% to check its work. The layout hasn’t caught up with the behaviour. We keep the editor huge because we haven’t let go, either because we don’t fully trust the output yet, or because we genuinely enjoy the code and don’t want to. In my experience it’s still rare to meet someone whose main development flow is purely the AI window, editor closed. To me that’s the tell: we haven’t cleared the first real hurdle of this new interface becoming a natural part of how a developer thinks.

So let’s imagine we’re past it. Trust is high. You no longer feel the compulsion to keep the editor open and inspect every diff before it goes to a remote branch. What are we actually admitting when we say that?

Think about what it’s like to hand a task to another developer. You don’t hover over their shoulder watching every keystroke (pairing exists, sure, but it’s the exception, not the rule). You align on the plan, they go away and do the work on their own, and the first time you really see the output is, drumroll, their Pull Request. You open the link, read the description, read the diff, leave comments, they push changes, you go again. That loop of plan, delegate, review, iterate is not new. It is the oldest collaboration pattern in software.

Now just swap one actor. Your fellow developer is an autonomous agent. The loop is identical. You align on intent, it goes off and writes and tests and debugs on its own, and you meet its work at the PR. So, uncomfortable question: are we just PR reviewers now?

In a real way, yes. Because if you decompose building any feature, it has always had three layers.

Layer one is context, stakeholders, planning: working out what should exist and why. Layer two is implementation: writing the code, testing it, picking the right tool for the job. Layer three is review: socialising the change, weighing the risk, and applying taste to decide whether you even want it and, if so, how it should be done.

For our entire careers, layer two, the greyed-out middle, was where the hours went. It was the hard, slow, expensive part, so it defined the job. That’s the layer that just got cheap. And when the expensive middle collapses, the job isn’t gone. It’s just been uncovered: the two ends we always cared about most were the planning and the review.

🙅 The Real Skill Is Denying Code

Let me push the thought experiment all the way, because it’s closer to reality than it sounds.

Take the brakes off entirely. Point some absurdly capable model (Fable 6, Sol, whatever the shiny name is this quarter) at your codebase and let it run continuously, scanning for bugs, spotting improvements, hoovering up the issues your users report. That’s layer one, the planning, largely automated too. Behind it, an army of subagents, each picking up a finding and raising a fully-formed, tested PR. The code writes itself and shows up at your door, gift-wrapped, all day long.

Now the last move: merge all of them, automatically, no human in the loop.

Something just went cold in your stomach, didn’t it? Good. Hold onto that feeling, because it’s the whole thesis.

The thought experiment proves that producing code is no longer the hard part. It can genuinely run on tap. The hard part, the part that made you flinch, is denying code. Deciding what not to merge. That instinct that says “no, not like that, not now, not here.”

And what is that instinct actually made of? Two things. The first is risk appetite, and it isn’t yours alone, it has to be aligned with the company’s: how much are we willing to break, in this system, for this reward, right now? The second is taste, which is really just vision wearing work clothes. We could tint the button red. Or we could leave it blue. Neither is a bug. Neither fails a test. It’s a purely subjective call that only makes sense against the vision of whoever the change is really for, the original creators and arbiters of the thing. An agent can generate a hundred valid buttons. It cannot, on its own, tell you which one belongs.

A world drowning in cheap, correct, mergeable code doesn’t need more people who can produce it. It needs people who can look at ten perfectly good PRs and say “these three, not the other seven, and here’s why.” Saying yes is easy and, increasingly, automatable. The value has quietly moved to the no.

🪪 We Don’t Have a Name for This Yet

So if the job is less “author” and more “the one who decides,” what do we call that person?

Honestly, I don’t think the name exists yet, and I’m not here to coin one. But I’ve noticed we keep reaching for the same handful of metaphors, and each catches a different edge of it:

• Reviewer: the plainest one. The centre of gravity is the PR, and the core act is judgement on someone else’s work. It undersells the planning half, though.
• Architect: captures that you’re deciding shape and structure up front rather than laying every brick. Long a real title, now closer to the default.
• Editor: my favourite, and I think the truest. Editors don’t write the book. They commission it, shape it, and decide what’s fit to print. Their signature move is killing darlings, cutting the good-but-wrong. That is exactly denying code.
• Curator: you’re choosing what belongs in the collection and what doesn’t, and the collection has a point of view.
• Gardener: some planting, more pruning. Deciding what to cut back so the whole thing stays healthy. (Regular readers will know I already can’t resist comparing systems to gardens. Especially data systems.)
• Arbiter: the one who settles it. Whether, and how. Yes, or no.

Pick whichever fits your day. They’re all circling the same shift, from the person who makes the thing to the person who decides what the thing should be. And you don’t need to wait for the perfect word, because the change is already happening in front of you. That person with the 80% editor and the 20% chat box? They’re mid-transition and they know it. They’re holding onto the old shape of the job out of trust, or out of genuine love for the craft of the code itself. No judgement. I get it. But watch that ratio over the next couple of years.

🌅 The Job Was Never the Typing

Here’s where I’ve landed, and where I hope this is useful to you rather than just interesting to me.

The role of dealing with code is changing, and it’s changing because we’re climbing the abstraction ladder one more rung. For years the top rung was a high-level language, and everything below it, the assembly, the machine code, the interrupts and the framebuffers, was already a black box we were happy to ignore. Now the language itself is going into the box. You describe what you want, the machine writes the Python (or the Rust, or the SQL), and you test whether it does the thing you meant. Anyone can now check the what without owning the how, and that is a genuinely new and democratising superpower.

None of this means the deep stuff stops mattering. Scalability, architecture, elegant design: all still real, all still valuable. But be honest about when they’re a hard constraint. For most changes, most days, they simply aren’t, not unless you’re actually planning to scale or you’re operating somewhere genuinely high-risk. The rest of the time, correctness you can verify and taste you can defend are what the job is really about.

So if you’ve been feeling the shape of your work change under your hands, and you’ve been struggling to put words to it: this is it. You’re not being replaced. The mechanical middle is being peeled away to reveal what you were actually being paid for all along. Not the typing. The judgement. The deciding what should exist, and the harder, more valuable art of deciding what shouldn’t.

We were never really paid to write code. We were paid to know which code was worth writing. We just used to have to type it out to prove it. Now we don’t. And maybe your screen won’t be 80% covered by something you no longer use.

Peace and Love.