the planning bottleneck

Planning was always the hard part of software engineering. We just found a clever way to avoid it: we outsourced it to the implementation.

We told ourselves that “the implementation will reveal the requirements.” We used agile cycles as a mechanism to discover what we actually wanted to build. This worked because implementation was expensive and slow, so we could think while we typed.

Now that implementation is cheap, planning debt surfaces immediately.

Thriving in this environment is no longer about being the fastest typist or knowing the most syntax. It is about articulating intent before writing a single line of code.

The Hidden Planning Debt

Agile’s dirty secret is that we often used iteration as a crutch to avoid upfront thinking. “Move fast and break things” was a viable strategy because fixing things was often cheaper than thinking through all the edge cases in advance.

But when implementation is instant, iteration without direction becomes thrashing. You can generate code infinitely fast, but if you don’t know where you’re going, you’re just generating legacy code at light speed.

The bottleneck has shifted. It used to be how fast I could translate a thought into code. Now, it’s how fast I can form a complete thought.

Inversion as a Planning Tool

James Clear talks about “inversion” as a mental model¹. Instead of asking “How do I succeed?”, you ask “What would guarantee failure?”

This is surprisingly effective when working with LLMs. Before I write a prompt, I try to invert the problem: “What would make the model definitely fail at this task?”

• It will fail if it doesn’t know the directory structure.
• It will fail if it assumes we’re using the old API.
• It will fail if it tries to preserve the legacy styles.

Avoiding mistakes is an under-appreciated way to improve. By identifying the failure modes upfront, you define the constraints that the model needs to operate within. You are doing the thinking so the model can do the typing.

What Planning Artifacts Look Like Now

If we can’t rely on “figuring it out as we go,” we need new artifacts to capture our intent. Sunil Pai suggests a “Context Packet” template² that I’ve found incredibly useful for both humans and agents:

1. Goal: What does success look like?
2. Non-goals: What are we explicitly not doing?
3. Constraints: Hard limits, style guides, integration points.
4. Authority order: What to prioritize when constraints conflict (e.g., “Performance > Readability” or vice versa).
5. Repo anchors: Files or patterns to reference as the source of truth.
6. Prior art: Examples of similar work.
7. Oracle: The definition of done. How do we verify this works?
8. Risk/Rollout: What could go wrong?

These artifacts feel heavy if you’re used to “just coding,” but they are the difference between a one-shot success and a 20-turn debug session.

The Skill Shift

The shift is from “I’ll figure it out as I code” to “I need to know what I want before I ask for it.”

Thomas Osmonson argues that “the dialogue is the work.”³ The back-and-forth with the model isn’t just about getting code, it’s about refining your own understanding of the problem.

The distinct skill of the AI engineer is the ability to maintain a coherent mental model of the system without seeing the code.

You need to be able to “see” the architecture in your head, because you aren’t building it brick by brick anymore. You’re ordering entire walls.

Practical Patterns

How does this change the daily workflow?

1. Rubber-ducking with the model: Before asking for code, ask the model to help you plan. “I want to add X. What are the potential edge cases? What files will this touch?”
2. Verification criteria first: Write the test case (or the manual verification steps) before you write the implementation prompt. This forces you to define “done.”
3. Treat the first response as a plan: Often, the model’s first attempt will reveal ambiguities in your request. Treat it as a draft plan, not a failed solution. Refine your intent based on what it got wrong.

Planning is no longer something we do before the work. Planning is the work. The typing is just a detail.

Footnotes

1. James Clear, “Inversion”. “Inversion is not about finding good advice, but rather about finding anti-advice. It teaches you what to avoid.” ↩

2. Sunil Pai, “Where Good Ideas Come From (for Coding Agents)”. “Agents make code cheaper. They do not make judgment cheap.” ↩

3. Thomas Osmonson, “More Thinking, Not Less”. “The bottleneck used to be how much code I could write… Now the bottleneck is knowing what to build.” ↩