Becoming the Prediction Machine

Source: Dev.to

Introduction

I need to tell you something I’ve been afraid to admit.

I don’t write most of my code anymore. An LLM does. Or, more accurately, many do. And the work, at times, has never been better.

This weekend, I built a playable proof‑of‑concept web game in about ten hours. Not a toy, not a “look, it renders a box” prototype—a full vertical slice: multi‑panel UI, timed choice system, email and phone pipelines, a script runner, a music state machine, a narrative spine—all working together, all clean, all stable. I didn’t type a single line of code. And I keep waiting for that to feel wrong. It doesn’t.

If you’re reading this and you’ve felt that same guilt—that nagging sense that maybe you’re cheating, that maybe this doesn’t count as “real” development, that maybe you should be ashamed of how fast you’re building now—this is for you. Because what I’m about to describe isn’t a confession. It’s permission.

What Actually Happened

People keep trying to describe this era in terms of productivity.

• “AI helps you code faster.”
• “AI accelerates development.”
• “AI boosts output.”

That framing misses what’s actually happening.

What changed this weekend wasn’t how fast I typed. It was that typing stopped being the bottleneck at all.

For the first time in my career, the slow, physical act of turning ideas into syntax disappeared. Not because the system was designing anything for me—it wasn’t—but because it was serializing my thinking directly.

• I held the architecture.
• The constraints.
• The mechanics.
• The emotional beats.

The model just wrote them down at a pace the human body was never built for.

LLMs serialize human intention. That’s it. That’s the whole thing.

They take structured internal cognition—architecture, reasoning, emotional framing, narrative beats, system constraints—and convert it into external form faster than a human body can type.

Nothing mystical. Nothing emergent. Nothing like “intelligence” in the human sense. Just serialization.

1. You form a mental model →
2. You describe it at the right level of abstraction →
3. The LLM instantiates it into code, prose, diagrams, or docs.

The bottleneck used to be translation—your hands, your typing speed, the mechanical act of expressing what you already knew. Now the bottleneck is gone. The LLM is the output layer of your cognition.

You don’t work faster because the model is smart. You work faster because you escaped the I/O limitations of flesh. You’re still doing the cognition. The model is doing the serialization.

If you’ve been working this way and feeling guilty about it—stop.

This is the actual work of software development.
The thinking. The architecture. The design. The constraints. The intent.

The typing was always the mechanical part. We just didn’t have a choice before.

What You’re Actually Giving Up (And Why It’s Worth It)

The Trade‑off

• Gave up: The ability to say, “I wrote every line myself.”
• Gained: The ability to build faster than I can type.

Some people will say that’s not a fair trade. Those people have never felt the difference between working at typing speed and working at thinking speed.

How the Workflow Actually Looks

I don’t tell the model “build me a game” and walk away. I don’t ship code I haven’t approved. I don’t push things I’m not happy with. That would be reckless, unethical, and ineffective.

What I don’t do anymore is treat typing as the work. What I do is watch the shape:

• Does this reducer do one job?
• Does this component have a single source of truth?
• Is the state machine coherent?
• Is the audio engine isolated?
• Are scripts declarative?
• Do the boundaries make sense?

I guide direction. I interrupt when the form is wrong. I make architectural decisions mid‑stream. It’s not “hands off.” It’s eyes on the blueprint, not the bricks.

Example Prompt

“So what story do we actually have narratively so far? Let’s lay out what we do have and what’s missing.”

That’s it. No instruction hierarchy, no role assignment, no formatting tricks. It’s exactly what I would ask myself—or a rubber duck—if I were thinking through the system alone.

The response was a structured breakdown of narrative beats, gaps, dependencies, and next steps—exactly what I needed at that moment. Why? Because that sentence was lossless compression of shared context. By the time I asked, the model already knew:

• the project
• the genre
• the emotional spine
• the constraints
• the MVP scope
• what “narrative” meant in this context
• what “missing” implied relative to what we’d already built

It wasn’t a request for creativity; it was a request to rehydrate shared context and reflect it back—collaboration inside a high‑bandwidth conversation.

When I open the code later, I’m not lost. Every file exists because I asked for it to exist. Every abstraction matches a shape I already had in my head. Every system boundary reflects a decision I made upstream.

It feels unfamiliar, like a freshly cleaned room—someone else did the sweeping, but the layout is still yours.

I inherit the same responsibilities as any lead developer on a team:

• I trace.
• I understand.
• I correct.
• I refactor.

The difference is efficiency. Instead of spending hours laying scaffolding, I spend minutes adjusting intent. The maintenance cost is normal; the creation cost collapses. That’s not cheating—that’s using the right tool for the job.

Why This Feels Like Cheating (And Why That’s Wrong)

If you feel guilty working this way, I know where that feeling comes from.

We were trained to believe that typing code is the work. That if you didn’t manually place every semicolon, you didn’t earn the result. That real developers suffer through boilerplate, because suffering is how you prove you’re serious. That’s not engineering ethics; that’s trauma from a world where typing was the only option.

No one says a carpenter is cheating because they use a table saw instead of a hand saw. No one says an architect is cheating because they use CAD instead of drafting by hand. No one says a writer is cheating because they use a word processor instead of a typewriter.

But somehow we’re supposed to believe that using a machine to serialize architectural thinking is lazy, inauthentic, or “not real development.” That’s nonsense.

You’re doing the hardest part:

• the thinking
• the architecture
• the design
• the constraints
• the intent

The model is doing the part that was always mechanical.

What the Model Cannot Do

• Choose the architecture.
• Decide what makes a system elegant.
• Name the right abstraction.
• Feel when a design is wrong.
• Care about user experience.
• Hold ethical weight.
• Generate meaning.

What the Model Can Do

Generate ten thousand lines of scaffolding the moment you know what the shape should be.

Developers who pretend this isn’t happening will be left behind—not because they lack skill—but because they refuse to let go of a bottleneck that no longer matters.

You already found the new workflow. You already know it works. You’re just waiting for permission to stop apologizing.

Here it is: stop apologizing. You’re not cheating. You’re architecting at the speed your mind was always capable of—now that your hands aren’t in the way.