Updated Priors

Human impressions on technology

AI as Power Suit

Bobby Draper, the Martian Marine from the Expanse series, is a badass.

We first meet her when she’s the only one standing after a monster tears through her unit on Ganymede. Later, when a yacht’s security detail cuts comms rather than admit they’re holding the UN representative she’s protecting as a hostage, she fights her way through the bulkheads to the bridge and takes the ship back single-handed. She does all of this because of her not-so-secret weapon: her power suit.

The suit gives her superhuman strength, augments her fighting capacity, gives her weapons. But it doesn’t negate her. She herself is strong. She knows her suit from the inside out. She maintains it. She tunes it. She takes it apart and reassembles it, customizing it to fit how she moves.

This is an appropriate metaphor for software engineering in an agentic era.

Our power suit runs on large language models—the agentic coding tools, the customized skills and workflows we tune to our personal practice. We’re much like Bobby when we bring our own craft, attention, care, and the embodied knowledge of what we’re building to how we use them.

But there’s a real danger in the default mode of the suit. And it’s worth exploring before we talk about how to wear it well.


The convergence danger

There was a time when people were sharing the best prompt. “One simple trick!!! Tell ChatGPT ‘I will be fired if you don’t do a good job!’ and it will try harder.” I don’t see those circulating as much anymore, but their echoes are everywhere—people still hoarding and trading in silver bullets, each promising to unlock something the others can’t.

The consequence is a kind of convergence: if everyone is trying to accomplish the same thing the same way, we all become interchangeable. While it may deliver velocity for us in the short run, collectively and in the long run, we’ll be weaker for it.

This fault is baked into the system. The training set of large language models gives them both their power and their weakness. At their most basic level, they are prediction machines. That default pull is toward the predictable—the average of the internet. The most likely thing for anyone to say next, which means the least distinctive thing you could say. Alberto Romero named this pull “the land of averages”.

Two related failure modes follow from this. The first is the drone operator problem: using the suit without bringing anything yourself, treating it as a shortcut rather than an amplifier. The second is subtler and more insidious for someone who is trying to use these tools well: the self-reinforcing closed loop, where the language model and you agree with each other, and you mistake that agreement for reality. While it appears you are making great solo progress, you’re actually sliding into the crater on regolith that won’t hold.

We don’t abandon the suit, but this is a cautionary map of where it pulls when left to its own devices: it either walks off without you, or it keeps amplifying whatever you were already leaning into.


The strength you bring

Bobby has superhuman strength inside her suit, but she’s no wimp outside of it. She maintains her own physical training to keep herself sharp.

What we bring as practitioners is that same kind of strength—our craft, our particular styles, our unique tastes. The discernment that comes through experience. The self-knowledge of what we’re good at and, just as importantly, what’s worth deferring to the suit.

I’ve found that I’m not at my best when I try to be a master of all. There are many things I’m below average on, or that just aren’t what makes my contributions unique. Those are what I defer to the suit. Some may call it laziness. I call it knowing what I have to offer and what I don’t need to spend myself on.

Craft matters because language models are a tool, and you need to know to what ends you’re wielding it. Our own experiences and strengths shape how we work. The suit should amplify those, not replace them with the internet’s average.

For instance, I no longer waste my brain cells on variable names. Gone are the days when I stare at my screen and then type result_as_string and hope that I come up with a better name before I submit the PR. LLMs are much better at coming up with names that are good enough and it’s just not worth my time to care.

The inverse is also true: the better defined your taste, the more strongly you can use the suit. A well-articulated sense of what makes something good is its own kind of direction: a clear interface, a test that exercises behavior at an appropriate level of abstraction to enable refactoring, a system that can evolve with a fuzzy roadmap. It’s what lets you point the suit at your intended destination rather than drift toward what’s average.


We’re insufficient inside our own suits

There’s a well-known meme at this point about AI sycophancy: the “you’re exactly right” problem, where the model will collapse in agreement with you at your first correction. It’s obvious enough that most of us have trained ourselves to catch it—to stop and ask whether we’re really as brilliant as it’s telling us, or whether we’re just being gaslit.

