When Harshil Kansagara started using AI to generate architecture docs, API contracts, and implementation plans across separate sessions, everything looked solid—until it didn't. The outputs were individually great but collectively broken. System architecture pivots never propagated to API contracts. Frontend assumptions silently diverged from backend data models. In a detailed write-up on DEV.to published June 7, Kansagara documents how this problem led him to completely rethink the role of AI in software engineering.

The Real Problem With AI-Assisted Development

Kansagara realized that AI wasn't the culprit—the real issue was treating it as a collection of disconnected prompt sessions. Without governance connecting artifacts together, every generated deliverable becomes an island. Frontend and backend drift apart. Architecture decisions made in week one contradict API contracts finalized in week four. The solution isn't better prompts; it's structural alignment across the entire delivery pipeline.

Building a Governance-Driven Framework

The framework Kansagara developed rests on three layers: Prompt captures intent only (lightweight, declarative), Agent orchestrates execution and decides which capabilities to invoke, and Skill is a reusable, schema-validated execution block with hardcoded governance rules. This architecture enforces consistency at the Skill layer rather than burying rules in fragile prompts that vary session to session. The framework creates a sequential dependency chain where Business Requirements feed System Architecture, which feeds Data Architecture, then Event Architecture, API Contracts, Implementation Plans, and finally Backend/Frontend Implementation. Each artifact consumes the one before it—upstream changes automatically propagate downstream.

The Finding That Should Change How You Think About AI

Here's what surprised Kansagara most: the highest-leverage use of AI wasn't code generation at all—it was context generation. When engineers or downstream agentic workflows received a governed, unambiguous spec, implementation quality consistently outperformed any raw AI-generated code output. The unlock is context, not syntax. Give an AI clean requirements and it produces cleaner code. The ambiguity problem isn't solved by better prompts; it's solved by upstream governance that removes ambiguity before it reaches the implementation layer.

What Failed Along the Way

Kansagara doesn't sugarcoat his failures. Over-orchestrating everything—he admits not every workflow needs an agent loop. Prompt bloat as a substitute for real architecture decisions. Severely underestimating token costs when scaling the system. And the biggest lesson: believing full pipeline autonomy was a safe goal. It isn't. The framework works because humans stay in the governance loop, not despite it.

Key Takeaways

  • Treat AI sessions as connected artifacts, not isolated prompts—governance must span across interactions
  • Context generation delivers more value than code generation when measured by implementation quality
  • Enforce alignment rules at the Skill layer rather than embedding them in fragile, variable prompts
  • Don't chase full autonomy—it creates hidden risks that surface in production, not in demos

The Bottom Line

The industry's obsession with AI writing code faster is solving the wrong problem. Until your team has governance preventing artifact drift across Business Requirements → Implementation, you're just building technical debt with extra steps. Kansagara's framework won't fix everything, but it correctly identifies where AI delivers outsized returns: not in syntax generation, but in eliminating ambiguity before humans and agents ever touch a line of code.