Tapiwanashe Mlambo
IDEAS
+

On AI Constraint Design

Most builds with AI agents fail not because the models are weak, but because humans hand them under-specified problems and try to think while the code streams past. The bottleneck has shifted from typing to thinking. Speed is now a multiplier on whatever quality of input you provide. Without structure, agents compound mistakes faster than you can catch them.

The standard pattern looks like this: describe an idea in a paragraph, open an agent, watch it scaffold a stack, react to its choices, ask for refactors, and watch the codebase accumulate sediment. Two days of momentum become two months of architectural drift. Decisions made under pressure, reversed under pressure, leave no traceable logic. I've seen it kill projects. The only honest fix is often a full rewrite with discipline.

The alternative is two moves. First, move every architectural and product decision upstream. Before an agent touches a file, settle the stack, schema shape, auth strategy, role model, payment rails, and deletion semantics. Write it as a spec: plain text, uppercase headings, declarative bullets. No "implement as needed." No room for interpretation. The agent's job becomes execution, not invention.

Second, break the spec into stages. Each stage gets a self-contained brief (under 200 lines) with exact inputs, outputs, and a checklist definition of done. Run each stage in a fresh session. Never let one session straddle two stages. Context degrades. Assumptions leak. Fresh sessions force the agent to rebuild its state against the brief, not the ghosts of earlier work.

Above the spec and briefs sits a meta-config file. It carries standards across sessions: package managers, component libraries, mobile breakpoints, git rules, build checks. Every rule exists because something failed without it. It's not aesthetic preference. It's enforced consistency.

This method costs time upfront. Writing a real spec takes hours of focused thinking that feels like nothing is happening. It forces commitment. If you don't know whether a record should be immutable, the spec will catch you. You can't write "mostly immutable." You must decide. It also kills exploration. If you're still figuring out what you're building, don't use this. Sketch first. Spec second.

What you get is finishable, reviewable, handoff-ready software. Every decision has a paper trail. When the agent drifts, you compare output to spec and fix the gap. There's never a "the codebase just grew this way" answer. Two recent rewrites, a retail ERP and a trading app, both shipped only after this method locked the architecture first.

Before AI, bad specs were slowed down by human friction. Teams argued, paused, and converged. That slowness was a safety mechanism. Agents remove the pauses. They don't push back. They execute. Speed without specification isn't productivity. It's accelerated rot.

If you're building something non-trivial with an agent: write the spec first. Break it into stages with strict definitions of done. Set your meta-config. Open one session per stage. Update files between stages. Resist reopening decisions mid-build. You will feel slow. You will want to code. Sit with it. The method pays for itself the first time you skip a rewrite. The rest is execution, which is what agents are actually good at.

Thanks for reading

This space is my working notebook for building resilient software in Africa: the trade-offs, the systems, the payments, and why I ship the things I do. If you care about building tools that outlive the hype, you're in the right place. Let's keep building.

See All Ideas