But there’s a more subtle version that’s harder to spot. This is genuine agreement: your thinking and the model’s default pull happen to align. You’re not being flattered. You’re being reinforced. And because it feels right, you keep going. The model makes it coherent and polishes the position you bring to it. You can’t immediately spot the flaw.

I learned this the hard way working on a feature in a Remix codebase, back when I was still wrapping my head around how Remix contrasted with my more comfortable territory of Python backends. I’d imported a number of principles from my own approach to shaping the feature. I ran it past my code agent, and it affirmed my hypotheses: “Yes, your reasoning makes sense. Carry on.”

When a colleague reviewed it, they said it had some major flaws and should be structured a completely different way. I went back to the agent with that feedback, and it doubled down in agreement with me. “Your original approach was right. Do it the other way, and it’ll add way too many layers of abstraction.”

I decided to humor my colleague and have something concrete to prove them wrong. I asked the agent, as a test: “Play along with me. Build it this other way.” It did. And I stepped back and realized the colleague was spot on. The resulting interface was cleaner, simpler, more along the grain of Remix. I learned principles I wouldn’t have otherwise.

Only because I had a colleague with a different perspective was I able to grow stronger.

This is the flip side of the strength you bring. The same particularity that makes you valuable also shapes your blind spots. The Remix story is about insufficiency. You aren’t enough, inside your own suit, to see what you can’t see. The way out is someone who doesn’t share your dialect. Diversity—of background, of approach, of the kind of engineering you do—is the break-open mechanism.


What indwelling looks like

Bobby’s suit isn’t the top of the line or the newest model. But it’s effective because it’s hers.

This is indwelling, not drone-operating—the suit doesn’t drive, I do.

The way I bring my unique approach—steering whatever models I’m using toward test-driven development—is one example. Over the years I’ve developed a particular mixture of TDD, extreme programming practices, and domain-driven design that suits me well.

I force the language models to write failing tests and verify they fail as expected before writing minimal app code. They’d prefer to write tests afterwards as it seems to be more natural to them. I don’t care. This methodology is what works for me. I can design interfaces iteratively. I can spot where we need to step back. I’ve chosen a workflow that refuses the suit’s natural path.

It’s because of this approach (and my occasional yelling “wait, did you just start coding without writing any tests?”) that I’m able to review agent-written code well: reading the tests, noticing the gaps, and spotting when it’s time to refactor by feeling the tension that builds up in awkward, repeated test code.

This hasn’t been static. Much like Bobby taking apart and reassembling her suit for maintenance, I’m constantly observing how these processes run and how they change as model capabilities evolve. I adjust them to stay in line with how I work well. The result is that the suit conforms to my body more and more over time. My Pi harness—the open-source coding agent I’ve built my own practice around—is highly customized for how I work, and it’s in a constant state of evolution (perhaps more on that another time).


What I’m still sitting with

There are a few things I haven’t figured out. And honestly, anyone claiming they have is selling something.

The first is atrophy. I can do more “power push-ups” with the suit than without it. But what muscles are atrophying because we keep the suit on too long? I’m doing a lot more reading and reviewing of code these days, and hardly entering any of the individual characters that I end up shipping. This gives me an incredible ability to make architectural decisions and see their consequences faster. But is there something about feeling the texture of shaping a particular function by typing out the characters that I lose? And how do I maintain the skill I’ve honed over years, when the path of least resistance is to let the suit do the typing?

The second is the pull of the solo loop. I can get a lot done when I’m working one-on-one with an agent. It works on my schedule. It tells me how smart I am. And though I know a decent portion of the time I’m being gaslit, the average of the internet tends to agree with me. How and when do I pull in others, so that someone can actually point out the blind spots I’m reinforcing?

The third is the next generation. If writing code by hand is going the way of the punch card—and it may be—how do we bring up engineers who never did the reps? There’s something about struggling through the wrong approach, about typing out a function keystroke by keystroke, that builds intuition you can’t shortcut. Maybe it’s creating a workflow where you reserve certain pieces to write yourself. Maybe it’s targeted comparison—looking at different versions of the same function and evaluating which is more effective. Or maybe it’s an approach that someone with a different perspective still has to invent. I don’t know what the answer is.

None of that stops me from heading out the airlock tomorrow. It just means I keep my eyes open while I do.


Let’s strap on our power suits and go exploring.