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. Not sure it's worth $300/hr for a senior engineer, but maybe the first twenty minutes.

Could work.

The Ego Comes Attached

I've sat with senior devs and similar titles across the board.

Safe to say they can come with a bit of an ego.

So if I could create that same intellect without having to feel unfit for the conversation, I'd spend some time on that.

From what I know, seniors are good at seeing what a problem is attached to. 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 can be copied. The rest is personality.

The Prompt

This started as someone else's. Min Choi posted on July 31.

Paste one of these at the top of your session, before any work starts.

The original is reproduced exactly as written.

## 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.

### 1. Investigate 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.

### 2. Then 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.

### 3. Proportionality

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.

### 4. After 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 You Don't Get

Honestly.. There's no case study underneath this post.

So I ran the prompt back through Claude and asked what a person would do that this doesn't.

Three differences came back, and they turned out to be the same difference wearing different garb.

It never pushes back on the ask. 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. Just-do-it or full-treatment, with the ambiguous middle left undefined, which is where the details live. One line would fix 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.

Maybe the Ego Is the Point

Here's where I ended up.

The reason a senior tells you your idea is wrong is the same reason they're hard to sit with. That certainty costs you something in the room.

It's also the thing that saves you three weeks.

A prompt won't do that. It'll plan beautifully for a bad idea and never once ask why you're building it.

So maybe the ego is worth the money.

Both of these work. They just work on different things.

One gets you the sequence, the other gets you someone who'll tell you the sequence is pointed at the wrong problem.

If you want the first one without the second, this could work.

So, try it for yourself.