Agent First Development for Enterprise Teams

Vibe coding makes it easy to turn an idea into something you can click through. The difficulty changes when a team has to deliver it, another team has to maintain it, and a customer expects it to keep working.

Imagine five engineers running several agents each. Everyone is producing code. But they may also be producing five interpretations of the same requirement, incompatible interfaces, and more changes than anyone can properly review. A successful agent run tells you very little about whether the team has delivered a useful system.

In PRD-driven development, I wrote about keeping the product requirements document close to the code. I think that idea needs to become a broader methodology for teams. I would call it Agent First Development: understand the scope together, delegate bounded work to agents, and accept delivery through evidence.

Vibe first means using fast experimentation to discover and refine an idea. Agent first means organizing implementation so agents can execute clear tasks with the right context, tools, and limits. Human judgment connects the two and remains responsible for the result.

What I would borrow from earlier methodologies

From waterfall, I would borrow the discipline of making requirements, dependencies, and design decisions explicit before implementation. An important warning already appears in Winston Royce's 1970 paper: leaving the discovery of operational constraints until final testing can force major redesign. Early understanding has to include experiments and feedback.

From Agile, I would keep short delivery cycles, customer collaboration, and the ability to revise a plan when we learn something. The Agile principles already connect frequent delivery with technical excellence and regular reflection. Agents make those feedback loops even more valuable.

From the Scaled Agile Framework, or SAFe, I would borrow three practices: planning dependencies and capacity across teams, maintaining an architectural runway so upcoming work has the foundations it needs, and building quality into every increment. These give teams concrete ways to coordinate work that spans several systems.

The resulting process puts deliberate preparation before production implementation, then delivers in small increments. The team understands the whole intended scope before dividing it into tasks. Each increment still creates an opportunity to learn and change direction.

Complete scope means agreement about the outcome, boundaries, constraints, dependencies, and acceptance criteria, with consequential unknowns resolved through discovery. It cannot mean predicting every implementation detail. If a question could change the architecture, security model, or delivery commitment, investigate it before committing the affected work. Record smaller uncertainties with an owner and a condition for revisiting them.

The 12 commandments

1 Understand the scope before starting implementation

Write down the problem, intended users, expected outcome, included workflows, exclusions, dependencies, and failure cases. Agree on examples of acceptable behavior. Product, engineering, and the people responsible for running the system must share that understanding before agents start production implementation.

The product owner accepts the intended behavior; the engineering owner confirms feasibility and constraints. A request to build an enterprise dashboard is still an idea. A bounded requirement for named users, permissions, data sources, and measurable behavior is work the team can delegate.

2 Put a human name against every commitment

Every deliverable needs an accountable engineer, a reviewer, and an identified owner after release. The product owner decides whether it solves the agreed problem. A small team may combine roles, but the responsibility must remain visible.

Agents can propose designs, implement changes, and investigate failures. Their supervising engineers own the decisions and must understand the changes well enough to explain and maintain them. Shared code ownership should spread that understanding across the team. The agent wrote it is an explanation of authorship; the team still owns its behavior.

3 Use prototypes to answer questions before making commitments

Give exploratory vibe coding a question and a time limit. Can users complete this workflow? Does this integration expose the data we need? Can the existing architecture meet the expected load? Review what the experiment actually demonstrates before turning it into delivery work.

Use isolated environments and synthetic data. Record the assumptions and shortcuts. When prototype code becomes a candidate for production, inspect it against the agreed architecture, acceptance criteria, and security requirements. Any gaps become explicit work. A convincing demo earns a decision about what to build next.

4 Define enterprise readiness before generating the solution

Translate enterprise ready into requirements the team can verify: identity and authorization, separation between customer tenants, auditability, data handling, accessibility, reliability, performance, and operating cost, as applicable to the product. Give each requirement an owner and an acceptance check.

For example, specify which roles can export data, how access is revoked, what gets logged, the largest supported export, and the load under which it must finish. Include relevant organizational obligations in this discussion. These choices shape the design and the implementation tasks from the beginning.

5 Give the team and its agents one versioned source of truth

Keep the agreed requirements, architecture decisions, interface contracts, task plans, and acceptance checks in shared, versioned records. Each agent task should identify the revision it is implementing. Decisions made in private chat must enter that shared record before other work depends on them.

Agents can update documentation as they work, including why an approach changed. Changes to scope or acceptance criteria require the responsible humans' agreement. Preserve the decision history so an implementation cannot quietly redefine what the team promised to deliver.

6 Agree on contracts before parallelizing the work

Define API behavior, schemas, error handling, authorization boundaries, and compatibility expectations before separate agents build dependent components. Assign owners to shared interfaces and migrations. Put foundational changes ahead of the features that depend on them.

For example, the teams building an export button, its API, and its background worker should agree on the job states and failure behavior first. Give them shared contract tests and integrate a thin path through the system early. Parallel execution becomes useful when the pieces have a tested way to fit together.

