Outcome Engineering

It’s a scary time to be a software engineer. Layoffs, selloffs, daily announcements of agentic advancements. Beyond the practical fears of employment, what does it mean to be a software engineer in an agentic world?

What is our purpose? None of us really know yet, but I know it was never really about the code.

The code doesn’t love you back

Look, I get it. I love to code. I’m not an artist or a musician, so code is my paintbrush, my guitar. It is my favorite and most powerful way to express ideas, to create and share things that have to exist in the world.

Coding is also my profession, my vocation. Through decades of training and experience, I know in my bones the impact of algorithms, clarity, structure, and consistency on code maintainability, team collaboration, and product quality.

I can appreciate why

while(*dest++ = *src++);

is adorable but maybe not always the right choice. And even why sometimes it might be.

More than that, no matter the satisfaction of a perfectly typed solution, of an all night session that compiles and runs correctly the first time, time and human capacity are incredibly constrained resources.

And that glory — that high — will turn into crushing disappointment if your customers don’t understand what you built, can’t see why your brilliance is The Right Thing For Them. Seriously. Engineers like to correctly wax nostalgic about the betrayals of Time Zones and fonts, but you really haven’t felt pain until you’re watching a pack of 14 year olds ignore a game you put in front of them.

And of course the complexity of modern systems and organizations wildly outpaces anyone’s ability to truly understand what’s going on, so software engineering has already moved — uneasily at times — from pounding out code in isolation to tight conversations with infra, o11y, data science, and design. And research. And marketing and sales.

Because it’s not really about the code. In fact, it’s not really even software we’re trying to engineer.

It’s outcomes.

Maybe it’s time for a new name. While naming things is only slightly harder than caching, sometimes a new name can help us reframe a problem.

Welcome to Outcome Engineering.

What’s in a name?

If our perspective changes to outcomes, agents and agentic coding move beyond tooling to become our allies and collaborators. Rather than competitors for coding jobs, they are a force waiting to be wielded.

Properly unleashed, coding agents mean every one of us is no longer constrained by time and human bandwidth. Suddenly creation becomes a question of cost of compute, not capacity.

What would you do if nothing had to go on the backlog?

What would you need to know and prove if you had the ability to build the most important ideas, to inform the hardest debates by creating?

So, a thought experiment: what is Outcome Engineering, o16g?

I started with 16 ideas to shape it. You can see them in appropriately manifesto form.

Outcome Engineering starts with:

1. Human Intent. We choose the destination no matter how many agents help us.

2. Verified Reality is the Only Truth. We can prove what we intended to do is what we delivered.

3. No More Single Player Mode. Whether humans or agents, outcome engineering is a team sport.

4. The Backlog is Dead. No critical user need is unmet because of lack of time or capacity.

5. Unleash the Builders. We architect reality, we revel in creation, not the toil.

6. No Wandering in the Dark. Agents understand the territory and current state.

7. Build it All. Every time we build, we learn and our entire process improves.

8. Failures are Artifacts. Even failures make us better and inform the future.

9. Agentic Coordination is a New Org. Scaling agents mirrors scaling people, but faster, weirder, and way harder.

10. Code the Constitution. Decision fatigue is real, build the systems to encode mission, vision, and goals.

11. Priorities Drive Compute. Even with scalable agents, we are responsible for spending well.

12. All the Context. Beyond prompts, beyond docs, agents must have the right context for every decision.

13. Show Your Work. We are engineers, we refuse to accept black boxes in blind faith.

14. The Immune System. Repeated mistakes are system failures, we spend the resources to continuously improve.

15. Risk Stops the Line. Make the proper level of risk for a given project or domain the blocking function.

16. Audit the Outcomes. Everything is in motion, capabilities change overnight, and trust is a vulnerability.

These will change at the speed of agents, but it’s a start.

Welcome to Outcome Engineering.

Outcome Engineering is at the starting line

In an era of every agentic model trying to become a platform, it’s tempting to think we’ll just get this for free soon.

I don’t think we will. At least not as fast as we could.

The specific implementations are too domain and company dependent. Because models from the same provider are way too agreeable with each other, no single source solution will debate and explore ideas like more heterogeneous approaches.

Maybe you don’t call it an o16g team, perhaps it’s just product infra 2.0.

But it will take a team. And new perspectives. A new name.

Maybe a new profession?

Because while this is clearly a home for software engineers, it’s also going to need designers, product thinkers, operations engineers, release engineers, o11y engineers, AI researchers, and a host of other experts in domains who can use agents to express, test, and prove ideas faster than ever before.

Outcome Engineering is going to grow from collaborations of teams that look different than product development teams do today.

Can’t wait. Won’t wait.

Mission alignment and opportunity

At Onebrief, we’re making commander superhuman. Reality and outcomes are already core to our mission and to our products. With agents accelerating our development and product, we have the perfect foundation and team to architect the future.

Want to join us? Check our our open roles or drop me a line.