I spent the day at o11ycon 2026 today. Spent most of it talking to people. Watched a few talks. I am beat but want to share a few of my notes before they disappear into the ether of "things I ought to write about sometime."

Stop Building Features

The biggest idea from the conference for me hit in the first half an hour: AI allows people who aren't software engineers to build meaningful software. Those of us who are software engineers at companies should stop building features and focus instead on building systems that allow people on the sales team, the factory shop floor, etc. etc. etc. to ship safely.

Every time I talk to other engineers about AI and what they're doing with it I feel tired. Every time I talk to people who are engineer-adjacent about the software they can build now I start getting excited.

But there's this strong "Wile E. Coyote stepping off of a cliff" feeling, too. What's the blast radius here? What kind of systems do we need to do this "safely?"

This is a weird human-shaped object

"This is a weird human-shaped object and it accepts human-shaped input." - Austin Parker

The hardest thing to really wrap my head around with AI is this weird mix of human and inhuman qualities that it has.

On the one hand: These systems often respond better if you treat them less like a computer and more like a person. The Honeycomb MCP server uses ASCI graphs under the hood to communicate the results of queries to agents, not reams and reams of JSON. The agents can get lost in JSON. Trying to pin down their behavior very precisely with complex prompts often makes their behavior worse.

On the other hand: They are not people. They can be suddenly, startlingly alien. And they don'treally "want" things or "care about" things or "have goals."

I think it's a mistake to treat "AI is sometimes unreliable" and "humans are sometimes unreliable." Both have variable task performance but I don't think it's for the same reasons.

AI Teammates are a Dead End

"The people who get the best results are the people who treat it as an extension of themselves." - Austin Parker

(Incidentally– I highly recommend sitting down next to Austin Parker's laptop and listening to him explain the design of the Honeycomb MCP server if you get a chance.)

There are a lot of people who are very excited about AI operating fully autonomously and entirely replacing human jobs. My take is that agents are going to replace a lot of tasks but that they largely aren't going to replace jobs, for two reasons.

1. Jobs are bundles of tasks and some of those tasks are "o-rings." If they fail the entire job fails. If AI can replace 4 out of 6 tasks involved in a job but not the final 2 it can't replace the job.
2. One of the tasks that agents are generally really bad at is "accountability" which is a core part of a huge number of jobs, and is only going to get more important in a world where agents area big part of work.

It's possible that sometime in the next few years AI companies will crack the accountability problem and I'm just wrong about this but I think accountability that will satisfy a human supervisor requires traits like "an embodied understanding of the world" and "motivations" and LLM-based systems don't have that and they aren't "a bit more training data" away from having it either. This is not an improvement that you can get to incrementally.

Basically I think that the future belongs to "centaurs," human/machine hybrids where the LLMs provides many (most?) of the skills and knowledge and the human provides things like "I care about what my boss thinks of me" and "I want money" and "the ability to explain how things are going."

Is AI going to kill code review?

There was a panel about whether "AI has killed the SDLC"and it was... confusing. I've never worked somewhere that had strict separation between phases like the article describes. But I also don't understand the argument that we "need" code review, either.

I've worked at a lot of places that required code review but whenever anyone talks about why they do code review it seems... obviously wrong?

As far as I can tell code reviews are useful for two things.

• They give a second person a chance to read the code
• Create an opportunity for that person to give some feedback, point out things the first person might not know about

These are good things! You should be reading your colleagues work and talking to them about it!

But people talk about them like they're a... quality gate?

And I guess if your review process is, "pull the PR locally, run it in an environment, explore it thoroughly" then you might be getting some benefit there. But if your process is, "Run the code in your head and then think about where problems might be" then you're not going to catch the most interesting problems with it.

What you are going to do is slow down the change rate in your project and increase context switching.

Anyway, if code review dies because AI overwhelms it, I'll be a little sad that it wasn't because people realized context switching is evil, but I won't be that sad about it.

Tokenmaxxing

In Nathen Harvey's DORA keynote he argued that while token leaderboards won't be good in six months, they're good for now because they're getting people into contact with AI tools and helping leaders identify the people who are using AI effectively, which will help drive AI adoption at the company.

I really wish he'd talked about what the people at the top of those leaderboards are doing with them, because what I have heard is kind of the opposite. Folks at companies that have leaderboards generally report that what people are doing to get to the top of them is obviously stupid and the people at the top of them will tell you this, and it's mostly making other engineers more cynical about AI.

Overheard

• "It is easier to act your way into a new way of thinking than it is to think your way into a new way of acting." (This is Zen.)
• "What's stopping you from YOLOing into production?" "We are a bank."
• "Humans are no longer the primary reader of your telemetry"