7 Give every agent a bounded task and a stopping rule

An agent task needs an objective, relevant context, allowed changes, dependencies, acceptance checks, resource limits, and a human owner. Ask the agent to restate its plan before substantial implementation so misunderstandings surface while they are cheap to correct.

Define when it must stop and escalate: a missing requirement, an incompatible interface, a need for broader access, an unexpected migration, or a failing constraint. New functionality goes back into the shared backlog for a scope decision. An agent's ability to keep generating changes must never become permission to expand the assignment.

8 Limit parallel work to what the team can integrate and review

Use isolated branches or worktrees for independent tasks. Coordinate changes to shared components, and assign a person to own integration. Keep pull requests small enough for a reviewer to understand their behavior and failure modes.

Choose the number of active agent tasks according to available review, testing, and integration capacity. Make dependencies and blocked work visible on the same board the team uses for delivery. Integrate frequently against the current codebase. When the review queue grows, finish and verify existing work before starting more agents.

9 Require evidence that can challenge the implementation

Derive acceptance checks from the agreed requirements, and exercise failure paths as well as successful ones. Use integration tests, realistic load, authorization checks, and recovery exercises where the risk calls for them. An agent can write tests, but its implementation and its tests may share the same mistaken assumption.

A separate reviewer should examine both against the original requirement. Automated or agent review can help find problems; accountable human review remains part of acceptance. Never weaken an agreed check merely to make generated code pass. Keep the evidence linked to the change it verifies.

10 Bound an agent's authority as carefully as its task

Give agents only the repository, tools, credentials, and network access their assignment requires. Use approved model services for the data involved. Keep secrets out of prompts and logs, use sanitized test data, and treat instructions found in issues, web pages, or dependencies as untrusted input.

Use controlled automation for sensitive actions. Production access, destructive operations, permission changes, and release decisions must follow the team's defined authorization process. Record the actions needed for accountability without unnecessarily retaining sensitive content. Increased autonomy needs enforceable boundaries.

11 Deliver a system the next person can operate

The definition of done includes deployment instructions, useful telemetry, alerts, a runbook, an operational owner, and a tested recovery plan. Review new dependencies and their licenses, and retain the dependency inventory and security evidence required for the release.

For higher risk changes, rehearse migrations and use a gradual rollout with explicit stop conditions. A feature flag can stop new use, but it cannot reverse a destructive data migration; that needs its own recovery strategy. Preserve a trace from approved requirement to task, reviewed change, checks, and release. Accept delivery against that record and observed behavior.

12 Measure useful delivery and make learning survive the session

Track how long accepted changes take to reach users, escaped defects, incidents, recovery time, rework, review delays, and whether customers use the result. Include the cost of models, infrastructure, and human review. More generated code or completed prompts does not establish improvement in any of those outcomes.

After each increment, review where the team misunderstood the problem, where agents needed intervention, and which checks caught real failures. Turn recurring lessons into better requirements, reusable tools, repository instructions, and regression tests. The next engineer and the next agent should inherit that knowledge.

How a team would run it

Start with a delivery brief and a shared scope review. Use discovery and prototypes to resolve consequential questions, then agree on the requirements and constraints for implementation. Adjust the amount of preparation to the risk: a copy change and a customer data migration need different evidence.

Next, break the scope into small increments that each deliver a usable workflow. Agree on shared contracts, sequence dependencies, and assign human owners before opening agent tasks. Each task carries the same relevant requirements and a clear definition of done.

During execution, a short daily coordination check should focus on changed assumptions, blocked dependencies, review capacity, and integration failures. Review and integrate throughout the increment. When new information changes the scope, the responsible product and engineering owners update the shared agreement and replan affected work before execution resumes.

At the end of the increment, demonstrate the integrated workflow against its acceptance criteria and review the operational evidence. The release owner authorizes rollout through the agreed process. Observe the result in production, check the customer outcome, and feed what the team learns into the next increment.

An enterprise export in practice

Consider a team asked to add customer data exports. Before implementation, it agrees on who can request an export, which records belong to that customer, what happens if access is revoked mid-job, how retries behave, and when exported files expire. Product and engineering also agree on supported size, completion time under expected load, and audit requirements.

One engineer supervises an agent implementing the API. Another owns the worker. A third owns the user workflow and integration. They share the authorization rules, job schema, and contract tests, and run a small export through the whole system before expanding it.

The reviewer checks attempts to export another customer's records, duplicate requests, interrupted jobs, expired links, and revoked access. The release includes alerts for stuck jobs, limits on resource usage, and a way to disable new requests while handling existing ones safely. Completion means the agreed behavior works and the operating team can support it.

That is the methodology I want teams to adopt. Spend enough thought to know what we are asking agents to build. Give them the context and freedom to execute within that agreement. Take responsibility for every change that reaches a customer.