The Case for Professional Pseudocoding

I've been using Claude Code almost every day for over six months now, and the thing that surprises me most isn't how fast it is. It's how quickly it exposes the gaps in my own thinking.

I'll prompt something like "clean up this model" or "make this easier to understand," and the LLM will do exactly that. But these aren't specifications; they're vibes. They don't say what the data model is supposed to produce, what correctness means, which assumptions matter, or which behaviours absolutely cannot change. And the tricky part is that the AI will always give you something. It won't push back or ask clarifying questions - it'll just produce confident-looking code that may or may not do what you actually needed. There's no compiler error for a bad spec.

The gap between a vague intention and a useful specification is where a lot of the work lives now.

I've started calling this professional pseudocoding: the ability to turn messy intent into a specification precise enough that an AI tool, a teammate, or your future self can act on it.

This is not vibe coding

To clarify, I don't think pseudocoding is the same thing as vibe coding. Vibe coding, at least as I understand it, is when you throw a vague idea at an AI tool and keep nudging the output until it sort of works. I actually think that's great for prototypes, experiments, and weird side projects that would otherwise never get built.

But vibe coding is not a good choice when the stakes are high. When the data model has downstream dependencies, cost implications, or historical correctness constraints, the quality of the specification matters a lot.

Professional pseudocoding is more disciplined than vibe coding. It's the ability to describe what should happen, what should NOT happen, what assumptions you're making, and how you'll know whether the output is correct. It's the difference between:

"Make this model cleaner."

and:

This model should produce one row per shop per day; it should exclude test shops; it should avoid scanning the full events table on every run; the output should be partitioned by date and clustered by shop_id; and we should add tests for uniqueness, freshness, and null attribution source.

That second version is not just a better prompt. It's better engineering. The AI can help write the dbt model, but the grain, the correctness criteria, the constraints, and where this model fits in the larger system – that context still has to come from the person building the thing. You can't write a good spec for a system you don't understand. This isn't about "prompt engineering," which involves formatting tricks or model-specific hacks – it's about the thinking upstream of the prompt.

English as the interface

English isn't literally replacing programming languages. Production systems still need real implementation details, but the interface between human intent and executable code is changing. These days, the first version of the code is often written as a description, not as syntax.

This is why I think writing and coding are starting to collapse into each other. A good prompt looks a lot like pseudocode. So does a good design doc, or a good PR description. They all have the same basic shape: here's what this system needs to do, and here's how we'll know if it worked.

Strong technical writing has always been valuable, but AI makes the value more obvious because the feedback loop is so fast. When your instructions are clear, the LLM can move fast. When your instructions are vague, the LLM can also move fast – just in the wrong direction.

Engineers were already doing this

Senior engineers have always spent a lot of their time pseudocoding, even if they didn't call it that. Design docs, RFCs, migration plans, PR reviews – a huge amount of senior engineering work is explaining what should exist before it exists.

What AI changes is that this skill becomes useful much earlier and much more often. You don't need to be writing a six-page architecture doc for pseudocoding to matter. A good issue description, a clear implementation plan, or a precise PR comment are all doing a version of the same thing: turning intent into something another system can act on.

Pseudocoding used to feel like a warmup exercise – something you did in interviews before writing the "real" code. I think it's becoming much closer to the core of the job. If that's true, it changes what we should be investing in. Less time learning new frameworks, more time getting better at describing systems clearly enough that someone/thing else (i.e., your AI agent) can build them.

Code review becomes less about syntax and more about whether the spec was right. The gap between a strong engineer and a weak one increasingly shows up before any code is written.

The tools will keep getting faster, but the thinking is still the hard part.

Until next time ✌️