When the price isn't worth it.
LID has a real price — design before code, review between phases, cascade discipline across changes. When the benefit doesn't cover it, LID is the wrong choice. Fit problems, not product deficiencies.
-
N·01
Throwaway scripts and one-week prototypes.
If the code's lifespan is measured in days and nobody will maintain it, the up-front design phase never pays itself back. Vibe-code the prototype, ship it, delete it. LID compounds over months — use it where months are on the table.
-
N·02
Exploratory research code.
Code where you genuinely don't know the intent yet — you're exploring a problem space to figure out what you're building. LID requires an articulated HLD as its universal floor; if you can't write even a rough one, you're not ready for LID. Explore first, formalize when the target clears up.
-
N·03
Teams that won't review specs before code lands.
LID depends on humans reading the design before the agent writes the implementation. A team that skips LLD review, approves specs blindly, or only reads code in PRs will get weaker results from LID than from looser approaches — the price without the benefit.
-
N·04
Projects where English-as-source is a hard sell.
LID treats the agent as an English compiler and specs as the source. If your team, company, or compliance context requires code as the canonical artifact (regulated industries, certain auditing regimes, formal-methods environments), LID's specs-as-source stance will rub against those constraints. It can still work, but the cultural price may outweigh the gain.