Blog/Field notes/how-we-build-software

How we build software across the portfolio

AI agents, the harness, the harvested context, and the testable chunks.

How we build software across the portfolio

Cover · Field notes How we build software across the portfolio

Hey folks,

The last three posts were about Tactix, one product we're building. This one zooms out, because the more interesting story is how we now ship across every company in the portfolio, and how different that looks from a year ago.

The discipline finally has a name. In February 2026, almost exactly a year after coining "vibe coding," Andrej Karpathy declared that era over and drew the line at Sequoia's AI Ascent: vibe coding raises the floor for everyone; agentic engineering preserves the quality bar of professional software. Two different goals, two different disciplines.

His framing of the job now: "You have these agents which are spiky, stochastic entities -- but extremely powerful. How do you coordinate them to go faster without sacrificing your quality bar?"

That's the question this post answers, the way we answer it. The tool is Claude Code. But the tool is the easy part. The work is everything around it: where the context comes from, how memory persists, and how you trust what comes out.

The bottleneck moved

For most of my career, the bottleneck in software was writing it. That's gone. Anthropic's own head of Claude Code, Boris Cherny, says 100% of his production code is now AI-generated; he hasn't hand-written a line since October 2025.

So where did the bottleneck go? The data is unambiguous: to verification. DORA's 2025 report found AI adoption boosts delivery throughput but remains negatively associated with stability.

Faros AI, covering 10,000 developers, found high-adoption teams merged 98% more pull requests while review time climbed 91%. And a large-scale study counted over 110,000 surviving AI-introduced issues in production repos by February 2026.

Throughput is solved. Trust is not. Which means the scarce engineering skills are now context assembly and verification design, and everything below is in service of those two.

The harness

Claude Code is a terminal-native agent: it reads the repo, plans, edits, runs your tests, reads the failures, iterates. That loop is the unit of work we delegate. What makes it a harness rather than a chatbot is what we wrap around it, and here Anthropic's recent research is the best writing on the subject. Their harness design post (March 2026) documents two findings we'd felt but couldn't name:

Models lose the plot on long tasks. As the window fills, coherence drops, and some models exhibit "context anxiety," wrapping up prematurely as they near what they believe is their limit. The fix is context resets: clear the window entirely and start a fresh agent with a structured handoff artifact, rather than compacting in place.

Agents can't grade their own work. Asked to evaluate their own output, agents confidently praise mediocrity. The lever is separation: a standalone evaluator tuned to be skeptical beats a generator asked to self-criticize, every time.

Their resulting architecture is a planner, a generator working in sprints, and an evaluator that clicks through the running app the way a user would. The cost numbers are worth staring at: a solo agent run took 20 minutes and $9; the full harness took 6 hours and $200. Twenty times the cost, and the solo run's output was broken at the core while the harnessed one worked.

One caveat they're honest about, and we've adopted as a principle: harness complexity should shrink as models improve. Scaffolding built for one model generation becomes a cage for the next (Opus 4.5 largely eliminated context anxiety on its own). Build the simplest harness that holds your quality bar, and subtract aggressively.

Context is the product

Here's the part of our flow that's genuinely differentiated. Most agentic engineering content stops at the repo boundary. But the repo is the what. It contains none of the why.

The repo is the what. This is the why. Emails Granola meeting notes # Slack threads iMessages Distill decisions · constraints requirements chatter · sensitive data · noise Context doc the why Repo the what Agent A page of curated truth beats fifty pages of raw transcript. What enters the window is a decision, not a dump.

The why lives in the communication exhaust: the email thread where the customer described the real problem, the meeting where we ruled out the obvious approach, the Slack thread where someone flagged the constraint, the iMessage where a founder changed the requirement on a Tuesday night. With small teams and fast-moving founders, that last one happens more than anyone admits.

