Almost every CTO or VPE we talk to is asking some version of the same question: “Are we picking the right tools, building out the right workflows, and putting our people in the right places?” In other words: how should engineering teams actually operate now, with agents writing most of the code?

Teams are landing in pretty different places. Some are pushing toward full autonomy with minimal human review. Others are keeping tight control, using AI more as a reviewer or assistant. Most are somewhere in the middle.

But which workflow you pick isn’t really the challenge. The inputs are.

The bottleneck has moved. Writing code is getting cheaper, but building reliable systems requires more than just code. Specs, tests, and review are now the limiting factors, and agents amplify whatever you feed them. Strong inputs get strong results. Weak ones fail faster, at scale, and with less visibility into why.

One theme for the second half of 2026: engineering leaders need much better visibility into what other teams are actually doing. Too much of this is still being figured out in private, and some of the public conversation is noise.

What’s actually working

From what we’re seeing across teams and practitioner write-ups, a few patterns are emerging. Not as a single “right way,” but as things that consistently hold up.

Front-load the thinking: spec, tests, then code

The teams getting reliable output are putting more effort into shaping the problem up front (acceptance criteria, edge cases, tests) before letting agents implement. The shift is subtle but important: less time writing code, more time defining what “correct” looks like.

Parallelize aggressively, but with boundaries

Running multiple agents in parallel is becoming common: one exploring, one implementing, one cleaning up. (Stripe built a harness that ships >1,000 agent-driven PRs per week. ) But the teams doing this well isolate each agent in its own worktree, container, or sandbox, so mistakes don’t cascade. Parallelism helps, but only if it’s contained.

Where this breaks

A few failure modes show up just as consistently.

Tests written after the fact

This is amplification working against you. When you ask an agent to write tests after the implementation, the existing code becomes the spec. Agents don’t push back. They complete the task you gave them, even if the task is wrong. The result: tests that lock in whatever’s broken. Discipline matters more with agents, not less: tests first, then implementation.

Context can be a liability

Many teams are leaning on rules files (CLAUDE. md, AGENTS. md) to guide behavior. But they go stale quickly. Codebases evolve, and these files rarely keep up. Without regular review, they can make things worse, with agents following outdated or rigid instructions. Structure is necessary for good results, but bad structure gets amplified.

What actually changes for teams

Coding agents don’t remove the need for senior engineering judgment. They concentrate it. The work shifts toward defining problems clearly, validating outputs, and keeping the whole system reliable. Teams with weak specs, inconsistent tests, or overloaded review processes feel more pain, not less. Teams with strong fundamentals move faster.

The work moves up the stack, and the pressure moves with it. And the systems you build around the agents matter more than the agents themselves.

Reading list

• Embracing the parallel coding agent lifestyle – by Simon Willison. Concrete patterns for running several coding agents at once. Covers worktrees and Docker for isolation, what kinds of work to delegate to parallel sessions, and what to supervise more tightly.
• How Stripe built “minions” – by Steve Kaliski via Lenny’s Newsletter. Inside Stripe’s production agent harness shipping ~1,300 PRs/week from Slack reactions. Covers the harness layers, how they handle code review at that scale, and what they had to build vs. adopt off-the-shelf.
• Why Testing After with AI Is Even Worse – by Matti Bar-Zeev. Why asking an agent to write tests after the implementation produces tests that validate existing bugs instead of catching them. Makes the case for TDD with agents, not against it.
• How System Prompts Define Agent Behavior – by Srihari Sriraman and Drew Breunig (nilenso). A close read of system prompts across Claude Code, Cursor, Codex, Gemini, and others. Shows the same model producing dramatically different workflows depending on the prompt wrapped around it.
• Your CLAUDE. md Is Making Your Agent Dumber – by Cordero Core. Recent research finding that LLM-generated CLAUDE. md / AGENTS. md files actively decrease agent success rates compared to having no context file at all. Practical guidance on what to do about it.
• Ralph Wiggum as a “Software Engineer” – by Geoffrey Huntley. Walks through “Ralph,” a bash-loop technique for autonomous coding agents. Concrete on what kinds of projects it suits and where senior engineering judgment stays non-negotiable.