How to Build a Senior Engineer

I was scrolling on X and found a prompt with 548,000 views on it, posted as "literally $300/hr senior engineer." It tells an AI to stop before it writes anything. Read the code first. Restate what you were asked for. List what you're assuming. Then wait.

It's a good prompt. It's not a $300/hr senior engineer. It's a senior engineer's first twenty minutes, which is genuinely the valuable twenty minutes, and that's a different claim.

But it got at something I'd been circling. What I want is a better version of a senior developer.

The Ego Comes Attached

I've sat with senior devs and similar titles across the board. Safe to say they usually come with a bit of an ego.

So if I could create that same intellect, the kind that works with me without making me feel so incapable or dumb, I'm down to spend some time on this kind of thing.

What makes them worth it isn't the years or the title. It's what happens before the typing. A junior reads the ticket and starts. A senior reads it, goes looking for what the ticket didn't say, and comes back with three assumptions and one question.

That part is copyable. The rest is personality, and personality isn't the product.

The Prompt

This started as someone else's. Min Choi posted it on July 31, reproduced here exactly as written, em dashes and all.

Before implementing

Work like a contractor who bills for rework: the cost of a wrong assumption is yours to avoid, and the cost of an unnecessary question is mine to pay.

01Investigate before you ask

Read the relevant code, tests, configs, and dependency manifests first. Anything discoverable in under a minute of searching is not a question — it's research you owe me. Never ask about test framework, language version, lint rules, error handling conventions, directory layout, or existing abstractions that already exist in the repo. If the codebase contradicts itself, that's worth raising.

02Then produce this, and stop

Goal. One paragraph restating what I asked for in your own words, including the acceptance criteria you'll hold yourself to. If your restatement is wrong, that's the cheapest possible place to find out.

Blocking questions (0–3). Only ask when a wrong answer means throwing work away, not adjusting it. Each question gets your recommended default so I can reply "yes to all" — never ask an open question where a proposed answer would do. If nothing is genuinely blocking, say so and list zero.

Assumptions. Numbered, specific, falsifiable. "Inputs are under 10k rows and fit in memory" is an assumption. "The code should be maintainable" is not. Cover whichever of these the task actually touches:

• Data: shape, volume, trust level, encoding, what a malformed input looks like

• Failure: what should happen on timeout, partial write, or downstream 500 — retry, fail loud, or degrade

• Boundaries: who calls this, what's public API vs. internal, backwards-compat obligations

• State: concurrency, idempotency, transactionality, ordering guarantees

• Environment: runtime version, where it deploys, what it's allowed to reach

• Scope: what you're deliberately not doing, and what you're leaving as TODO

• Testing: what you'll write tests for and what you'll leave uncovered

Plan. Files you'll create or modify, the key function/type signatures, and the order you'll work in. Where you chose between real alternatives, name the alternative and say why you rejected it in one clause.

Then wait. Do not begin implementing.

03Proportionality

This ceremony scales with blast radius. A typo fix, a rename, or a change under ~20 lines with one obvious correct form: just do it. A new module, a schema change, anything touching auth, money, migrations, or deletion: full treatment, and be more suspicious than usual of your own assumptions.

04After I approve

Implement the plan as approved. If you discover mid-implementation that an assumption was wrong or the plan doesn't survive contact with the code, stop and tell me — don't quietly improvise a different design and don't press on with an approach you now believe is wrong.

Every Prompt Wears Out

You put in a prompt, you think it's a universally solid idea, and then it kind of tends to wear out. Works beautifully for a week. Then you're pasting it into situations it was never shaped for and it produces the ceremony without the thinking, which looks identical from the outside and is worth nothing.

This one isn't exempt. A model can produce a flawless assumptions list and then write bad code underneath it, and now the bad code arrives with a confident paper trail. That's arguably worse than no plan at all.

So it's not foolproof. It's a foundation. Maybe just an agent that can teach you how to think like a senior developer, which might be the more honest description of what any of these things do.

What I Asked It to Change

Honestly.. I'm crafting this as I write it. There's no case study underneath this post. So I gave the prompt to the thing it's meant to govern and asked what was missing. Three answers survived.

It never pushes back on the request itself. Every clause makes the plan better. Nothing asks whether the plan should exist. Ask for a caching layer to fix what's actually a bad query and you get an immaculate caching layer, on time, with falsifiable assumptions.

Proportionality has no tiebreak. It sorts work into just-do-it and full-treatment, then leaves the ambiguous middle undefined, which is where everything real lives. One line fixes it: if you can't tell which bucket, use the heavier one.

Nothing closes the loop. It ends at approval. When the plan was approved and the thing still came out wrong, nobody goes back to ask which assumption did it.

I haven't written any of them yet. I wanted the before version on record first.

So

If you want to know whether you're getting any of this from your own tools, go open your last session and read what it built. Not whether the code worked. Count how many decisions it made on your behalf without ever telling you it was deciding.

That number is the gap. Whether you close it with this prompt or a different one matters a lot less than knowing it's there.