Contents
In brief
A Dev.to essay argues classic prompt engineering should give way to Problem Engineering: formal problem specs before any code is generated. Production failures are rarely “the model isn’t smart enough”—they are specification holes. The frame has five layers: system invariants, data contracts, state mutations, fault topology, and observability hooks.
What happened
A familiar 2026 pattern: dump hundreds of repo lines plus legacy tricks (“think step by step,” “act as a principal engineer”). The model streams flawless TypeScript and a green build… then Redis pools exhaust, races double-charge, and the service dies. The model could code; the problem was un-engineered.
The idempotency middleware case makes the contrast sharp: a vague prompt yields check-then-act races and infinite caches without TTL; a full spec (Redis keyspace, atomic SET NX, PROCESSING/COMPLETED, body checksum, fail-open on timeout) turns the model into a syntax compiler that ships solid code on the first pass.
Why it matters
Long context and test-time reasoning do not cancel ambiguity. Until boundaries are fixed, the model fills gaps along the statistical path of least resistance—tutorial-grade code without concurrency or degradation plans. Senior leverage is not “talking to AI”; it is bounding the search space.
In practice
- Before generation, run the checklist: invariants, I/O schemas, atomicity, dependency timeout behaviour, telemetry.
- State data contracts explicitly (types, nullability, formats)—do not let the model invent shapes.
- For money and side effects, require idempotency and payload checksums.
- Choose fail-open vs fail-closed before code, not after the first incident.
- Put log and trace expectations into the brief so “working” code is not blind in production.
Takeaway
Prompt tricks were a bridge for fragile models. Mature reasoners win from hard problem architecture. Engineer the problem first—then generate.