Dev reflection - January 25, 2026

Hey, it’s Paul. January 25th, 2026.

I spent part of today watching a game fall apart in my hands. Not because it was broken—technically everything worked fine. It fell apart because I’d confused being clever with being usable.

Here’s what I mean. I’d been building this space station game where characters make their own decisions each turn. The station commander—that’s you—is trying to figure out who’s sabotaging the equipment while managing resources and keeping everyone alive. The interesting part was supposed to be that the saboteur isn’t following a script. She’s actually responding to what you do, making contextual choices about when to act and when to lay low.

And that part worked. Beautifully, actually. The problem was everything else.

I sat down to play and lasted maybe five turns before my fingers hurt. I was typing out full sentences for every action. “Walk south to the engineering bay.” “Examine the mining console carefully.” “Check the status displays for anomalies.” Meanwhile, text adventures figured out in 1980 that you could just type “S” to go south. I’d been so excited about the AI understanding natural language that I forgot people don’t want to write essays to move through a room.

There’s a lesson here that goes way beyond games, and it’s one I keep relearning: sophistication in one part of a system doesn’t excuse neglect in another.

Think about it this way. You can build the most intelligent, responsive, contextually aware backend in the world. If the way people interact with it is tedious, none of that matters. The experience isn’t the sum of the parts—it’s constrained by the weakest interaction point.

This shows up everywhere. I’ve seen enterprise software with genuinely powerful capabilities buried under interfaces that require seventeen clicks to do basic tasks. I’ve seen AI tools that can analyze anything you throw at them, but the process of throwing things at them is so cumbersome that people just… don’t. The capability exists. The experience doesn’t.

What’s interesting is why this happens. And I think it’s because building the sophisticated part is more fun than building the boring part.

Getting an AI character to make contextual decisions based on game state? That’s interesting. That’s the kind of problem you want to solve. Adding keyboard shortcuts so people don’t have to type full sentences? That’s tedious. It’s not intellectually stimulating. It doesn’t feel like progress.

But here’s the thing: the tedious stuff is often what makes the interesting stuff matter.

I added single-letter shortcuts. N for north, S for south, L for look around. Suddenly the game was playable. Not because the AI got smarter—it was already smart. Because the friction between me and the AI got smaller.

There was another problem, too. The game would describe things beautifully. “The mining equipment hums with a slightly irregular rhythm, its displays casting pale blue light across the metal floor.” Very atmospheric. Completely useless for figuring out what was wrong.

I needed numbers. Power allocation: 60 kilowatts. Optimal: 100. Equipment efficiency: 87%. That’s information I can act on. The atmospheric description tells me something feels off. The numbers tell me what to do about it.

So I added both. The AI still narrates the scene—that’s what makes it feel alive. But now there’s also a diagnostic readout underneath. Poetry and data, working together.

This gets at something I’ve been thinking about a lot lately: the question of appropriate technology. Not “what can AI do?” but “what should AI do in this specific context?”

The answer isn’t always “everything.” Sometimes the answer is “this one particular thing, while other tools handle the rest.”

In the game, AI handles narration and character decisions—the parts that benefit from flexibility and contextual awareness. But movement shortcuts are just simple text replacement. The diagnostic system is just calculations from game state. No AI needed. Each piece uses the tool that fits.

This feels like a broader principle for building things right now. We’re in this moment where AI can do so much that it’s tempting to use it for everything. But “can” isn’t the same as “should.” A hammer can drive a screw if you hit it hard enough. Doesn’t mean you shouldn’t use a screwdriver.

The interesting question is how you decide. When does AI add value versus add complexity? When does sophisticated capability justify itself versus when does simple reliability win?

I don’t have a complete answer, but I have a heuristic that’s been useful: AI excels at handling variation. Simple tools excel at handling repetition.

If you’re doing the same thing over and over, you want it to be effortless. Keyboard shortcuts. Saved templates. Automation that just runs. You don’t need intelligence—you need reliability.

But if each situation is slightly different, if context matters, if you need to respond to things you couldn’t predict—that’s where AI shines. The saboteur in my game doesn’t follow a script because each game state is different. The narration adapts because each moment has different details worth emphasizing.

The sweet spot is systems that use both. Repetitive actions get streamlined. Variable situations get intelligence. You’re not choosing between AI and traditional design—you’re choosing where each one fits.

This connects to something else I ran into today. I’d written guidelines for how I want things to sound—my voice, my perspective, the way I think about problems. Those guidelines existed. But the system generating content wasn’t actually following them.

The problem wasn’t that the guidelines were wrong. The problem was how they were being used. The system was treating my work as the subject—describing what I built, explaining my process—when it should have been treating my work as source material for broader ideas.

That’s a subtle distinction but it matters enormously. “Here’s what I did today” is a developer log. “Here’s what I noticed while doing something today” is an essay. Same raw material, completely different output.

The fix was reframing the entire task. Instead of “summarize this work,” it became “extract the ideas this work surfaced.” Instead of “describe the system,” it became “talk about what the system reveals about how things work.”

What’s interesting is that this required being more specific, not less. I had to explicitly say “don’t start with ‘I built a system that…’” I had to provide examples of how to translate jargon into accessible concepts. I had to frame the whole thing as essay writing rather than technical documentation.

There’s a tension here that I think matters for anyone working with AI right now. The more specific you are about what you want, the more constrained the output. But the less specific you are, the more you get generic AI writing that sounds like everyone and no one.

The solution isn’t to be less specific. It’s to be specific about the right things.

The old approach was specific about structure—opening section, middle section, closing section. Very organized, very predictable. The new approach is specific about perspective—think like this, avoid saying that, translate these concepts this way. Looser structure, tighter voice.

Turns out structure is less important than perspective. You can vary the structure and still sound like yourself. But if the perspective is wrong, no amount of structural consistency helps.

This is true for AI-assisted work but it’s also true for delegation in general. When you hand something off—to a person, to a system, to an AI—what matters most is whether they understand how you see the problem. The mechanics can be figured out. The worldview has to be transmitted.

So that’s where I am. Two different problems from today that turned out to be the same problem: the gap between capability and experience.

The game had intelligent characters but tedious interactions. The content system had good guidelines but wrong framing. In both cases, the sophisticated part was working. The basic part wasn’t.

And in both cases, the fix wasn’t to make the sophisticated part more sophisticated. It was to pay attention to the boring stuff. The shortcuts. The data displays. The explicit instructions about what not to do.

The boring stuff is where the experience lives.

I keep coming back to this idea that the best systems are invisible. Not because they’re simple—they might be incredibly complex underneath. But because the complexity serves the user instead of demanding attention from them. You don’t notice good tools. You just notice that the work is easier.

The game is playable now. The content sounds more like me. Neither change required breakthrough thinking. They required noticing where the friction was and caring enough to reduce it.

That’s usually the work. Not the clever part. The careful part.