We are living through an ongoing debate about the proper use of AI in software development. I say debate because, in our experience, the degree of trust teams place in AI-generated code still varies widely from one project to another.

A few resources have helped us frame the tradeoffs of designing workflows where human developers and AI tools collaborate. We strongly recommend Google’s The New SDLC With Vibe Coding whitepaper, which maps the landscape from what it calls “vibe coding” to frontier agentic engineering without prescribing a single right approach. The variable that changes most across that spectrum is how the work is verified: at the vibe-coding end, developers rely on manual judgment and whether the result seems to work; at the agentic-engineering end, specifications, evaluations, tests, and delivery gates give agents structured feedback and more autonomy.

The human work does not vanish, though. As implementation becomes faster, specification quality and the ability to verify the result become the new bottlenecks.

More recently, Boris Cherny of the Claude Code team shared his Steps of AI Adoption. Where Google emphasizes the discipline around the work, Cherny’s progression is organized around scale and autonomy: from closely supervising one agent, to orchestrating many in parallel, to delegating whole categories of work.

It is the more aggressive and aspirational of the two, and pays less attention to how a team stays in control of the engineering system around the code. Both are useful, and both agree that progressing step by step beats trying to adopt everything at once. In our experience, the advanced stages of either direction require strong engineering practices and a supportive culture.

A team learning in practice

As we help clients navigate these options, our own teams are experimenting too. One example came from a five-developer team of mixed seniority building a greenfield application, none of whom had worked in a truly agentic workflow before. In a pre-AI process, the MVP would likely have taken several months; with agents doing most of the implementation, they delivered it in a few, while also learning to design the workflow around them.

They began close to vibe coding and moved toward a process where agents implemented most tasks and did an initial review, while developers owned requirements, architecture, conventions, and supervision.

The human work did not disappear. It moved somewhere else.

On Google’s spectrum, the team moved from structured AI assistance toward agentic engineering. Most implementation is now delegated; domain knowledge, architectural decisions, and conventions have become explicit; and the harness itself is treated as an engineering system to maintain. It has not reached the frontier, though: the gap between documenting a rule and enforcing it reliably still exists, and automated guardrails are evolving.

On Cherny’s axis the team runs longer, more autonomous sessions, but it deliberately did not chase large-scale parallelism. A single agent proved best for most tasks, with multiple agents reserved for analysis or independent perspectives.

The team prioritized the reliability of its development system over the number of agents it could run at once.

Foundations before autonomy

The shift was gradual. Before delegating larger pieces of work, the team made its domain knowledge, architecture, conventions, and design foundations explicit. This surrounding structure proved more important than any individual prompt. The agent grew more reliable as the repository became consistent and recurring mistakes turned into documented rules or automated checks. The design system played the same role, reducing the decisions an agent had to infer from scratch.

As agents wrote more code, the team’s effort moved toward specifying tasks and describing expected behavior. An underspecified requirement can quickly become an implementation that looks complete but misses important cases. In a traditional workflow a developer might catch those gaps while writing the code; with autonomous agents, an incomplete idea becomes a complete but incorrect solution much faster. The bottleneck moves from producing code toward communicating intent and verifying that the system behaves as expected.

Developers still own the machine

This created some discomfort: developers felt less connected to code they no longer knew line by line. But supervision remained essential.

Agents can follow many rules correctly while still missing structural problems, accumulating complexity, or moving the system in the wrong direction. The team’s role shifted toward maintaining the machinery that produces the software: the context, conventions, validation mechanisms, and feedback loops around the agent.

That machinery degrades too. Documentation drifts, context gets noisy, and temporary instructions outlive their usefulness. Capturing every lesson is not enough; teams must decide whether each one should be removed, turned into a convention, or enforced automatically.

Clear code still matters, because it lets humans audit what agents produce and gives future sessions stronger patterns to follow. Developers may know less of the application line by line, but they cannot disconnect from the system directing and validating the agents. This is why team ownership matters.

Agentic development is adopted when a team learns to understand, shape, and maintain the workflow that makes its tools reliable.

Learning together

Coding agents are already part of software development, and opting out is no longer a realistic long-term position. The real question is how we adapt our engineering processes and culture to include them thoughtfully.

We wanted to share one of the many stories unfolding inside WyeWorks, and to approach it with some humility: ideas that look promising on paper still need to be tested in the everyday experience of real teams. Our team is formed by developers able to help others evaluate these approaches and adopt what fits their context, and we do so while continuing to experiment and learn ourselves.