I recently attended a talk where one of the presenters made some pretty…astonishing claims about what they had achieved by the pure, uncut power of vibe coding. Difficult engineering problems solved, backlogs cleared. Rewrites that would have aken a year or more in the beforetimes, now whipped out in a few short weeks of prompting. Afterwards, wandering around the conference, I caught a lot of excited chatter:

“I can’t wait to make my teams watch the recording of this talk. My engineers are SO resistant to the idea of shipping code without reading it. Finally, some proof they can’t ignore!”

“Mine are too. It’s so frustrating. People are just so stuck in what they know. I think they’re just scared of being replaced, you know?”

The talk was fantastic. The presenter made it all sound easy, breezy and oh-so-fun.

The problem is, I know lots of other people at his company, and they described these projects as a horror show. Yes, they allowed, some progress was made, and some of it was pretty cool, but he also left a long, fiery trail of chaos in his wake. Months later, some teams were still grinding through waves of cleanup work.

(Please don’t @ me to ask if I am subtweeting your talk. I am subtweeting MANY TALKS. This is a composite.)

I keep thinking back to this episode — the highly selective version of the story that was told on stage, and the room full of AI enthusiasts who seemed to be eating it up with a spoon, uncritically, because it so validated everything they wanted to be true.

I keep thinking about the certainty they took home with them, and wondering how that energy fed into conversations with their teams.

There is a yawning chasm opening up between…oh, let’s call them the enthusiasts and the skeptics, although the battle lines are drawn in many different ways. Both groups are tense, frustrated, and a little scared, and as a result, they have stopped talking to each other. Instead, they talk about each other — as roadblocks, as caricatures, as threats. It’s all,

“THOSE people are AI-pilled and don’t understand software”, vs

“THOSE people hate AI and don’t want to move fast.”

This is not a situation where one side is right and the other is huffing paint. (O, that it were!) Each side is grappling with a real, alarming, escalating threat to the company’s existence, and the closer they look the more (again: real, alarming) evidence they find.

The enthusiasts are not wrong. We are starting to see real, non-imaginary, discontinuous leaps in capabilities from teams that lean in hard to working with AI. And this does not feel like a normal technology cycle where you can wait for the dust to settle; teams that sit this out while competitors are hustling could be out of business before the dust settles. That’s a real, existential threat.

The skeptics are also not wrong. When you ship code faster than engineers can read it, in domains where nobody has full context, you are making withdrawals from a trust account that took years to build. Reliability degrades, institutional knowledge evaporates. You end up with systems nobody understands, products burbling into incoherence, and on-call rotations that grind people up and spit them out. That is ALSO a real existential threat.

Before I go any further, I want to be clear about who I’m writing for. This is not about teams whose management chain is disconnected from engineering realities or paying for McKinsey consultants, or teams with low engineering discipline and trust.

I am not writing for tiny baby startups with no customers or revenue, and I am not writing for behemoths who are on the verge of busting through the red tape to finally get a Claude license.

I am writing for relatively high-performing teams that are transforming from pre-AI to AI-native. These are teams with engineering discipline and skill who care deeply, who are struggling precisely because there are so many legitimate, competing threats and no obvious answers.

I’m talking about the happy case, in other words. It’s still hard as shit.

The wins are real, the costs are real. This ought to be a fruitful source of tension, where skeptics and enthusiasts join up to solve hard problems with their powers combined, Powerpuff Girls-style.

The problem is, the wins and costs are happening to two different groups of people. There is no natural feedback loop.

That conference talk I mentioned? I doubt the speaker was intentionally misleading us. They might not even know about the tire fire in their wake. It has become very easy to do things without context or mastery, and the downstream costs are often invisible to the person who incurs them. All they see is the win.

The skeptics have the opposite problem. They cannot avoid hearing the enthusiasts’ claims, even if those try. But when those claims seem to get bigger and blowsier and less tethered to reality, the skeptics react with escalating cynicism. They hear the enthusiasts, but they no longer believe a word they say.

I have lost track of the number of engineers who have said to me, in exasperation, “I don’t WANT to be an AI hater. I studied AI in school! I think it’s neat! I feel like I’m getting backed into a corner where I have to be a hater because I’m the only one left who gives a shit about reality! Is any of it real?”

Ok, that’s fair. I’ll show my work. Here is my north star example of what “good” looks like.

I have long looked up to the Fin (formerly Intercom) engineering org. When Christine and I put together our AI mandate1 last year, we drew a lot of inspiration from a piece by Darragh Curran, CTO, called simply “2x”, where he challenged the R&D org to double their productivity in the next 12 months.

