Charity Majors

Auto instrumentation has gotten so good in recent years. If you're using Open Telemetry and everyone should be using Open Telemetry. All of the common patterns like all of the models are trained on them. So, it is literally faster and easier to build with instrumentation than to than not to.

But I also think that in my mind, 20 years of DevOps was really about one thing. Trying to create one feedback loop that connected people writing code to that code in production. And it failed.

That was always a bad idea because it's split brain. Half of you are writing the code and the other half are understanding it. I would argue that you can't really understand the code you write unless you're operating it.

And I have decided not to sink anymore because writing is thinking on paper. And there's no shortcut for doing that thinking.

Software is made of logic and language. AI is made of logic and language. And because of that, we can bake in guardrails.

It's like we need to hear the wins. We need to hear what's We need to hear about what's possible. We need to hear what's exciting. But you got to couple it with the costs.

One of the things that's ironic though is that both of these sides feel like they are the tiny minority and they're outmanned and they're being suppressed and they are standing up for what is truth and valor in the face of the big AI folks or the big skeptics.

See, the problem is that neither side is making it up. Like they are seeing really scary trends.

You can use AI as a shortcut to help you not have to think too much. And you can use AI to help you think more deeply and more rigorously. And both of those use cases have their place. But when it comes to your core job function, we primarily want the second one, right?

Here's a baseline. Uh you cannot send anyone something you haven't read. And in fact, if it would take them longer to read it than it took you to make it, it's probably slop.

Another another thing we point out is just there is no human in the loop. You own the loop. The loop is yours. The loop is mine. It would not exist if it was not for me. So I am the owner, right?

If you're debiting from this trust account in the creation of the code, it has to get built up somewhere else.

Okay, if I'm not going to read this code, how do I know it's going to perform within boundaries of the last code that I generated? That is conformance testing.

It's like they have all the wisdom of their most senior engineers looking at every single diff and that is fantastic. Which means that you don't have to worry about remembering and looking and nitpicking and all the things that we're not good at anyway

As soon as you merge, it should be going out. You like you should have to stop the train to make your code not go into production as soon as you've merged.

Production is not what happens after development. It is a stage of development.

it's always weird to me just how much software engineers really seem to believe that the world exists in the repo. It doesn't. It's production, you know?

Like that just does not seem like the ideal artifact. We should be able to store them somewhere. We should be able to have architecture diagrams that we can review and discuss that generate that code to spec.

I mean, if you if you think about it, you could generate 10,000 variants of a function faster than you could write it once.

What I was saying in that piece though was, I think we were right to be skeptical that time. But now, I see the same thing playing out with would you be willing to ship it some code you didn't read? There's no point in arguing about if it will happen or when it will happen. Talk about what it would take.

And it wasn't actually the models. It was the harnesses. It was all the tooling.

We can go fast. Let's do same thing faster, you know, just boom. And I've come to feel like that is a very immature description of what better is.

I also believe that, you know, there's been this whole push towards individual output, but teams are still what matter. Teams output.