Not every project needs a blueprint.
LID has real costs — design before code, review between phases, cascade discipline across changes. When the benefit doesn't outweigh the cost, 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 is pure overhead. 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 discipline matters; without it, you're paying the cost without getting 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 plastic-code philosophy will rub against those constraints. It can still work, but the cultural overhead may outweigh the gain.