In this same vein, plan mode is a trap. It makes you feel like you're actually engineering a solution. Like you're making measured choices about implementation details. You're not, your just vibe coding with extra steps.
I come from an electrical engineering background originally, and I've worked in aerospace most of my career. Most software devs don't know what planning is. The mechanical, electrical, and aerospace engineering teams plan for literal years. Countless reviews and re-reviews, trade studies, down selects, requirement derivations, MBSE diagrams, and God knows what else before anything that will end up in the final product is built. It's meticulous, detailed, time consuming work, and bloody expensive.
That's the world software engineering has been trying to leave behind for at least two decades, and now with LLMs people think they can move back to it with a weekend of "planning", answering a handful of questions, and a task list.
Even if LLMs could actually execute on a spec to the degree people claim (they can't), it would take as long to properly define as it would to just write it with AI assistance in the first place.
Your aerospace analogy is fair, and I'd push back on one thing: the problem isn't that developers don't plan — it's that most planning tools for software are too lightweight to actually constrain AI output. "Plan mode" is indeed vibe-coding with extra steps if your plan is a bullet list.
I've been building a Go web framework using AI as the primary code writer. What made it work wasn't a task list — it was locking architectural decisions upfront in a document the AI reads before touching any file. Not guidelines. Decisions. Closed. With rationale, rejected alternatives, and consequences documented.
Any change that crosses a decision boundary gets stopped. Any change touching more than one file requires an explicit Amendment — numbered, approved, then implemented. If you've worked with formal change control in project management, it's exactly that mental model applied to AI-assisted development.
The AI writes code. It does not decide what gets built or how the pieces fit together.
That's closer to your requirements derivation + down-select model than to anything most software teams do. The difference is the tooling forces it — the AI won't proceed without the context, and the context is the spec.
This is an ad written by a robot. It just says "AI bad at code. Hire us; we're so good at knowing tough things like that."
In this same vein, plan mode is a trap. It makes you feel like you're actually engineering a solution. Like you're making measured choices about implementation details. You're not, your just vibe coding with extra steps.
I come from an electrical engineering background originally, and I've worked in aerospace most of my career. Most software devs don't know what planning is. The mechanical, electrical, and aerospace engineering teams plan for literal years. Countless reviews and re-reviews, trade studies, down selects, requirement derivations, MBSE diagrams, and God knows what else before anything that will end up in the final product is built. It's meticulous, detailed, time consuming work, and bloody expensive.
That's the world software engineering has been trying to leave behind for at least two decades, and now with LLMs people think they can move back to it with a weekend of "planning", answering a handful of questions, and a task list.
Even if LLMs could actually execute on a spec to the degree people claim (they can't), it would take as long to properly define as it would to just write it with AI assistance in the first place.
Your aerospace analogy is fair, and I'd push back on one thing: the problem isn't that developers don't plan — it's that most planning tools for software are too lightweight to actually constrain AI output. "Plan mode" is indeed vibe-coding with extra steps if your plan is a bullet list. I've been building a Go web framework using AI as the primary code writer. What made it work wasn't a task list — it was locking architectural decisions upfront in a document the AI reads before touching any file. Not guidelines. Decisions. Closed. With rationale, rejected alternatives, and consequences documented. Any change that crosses a decision boundary gets stopped. Any change touching more than one file requires an explicit Amendment — numbered, approved, then implemented. If you've worked with formal change control in project management, it's exactly that mental model applied to AI-assisted development. The AI writes code. It does not decide what gets built or how the pieces fit together. That's closer to your requirements derivation + down-select model than to anything most software teams do. The difference is the tooling forces it — the AI won't proceed without the context, and the context is the spec.
[dead]