He recently published some results, showing that they exceeded their goal — they 3x’d their output in 9 months (defined by total # merged PRs divided by total people in R&D). (Yes, PRs are an imperfect representation of reality. I know this, you know this, he knows this. He talks about it in the piece, which you should absolutely go read.)

The results are mixed, which makes a fascinating read. Product defect backlog shrunk by over half. >2x product changes, 39% faster from idea to shipped. Code quality provisionally starting to improve, after a long, scary 18 months of decline. Downtime down by 35%.

That is a real, non-imaginary, discontinuous forward leap in capabilities. This did not happen because AI is magic. It happened because Fin already had exceptionally high engineering discipline, fast feedback loops, and a culture of experimentation and measurement.2

If you want to know what engineering teams founded pre-AI can expect to achieve by embracing AI, there you go. This should be well within reach for the rest of us.

First, a reminder. We care about the same things. We are on the same side. None of us are assholes.3

And we need each other desperately. To chart a safe path between the Scylla of missed windows and the Charybdis of systems melting into slop, we need eyes on both threats as we coordinate, synchronize, and pull together. Hard.

In order to do that, we need to do two things: knit our fractured realities back together, so we are rowing the same damn boat, and apply some engineering rigor to the problem.

The first move is to mend the gap in shared reality. Tell the whole story. You’re allowed to celebrate and get excited about big wins and advances with AI — but invite reflection on the costs and downstream consequences. People are also allowed to surface costs and consequences, but don’t leave out the context of what was achieved or attempted. Be very clear that your shared goal is to figure out how to collectively deliver more wins, bigger wins, with fewer unpredictable costs, not to clamp down on innovation.

This sounds simple. It isn’t. By default, wins get trumpeted in one setting (blog posts, conference talks, all hands) and costs bubble up in others (SRE team meetings, on call, retros, complainy DMs, grumbling over whiskey).

The result is that both sides may feel like they are being unfairly silenced. You might not think that “we aren’t even allowed to criticize AI” is a sentiment that can be widely held at the same time as “all we EVER DO is complain about AI”, but it can and it does. The asymmetry isn’t malicious, it’s structural, and it must be fixed.

If you’re an enthusiast, start here. Next time you do something big that you’re genuinely excited about — “in my spare time over the weekend, I finished a migration we gave up for dead two months ago!!” — YAY, AWESOME POSSUM! GO YOU! Get excited! Tell your coworkers! But ask around to see if there were any unintended consequences on other teams, and include that too. Or tuck in a “P.S., if there was any downstream cleanup work, I’d love to hear about it.” Especially if there’s a power dynamic and people might be afraid to speak up: make it easy. Invite feedback.

And if you’re a skeptic, doing cleanup downstream of someone else’s great AI vibe coding triumph, don’t just mutter bitterly to your fellow travelers. Bring this up in a responsible, friendly way to the person who caused it, or surface it in the same forum as it was announced. Close the loop. It’s how we learn.

Tell the whole story. Normalize this. It’s a steam valve for anger, it makes people feel seen, it bends towards less expensive wins, and makes a better story. It also — crucially — builds the shared reality that makes the next step possible.

Once you’re operating in the same reality, you can have the real conversation. Right now, it tends to go like this.

Enthusiast: “Let’s ship without code review! Company X is doing it. This is clearly where the world is headed. Why do you hate the future?”

Skeptic: “Are you fucking kidding me right now? I’ve got people I’ve never heard of submitting diffs in crayon and you want me to just auto-accept this shit? Your father was non-technical and your mother had a face like a donkey, and together I guess they made you.”4

Both can be right (minus the face thing). Yes, the field is directionally moving toward software factories and AI-validated diffs. Yes, it may be absolutely unthinkable to start auto-accepting diffs given the current state of your codebase and guardrails. Both of those things are more likely true than not, in fact.

But “what’s wrong with you” and “that will never work” are conversation stoppers dressed up as positions. (Remember, you are both very smart and you are on the same side.) The productive version of this conversation is:

“What would it take for you to feel comfortable shipping code to production without reading it?”

Better evals? Better tests? Better feature flags, guardrails, observability? Work on decoupling dependencies and reducing blast radius? Start with something small and out of the critical path? What is the work we need to do to prepare? What comes first, ordering-wise? Can we put that on the roadmap?

Approach this like an engineering problem, not an epistemological debate. What would it take? Start there.

As Nathen Harvey said in the 2025 DORA report: “AI is an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” AI will not solve for a lack of discipline, tooling gaps, or management that is disconnected from reality. If you want to leverage AI effectively, you need to invest in your engineering discipline and effectiveness.

AI is not a replacement for engineering discipline, let alone a shortcut to it. (I realize that is the biggest understatement in the universe.)

Your skeptics are the people you need to metabolize and operationalize these changes in a way that will keep customers from leaving and employees from quitting. But they can only participate constructively when they trust that they are going to be listened to and taken seriously.

Even if you’re an enthusiast, do you care about reliability, customer happiness, product coherence, retaining great employees, and improving engineering outcomes? If so, you should be able to find common ground with other people who care about these things. Align on reality, take a step, check in; rinse and repeat.

You don’t need to trust or think that each other is right about everything, but you must believe that you inhabit the same reality, share some of the goals, and that each of you are reasonable actors, capable of changing your minds.

When battle lines get drawn and sides get dug in, there are many temptations to escalate: to argue against the maximalist version of an argument you read on the internet, or to demolish the weak, straw man version of what your colleague is saying because you can, even though you know they kind of have a point.

It doesn’t help. Try to engage with what your coworker is actually saying, not what some moron said on HN using some of the same words.

A few small tactical bits:

• Mind how you talk about other people to each other. If you privately represent others’ concerns as unserious or unsophisticated (“they’re just clinging to what’s familiar”) to your allies, you quietly influence each other to write them off.
  

• Don’t deny anyone’s lived experience. That is the fastest way to shut someone down and make sure they stay shut off to you. Debate the facts, but let them come to any updated interpretations of their personal experience in their own sweet time.
  

• Get your own psychological needs met. Try to spend time with your team members as human beings, even if it’s just over zoom. A lot of people are massively stressed out and stretched thin right now, and sometimes it can help just to name it and offer a little extra grace. But you can’t give grace if you are running on fumes yourself.

Go pick a fight on Reddit, if you must. Don’t take it out on your colleagues, and don’t project the worst, stupidest version of the Internet’s stance onto them. Deal with reality together. It’s hard enough without borrowing trouble.

If you want ownership and accountability, you need feedback loops. Feedback loops connecting cause with effect are how we learn and make sense of the world. As we write in the upcoming Observability Engineering (2nd ed):5

“Feedback loops that are timely, precise, and relevant enable self-awareness in humans and self-governance in teams. They generally produce the right sociotechnical system behaviors without needing constant correction or oversight.” — Chapter 25, “Systems Thinking for Software Delivery.”

Ultimately, I believe there is a kind of moral authority someone earns by owning the consequences. If you’re the one left holding the bag, you should generally get final say over what goes in that bag. Which means software engineers who own the code should be, at minimum, extremely involved in defining the conditions for the code they agree to support.

But if you want to have sway over what gets shipped, if you want your critique to land, you must have the standing to deliver it. You must be a credible authority on the topic at hand — AI, in this case. So you should be highly motivated to become one. Ground yourself in expert knowledge of the new ways. Make it fervently clear that you’re on board, you see the opportunity, and you want to help everyone get there.

If you’re just arguing against the new ways from a position steeped in the old ways, I’m not sure why anyone should listen to you.

The engineers who shape how AI gets used will be the ones with credibility: they understand the opportunity, the stakes, and the tradeoffs, and they own enough of the consequences to have standing when they push back. Earning that position takes work, but it is work worth doing.

If you’re a senior leader, job #1 is don’t sink the boat. Keep moving forward as you steer the craft between all manner of icebergs, islands, breakers, and other watery graves. Being late to AI and grinding your team down into a pulp are two especially grim risks we must steer between

.

Note I said “leaders”, not “managers”. Some of the most effective leaders of the moment are staff+ engineers, who cannot make anyone do anything, but without whose judgment and good faith nothing gets done. So much of this challenge is about enlisting hearts and minds and building trust. This is often best done by peer counsel.

As management, sometimes you have to ask people to do things they disagree with or go in a direction they don’t love. That’s part of the job. If a hard call needs making and you don’t make it, if you waffle and waver over not wanting to hurt anyone, that’s dereliction of duty.

But forcing something through should always be the last resort. If people are pushing back, they probably have good reasons and you should understand them. Most people can be brought along, with a little understanding. Do the work to bring them.

And if you do end up laying down the law, you better be right. Reality had better back you up, and fast. Because if you forced them into doing something they knew was wrong and wouldn’t work, they are going to resent you for the rest of their life.

And you will deserve it.

~charity

P.S. Thanks to the people who reviewed this draft: Zach McCoy, Dave Williams, Josh Parsons, Emily Nakashima, Graham Siener, Christine. Special thanks to Quail Lincoln and Fred Hebert, who I can always rely on to pick a friendly fight, and to the entire Honeycomb engineering, product, and design crew, whose talent and skill are second only to the size of the hearts and their determination to do right by each other. I am grateful to be in the boat with all of you

.