From Vibe Coding to Developing the Company

The idea of spec-driven development is to take an idea, turn it into a specification, and use that specification to guide agentic work.

The simplest version of spec-driven development is to use “plan mode”, which coding agents now provide. And even the vibe coding platforms such as Base44 and Lovable recommend it as an alternative to one-shotting it.

Beyond plan mode you can adopt (or make) a harness that explicitly defines the workflow, policies, handoffs, and agent responsibilities. Think GitHub’s Spec Kit, Every’s Compound Engineering, Amazon’s Kiro, etc.

Each one of these frameworks/harnesses provides an opinionated view on what an agentic workflow should look like. Or, in other words, a specification for how to do development. That specification drives the agentic software workflow, also known as the agentic software factory.

It brings predictability through guardrails that steer agents. Kind of like how processes steer humans working together.

Each of these frameworks comes with a starter definition of workflow. Using it effectively requires continuously adapting it to your own world. It’s like Scrum’s Definition of Done or Kanban’s definition of workflow. Don’t expect spec-driven-development harnesses to provide a full recipe for how to work in your world. Use them as frameworks which you use, inspect, and adapt.

What does “adapt” look like? Making changes in the configuration files that agents refer to as they drive work throughout the software factory. Think AGENTS.md, constitution.md, skills, and LangGraph loop configuration. This becomes our operating system manifested as version-controlled code.

Even in spec-driven development, you can feel reduced to approving individual steps for the agents, constantly bombarded with walls of Markdown. Maybe you aren’t coding, but you have to review the large code PRs. That’s not exactly the vision of the agentic software factory we were sold on, is it?

Wouldn’t it be nice if we could indeed “vibe code” through a trusted software factory? To be able to express what we want, and get working high-quality software at the other end that achieves the outcome we are looking for?

The idea is to “one-shot” a trusted agentic loop. And get a higher-quality, more predictable result even when it’s nondeterministic LLMs executing the loop.

It’s not that dissimilar from a human-powered software factory. Humans aren’t deterministic either. And when they’re doing high-level knowledge work such as software development there’s plenty of variability. Agile/Flow-based ways of working are designed to bring discipline and predictability into the nondeterministic world of R&D.

That doesn’t mean everything we build will work. It doesn’t mean everything will be useful. It means we are optimizing the performance of the design factory to maximize our ability to turn human talent and capacity into useful products or capabilities.

And in the agentic age, we are optimizing the performance of both human capacity and AI tokens, through continuously tinkering with the operating system/process that we refer to when doing work in the factory.

You’ve sampled it and run it multiple times. Sometimes it will fail, and you have a process for fixing it. You are accountable for what the agents are doing.

View full-size diagram

Even if we created an efficient software factory, that’s only part of the journey. Delivering software doesn’t necessarily mean customers adopt it. It doesn’t necessarily mean we’ve delivered value. The impact comes from software that enables new behaviors for our customers.

Effective agency depends on alignment to what we’re trying to do. Before giving agents the keys to choose features, improve the outcome orientation of the agents and their harness. Otherwise, they’re going to build junk. It might work, but it might not move the needle in any meaningful way.

For years I’ve worked with organizations that call themselves product organizations with feature teams and cross-functional teams. When you look at the actual work, very few teams are really empowered to own end-to-end outcomes. Most of the work requires handoffs and waiting, with dependencies everywhere.

If you want agency, even for humans, you need to create the right structure. Focus on smaller bets that involve fewer teams. Reshape the teams to localize collaboration and coordination. Make shared capabilities available in a self-service mode, with context and guardrails.

Over time, ideally you’re able to say: this is the outcome, this is what I want to see, this is the KPI. Go. Develop a hypothesis about which features will enable the behavior we want to see. Validate your bet. Build based on what you learn. Deploy. Release. Tweak.

In other words, it’s not enough to make the software lifecycle agentic. What we want to see is the extension of the agentic workflow both upstream and downstream.

Upstream of the specification: what is the outcome, what is the problem, what is the intent?

Downstream of delivery: are people adopting what we’ve built, and is it creating value for them?

One thing I’ve done with multiple organizations is to create an upstream skill that makes sure you frame work in terms of outcomes and consider discovery/derisking as well as ways to close the feedback loop and make sure the agentic workflow starts with intent rather than software requirements. For an example of such a skill, check out Frame-Intent.

View full-size diagram

The mirror of starting with intent is to close the loop on achieving outcomes. So after deploying new software, the agentic workflow should look at product metrics: awareness, activation, retention of the new capability. Have we achieved our intent? If not, the agent should propose an updated hypothesis on how to achieve the intent based on the telemetry/context it collected, and iterate on the solution within agreed boundaries. Humans still decide whether to change the intent or commit to a larger bet. This is the true agentic loop in action.

Look at recent issues/PRs in your own GitHub repo, Jira or Linear. Is it clear what the outcome is, what behavior we’re trying to change, why we’re doing this thing? When we deployed it, did it make the change in behavior and achieve the outcome we set out to achieve?

If you’ve created your own harness or customized one, assess it. Is it validating and steering toward outcomes? At a minimum, it should show us when we haven’t created the impact we intended. That visibility enables us to converge.

Let’s dive a bit deeper into what continuously tinkering with the agentic software factory looks like.

Observe how we worked on the feature, humans and agents together or an agent on its own. Agents and humans reflect. Agents can create pull requests of changes they suggest to the process. Humans review those pull requests and decide whether to merge them into the way we work.

Those pull requests change the code running our system of work: skills, constitution files, agents and CLAUDE.md. When a rule isn’t having the intended effect, treat it as a bug. Create an evaluation or a test that proves it, then work on it through test-driven development. Improve the skills, improve the context, improve the system that creates the code, and then rerun and see if it’s better.

One of the things I’ve seen in organizations I work with is that the harness is created by engineering. It’s very engineering-oriented, both in what it focuses on and how it’s structured. When you give it to people who aren’t the engineer who wrote it, they don’t always know what to do with it. They don’t even understand the benefit. You need to think about activation and retention, especially when we start to move beyond engineering.

We should be thinking about the factory as a product that needs to evolve and find product-market fit. It’s the experience for the humans using this system.

The same thinking applies beyond the software organization. What we’re seeing engineers struggle with is even a bigger struggle for many other knowledge workers.

If you think the paradigm of continuous tinkering is hard to implement in engineering, just wait and see what happens when you try to extend it to the broader organization.

If you’re a software leader or maker, you can help other knowledge workers in the organization. Not just by helping them understand how to build stuff with AI. Even more important might be to help them with the shift to “developing the system of work” rather than doing the work or babysitting the work.