So before any meaningful build, we harvest. Meeting notes come straight out of Granola, which turns every conversation into agent-ready context without anyone taking notes. Emails get pulled. Slack threads get exported (easier than ever now that Slack's real-time search API and MCP server are generally available). Texts when that's where the decision happened. All of it gets distilled into a context document that rides along with the goal.

The empirical case for this step is strong. Feature additions succeed on the first attempt only about a third of the time with coding agents, and the best framing I've seen is that this is a workflow problem, not a model problem: you don't hand a new developer a Jira ticket and say "build this." You give them the architecture docs, the conventions, the landmines. One study found a 49% improvement in AI decision compliance when organizational knowledge, the conventions and undocumented decisions, is provided to the agent.

The codebase is the agent's hands. The communication exhaust is its judgment. You need both in the window.

Memory, kept ruthlessly small

Context windows end; projects don't. The CLAUDE.md file at the repo root is the institutional knowledge a senior engineer carries in their head, written down and loaded every session.

Claude Code's memory stack has matured fast (subagents now carry their own persistent MEMORY.md, so a code-review agent genuinely accumulates expertise about your codebase over time), but the discipline that matters hasn't changed: brevity is a performance requirement.

For each line in memory, ask: if I remove this, will the agent make mistakes? If not, cut it. A memory file that grows forever is noise wearing a helpful costume, and the longer it gets, the more instructions get ignored.

The write rule we use: if a fact changes often, stays local to one task, or has low confidence, it lives in session state or an artifact, never in permanent memory. Same refinement logic as the data flywheel: raw context is bronze, durable memory is gold, and curation is where the value lives.

This is the discipline Gartner just declared 2026 "The Year of" under the name context engineering: not "how much context can the model take?" but "what should the model see right now, and what should never be trusted blindly?"

Goals, phases, and testable chunks

Now the rule I'd keep if I threw away everything else: every piece of work starts as a goal, the goal breaks into phases, and every phase must end in a testable chunk.

Every phase ends in a testable chunk Goal one paragraph + harvested context Plan sprint contract: what "done" means, first human gate Agent builds to green write · run · read · fix Verify tests green · diff read tests reviewed hardest human gate testable chunk next phase starts from verified ground The agent never merges its own work. Small chunks keep the unwind distance short when it goes wrong.

Working, runnable code with tests a human can verify. Not "progress." Not a half-wired module that makes sense once phase three lands.

It turns out Anthropic's harness research converged on the same mechanism. They call them sprint contracts: before each sprint, the generator and evaluator negotiate what "done" looks like for that chunk before any code is written, down to granular criteria (one sprint had 27). Spec-driven development has gone mainstream on the same insight ("the spec is the prompt"), with GitHub's Spec Kit formalizing a gated pipeline where every phase produces an artifact the next phase consumes, and a human's job at each gate is critique, not passive approval.

Why it matters so much with agents: an agent will happily generate three thousand lines across five phases in an afternoon. If your first checkpoint is at the end, you have three thousand unverified lines and no idea where the wrong turn happened. Review cost scales with how far back you'd have to unwind a mistake. Small chunks keep the unwind distance short, and each accepted phase becomes verified ground for the next.

The tests deserve the hardest review. When the agent writes both the code and the tests, the tests are the only artifact where your judgment really matters; weak tests are a green checkmark on broken behavior. The canonical loop is TDD's native grammar: write the tests, confirm they fail, commit them, let the agent code to green without touching them.

One research nuance worth knowing: test-driven instructions alone aren't enough. A study of test-driven agentic development cut regression rates from 6.1% to 1.8% using structural impact analysis, but TDD prompts without that structure made regressions worse than vanilla. Verification has to be built, not requested.

Challenges

Challenge #1: curation beats collection

The naive version of context harvesting is dumping everything in. It fails quietly. Attention is finite, and forty pages of transcript make the one constraint that matters harder to find. The skill is distillation: decisions, constraints, requirements extracted; chatter left behind. A page of curated truth beats fifty pages of raw exhaust.

There's a judgment line here too. Emails, texts, and Slack history contain things that have no business in a coding context: personal details, sensitive negotiations, regulated data, third parties who never agreed to be context. An agent that ingested something sensitive from one source can surface it somewhere public. Harvesting always comes with an editing pass, and read-only, scoped collection is the default. What enters the window is a decision, not a dump.

Challenge #2: trust at volume

An agent produces more code than you can deeply read, and pretending otherwise is how teams end up rubber-stamping. Our answer is layered. Phase gates keep each review small. Tests carry the behavioral load, which is why test review is non-negotiable. Skeptical evaluation is separated from generation, per the harness research, because the generator will always grade itself kindly. And human attention goes where risk lives: auth, money, and data paths get line-by-line scrutiny; a settings page gets a behavioral check.

What we don't do is let volume become an argument for autonomy. The agent never merges its own work. The honest maturity level for production teams in 2026 is supervised autonomy, and the adoption gap says that's where the alpha still is: JetBrains' January survey of 11,000 developers found 90% use AI at work, but only 13% use it across the whole lifecycle, with discipline.

Takeaways

  • The bottleneck moved. Writing code is solved; verifying it is not. Hire and train for context assembly and verification design.

  • The repo is the what; communications are the why. Harvest the Granola notes, emails, Slack threads, and texts. An agent with the decision history builds what you meant.

  • Distill, don't dump. A page of curated truth beats fifty pages of transcript, and an editing pass is also how you keep sensitive data out of the window.

  • Every phase ends in a testable chunk. Anthropic calls them sprint contracts. Agree on what "done" means before any code exists, and keep the unwind distance short.

  • Review the tests hardest. When the agent writes code and tests, the tests are the contract.

  • Separate the grader from the generator. Agents can't judge their own work. Your evaluation path, whether a human or a skeptical evaluator agent, must be independent.

  • Build the smallest harness that holds your bar, then subtract. Scaffolding for one model generation is a cage for the next.

If you're building with agents inside your own team, I'd love to compare notes. Reach out.

Further reading

Until next time, Amit.

AM

About Amit Maraj

Author, DVx Ventures