Traditional software development cycle treats source code as the definitive blueprint. Developers translate requirements into coding syntax by hand. That coding syntax is the source of truth for testing, review, deployment, operation, and maintenance. Source code is the ultimate source of truth of an application.
Requirements in the traditional model were captured as PRD in Google docs or ProductPlan, design files in Figma, project management in Atlassian, version control in GitHub, documentation in Notion. The key is this entire ecosystem was built around source code.
Vibe-coding flips the traditional software development cycle on its head. Intent or requirements are captured as specification in plain english language. The vibe-coder iterates over the intent through an AI coding harness (Cursor, LOVEABLE, Kiro). The harness does its best to translate the Intent into source code.
- Old Model: Builder thinks → Builder writes code → Code is saved forever as the core asset.
- New Model: Builder defines the intent and requirements → AI generates the code → The code is just a disposable product of the process.
This shift from old model to new model is not benign. The speed of AI-assisted software development can compromise the structural integrity of the resulting systems. There is a need to design frameworks to govern this new division of labor.
Tesler's law, also known as the law of conservation of complexity, suggests that every system has a certain level of complexity that cannot be eliminated but only managed. This principle doesn't mean removing complexity altogether but rather deciding who should deal with it: the user or the system.
Architecture, Token economics, Governance, Hallucinations, Security are all important aspects which vibe-coding process needs to incorporate. This new division of labor needs a product whisperer, a specification builder or intent capture system for a robust application building cycle.
Ideally the specification builder or intent capture system should support:
- A workspace that lets you plan better and refine as you go.
- A workspace that integrates into your organization (workflows, systems of records)
- A workspace available through the entire development lifecycle, not just one conversation
- A workspace with batteries included like governance, guardrails, & security.
Fortunately there are bunch of great options which are available for the community to try:
Specification Builders
-
ProductSpec by Gokul Rajaram
ProductSpec is the open standard for product intent. It acts as a Product Harness for AI-native software work: what to build, what not to build, how to prove completion, and when intent changes. It gives teams and agents a portable way to define intent up front, attach evidence after work starts, and preserve what changed when reality disagreed.
-
SpecStory
Imagine having easy access to your intent, every productive AI interaction and every "aha!" moment you've had while software composing or AI-first building. The SpecStory extension captures and renders your AI chat and composer sessions into formatted Markdown that both humans and machines can understand, creating a persistent memory.
-
spec-kit by GitHub
Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the "real work" of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.
-
Kiro by AWS AI
Developing with specs keeps the fun of vibe coding, but fixes some of its limitations: vibe coding can require too much guidance on complex tasks or when building on top of large codebases, and it can misinterpret context. When implementing a task with vibe coding, it's difficult to keep track of all the decisions that were made along the way, and document them for your team. By using specs, Kiro works alongside you to define requirements, system design, and tasks to be implemented before writing any code.
-
OpenSpec
Review intent, not just code. Each OpenSpec change produces a spec delta that captures the change in requirements of the system. This makes it easy for developers to understand how they're modifying the system and what will need to change. It also allows reviewers to understand the change itself without having to dig through the code and quickly gain a high level understanding.
-
PitCrew Fastlane
Type the task you hate. In plain English. "I spend a full day every week reconciling custodian positions against our CRM across 100+ accounts." That's it. We ask what tools you use, who touches the workflow, and then map out exactly what it looks like today versus what it looks like automated. Time saved, steps eliminated, side by side.
Frameworks for Harness
Vibe-coding at lightspeed can impact a system's stability if there isn't a solid framework keeping things on the rails. Right now, there are plenty of conversations happening around the frameworks. Here are couple of recommendations:
At PitCrew we have led the conversation around harness with our notes on AI for Rails and Trust Metric for Agents.
AI engineer talk by Dexter Horthy: Harness Engineering is not Enough: Why Software Factories Fail
That is why Claude Code went from nothing to billions while tools with the same read, write, and edit commands did not: it was the first model trained against the harness it ships in. But maintainability is far harder to verify than a green test, and as Horthy puts it, if a model knew what good code looked like it would already write it. So for now you are stuck reading the code, which is fine, because you can still move fast. His fix is to turn the lights back on and plan up front: product review, system architecture, the underrated step of program design down to types and call graphs, then vertical slices. Thirty minutes of alignment saves hours of review, and a good PR becomes a joy to read instead of slop to untangle.
Recent launch: There is a new workspace for agents and human collaboration: Buzz by Block
Chat with teammates and specialized agents in one shared space, then move straight into planning, project management, coding, and PRs. Create agents tailored to your workflows, let them collaborate with your team's agents, and keep the work that used to be scattered across chat, trackers, and dev tools in one place.
This article was originally published on LinkedIn. Read it on LinkedIn →