It was never about the code is an even more important realization six months after I originally published the Outcome Engineering Manifesto. As a colleague pointed out, where Steve Jobs had suggested that computers were “bicycles for the mind,” in an agentic world it feels more like we suddenly have Concorde and flying cars for the mind. A lot has happened in the last six months:

• The SaaSpocalypse unevenly wiped over a trillion dollars in market capitalization
• Optimists and pessimists drew battle lines over agentic development
• Frontier models kept improving on a 4-month doubling cycle

My hypothesis in January was that we had 6 months (+/- 1) before coding agents achieved parity with human coders — a pretty solid prediction as it turns out — so at Onebrief, we started exploring outcome engineering. We built job descriptions, hiring pipelines, and integrated outcome engineering into all aspects of development. We learned, made mistakes, delivered critical outcomes to customers, and then learned some more.

Outcome Engineering in practice

This has been a successful experiment. In the midst of all the outrage farming and AI debates, we successfully hired uniquely shaped engineers who had already embraced agentic development. Even better, we have seen their skills and outlooks positively influence the rest of the org. Outcome engineer job recs also helped us meet a ton of experienced software engineers who were already using agents to force-multiply what they’d have been able to accomplish on their own.

However, creating a new ladder amidst massive technical change was always going to be an adventure, so I am sharing the ups and downs.

What went well:

A new ladder. The core idea behind inventing a new title came from the certainty that nobody really knows what skills will be most valuable as agents continue to improve. We knew we could hire great software engineers, but what if late 2026 required different skills? Outcome Engineering created the opportunity, the wiggle room, to hire driven, curious, mission-aligned people who didn’t necessarily bring exactly the same mix of expertise we currently had.

Blended skills. The breadth of the outcome engineering job description meant new teammates with a broader distribution of core product development skills across the traditional product development spectrum of tech, design, and product. Those experiences plus agentic coding created flexibility and strength, especially when exploring unknown unknowns. Self-identified outcome engineers – both new hires and existing team members who’ve asked to switch ladders – are substantially more likely to embrace ambiguity, to be fearless when chasing problems into the unknown.

Development speed. The headline is 2x throughput¹ in feature delivery to customers, with even greater gains across total commits, bug fixes, and refactors. For well-understood, tested code, porting or rebuilds are many orders of magnitude cheaper than in the past. We aren’t good at really understanding what a single order of magnitude changes, let alone changes of 4 powers of 10. In the past I’ve believed in optimizing for fewer programming languages across an org, but today I’ve changed to “what is the best language for the specific problem at hand?”

Hiring. A benefit of committing to outcome engineering — to agentic co-development — is the opportunity to embrace it in the hiring process as well, to bring the interview experience much closer to our development culture and environment. We’re still experimenting and iterating here, but early results are promising. But even before we brought up those versions, agentic hiring felt a bit like old-school game hiring, where if a candidate didn’t have things to show you, it would be a pretty short interview. How can you be a developer in an agentic world and not have a ton of demos to share?

The challenges we’re working through:

50,000 loc commits. While fearlessness leads directly to novel and innovative solutions to long-standing problems, it also puts pressure on existing systems and processes. Testing and tooling built for human-scale development velocity just don’t support what agents are capable of. Old definitions of demo vs. production don’t function well when so many great ideas are demonstrated in code and there’s a desire to get those ideas in front of customers. Product infrastructure, test and quality infra, and o11y all have to improve in tandem.

Norms take time to develop. Slop grenades are nobody’s friend. Colleagues deserve – and expect – discussion and debate to start from documents and code fully shaped by human intent. But it’s also true it’s worth getting excited about the vibe-coded monstrosity that proves something previously thought impossible could work! Safety, trust, and collaboration – and effective management to foster it – become even more critical.

It’s all single-player. The flood of bad solutions to this is starting, but overall way too much of agentic development is a developer and an agent talking to each other. This model robs us of so much context, discussion, collaboration, and joy. Onebrief is a fully distributed company, so we use hackathons and other events to bring people together, and even in one room, agentic development makes the process a lot less collaborative and fun. Opportunities abound here.

Not everyone wants to be – or sees themselves as – an agentic developer. This is by far the hardest one. If you’ve spent your life as a programmer, you’ve had a 20+ year run being at the pinnacle of earnings potential, impact, and fun. It’s been pretty incredible. But the change coming from agentic development is inevitable. My hope with outcome engineering is to create a joyous path forward for those who want it, but I am incredibly empathetic to those who don’t see that future for themselves. The reality is that five-person agentic teams are already doing what 20+-person teams did 6 months ago, and that trend isn’t slowing. My goal is to continue to create on-ramps to outcome engineering for anyone who wants to build that way.

Enter Outcome Development

I believe the best way to accomplish that — to build paths enabling the entire team to better deliver outcomes for the customer — is to move outcome thinking beyond engineering. Welcome to Outcome Development.

If Outcome Engineering — o16g — is about writing code with agentic support, Outcome Development is about the development methodology, the processes, and systems for agentic development. It starts with recognizing the dramatic difference in the cost of product development and opening the aperture, because once it’s not about typing, everyone can rethink how they’re executing and delivering outcomes.

It’s a natural outcome of embracing outcome engineering and unlocks the next level of capabilities. Yes, agents can remove the constraints of human bandwidth, but until that capacity is focused through risk and quality gates, until code review, testing, and o11y are as advanced as prototyping, we’re only capturing partial wins.

Outcome Development — like Outcome Engineering — is about building systems, processes, and tools to move as fast as you can identify the need. No worrying about backlogs, no waiting on resources.

We’re not there. But we can see the playbook. While Outcome Engineering had 16 principles, Outcome Development is simpler.

Speed of learning in production is the gate. Features, rewrites, experiments are all orders of magnitude cheaper than a year ago, so the actual limit on product improvement is how quickly you can learn in production. Anything that limits that – coordination costs, misaligned goals, flaky tests, product infra decisions that confuse agents, weaksauce o11y, poor capture of user feedback – limits your ultimate development speed.

Minimize global coordination needs. Even agentic development speed can’t overcome the O(n^2) cost of coordination, but the best way to optimize something is to not do it. Almost any investment in alignment, goal setting, product architecture, team communication, and customer understanding that reduces the need for global coordination is worth doing.

Code is worth $0. This is not a statement about developers or personal value. It’s a reminder that there are no technical moats anymore. No reason to be scared of a rewrite. No reason not to explore different language options. No reason to treat any subsystem or feature as sacred because of the code.

Try to have an agent do it. If it’s an inefficient task or one that is still scaling with people, at least try to have an agent do it. And keep trying, because the agents are getting better and better. Consider code review. It’s expensive and challenging to do a truly great agentic code review, one that not only reviews the code, but also considers long-term company and technology goals, and shares knowledge with team members. But what gets unlocked once you do it?

Everyone learns by building. Outcome Development organizations welcome everyone to explore, communicate, and learn by creation. Why debate two ideas when you can build and deploy both? Why not show a prototype to a customer in the field? Why not ask an agent to help remove some impediment or inefficiency that’s only obvious in your corner of the company? Outcome Development welcomes this because whoever started the work on an idea, the team needs a way to deliver it safely to production and learn. Inevitably, this means outcome roles move beyond outcome engineers. Why not add Outcome Designers, Outcome Managers, Outcome Reliability?

I look forward to our next update at the end of the year. If you want to join us on this journey, we’re hiring!

1. Many confounding factors, of course. We reorged into a more flexible structure, which increased development velocity separately from AI gains. Other metrics align as well: commits are 3-4x higher, customer relations are improving with more user satisfaction, etc. ↩