/ #growth#culture#software-design#team-building#cto

Wiring against the vibe

In Part 1, I wrote about the CTO as the bridge between business strategy and technical execution. Today that bridge is under real pressure. Vibe coding and agentic engineering are changing how teams ship code, and the pace of change is not hype.

I use these tools every day. They are good. An agent can scaffold a service in minutes. It can write the tests I would have skipped. It can walk a codebase I have never seen and hand me a reasonable map of it. For greenfield work, prototypes, and boilerplate, the productivity gain is hard to argue with.

But I have also watched teams treat these tools as a replacement for thinking. That is where things break. Speed without social circuitry is a faster way to hit a wall. Three books have shaped how I think about this: Accelerate, Kill It With Fire, and Wiring the Winning Organization. Each one has something uncomfortable to say about what happens when you optimize for output instead of outcomes.

1. Action Metrics over Outcome Metrics

It is easy to feel productive when your agents are producing dozens of PRs a day. Accelerate showed us why this feeling is misleading. Lines of code and PR counts are the wrong things to measure. They always were. The right metrics are DORA: lead time for changes, deployment frequency, change failure rate, and time to restore service.

In a mature system, headlong agentic engineering, as preached on X, can push these metrics in the wrong direction.

If a team is shipping code its authors do not fully understand, change failure rate rises. That part is easy to see in hindsight. The harder one is MTTR. When the system breaks, someone has to debug it. If no human on the team understands the generated code well enough to reason about it under pressure, restoration takes longer. Performance comes from the capabilities of your delivery pipeline, not the raw throughput of your agents.

We saw this before AI. A team outsources work to an agency, the code comes back, and the in-house team never rebuilds the mental model the agency had. AI agents are the same pattern at higher speed.

2. Translation over Transformation

The most seductive pitch right now is using AI to rewrite legacy systems. Feed the old Java monolith to an LLM, get a modern Go service on the other side. Done.

This misunderstands what legacy code is. In Kill It With Fire, Marianne Bellotti argues that modernization is not a translation problem. It is a contextual integrity problem.

  • Paving the cow paths. An LLM can translate syntax. It cannot recover intent. It will faithfully reproduce 20 years of technical debt in a shinier language, because every line of input carries equal weight to the model.
  • The lack of due process. Legacy systems are archaeological sites of business logic, tax rules, and edge cases. The weirdness is usually not a bug. It is a reason. Bellotti calls the work of recovering those reasons due process analysis. LLMs do not do why. They do statistically likely next token.
  • The result. A modern looking system that is just as brittle as the old one, except now it is a black box nobody on the current team actually wrote.

This is again not a new problem. When Ruby on Rails was in its heyday, one of the clients I had worked with hired a dev agency in India to rewrite their Coldfusion system to Ruby on Rails. The team that took over that project simply ported the codebase page by page to Rails and jQuery. The app worked perfectly fine but the code was unusable. The company had to eventually scrap the entire codebase. Rewriting old codebases in new technologies with LLMs will have the same effect.

3. Slowification

Vibe driven work pushes everything into what Spear and Kim call the Operating Zone. High stakes. Fast pace. Just ship it.

Wiring the Winning Organization argues that winners move problems out of the Operating Zone and into the Solving Zone. The Solving Zone is slow and low stakes on purpose. It is where you build the test suites, the sandboxes, and the runbooks that make the Operating Zone survivable.

It is not wise to celebrate a developer who used an agent to patch production in ten minutes. The right move is to protect the team that slowed down to build a Layer 3 environment where experiments are safe. AI engineering produces code in bursts. It is vital to protect the solving zone and build the engineering pipelines to ensure that you do not have to patch a production bug in 10 minutes.

4. Simplification

Agents make it easy to build spaghetti vibes. Highly interconnected systems that only an AI can keep in its head. Architecture disappears because nobody needed to draw it.

Simplification through partitioning is the counter move. Break the system into small pieces that humans can work on without constant coordination. In the age of AI, architecture matters more, not less. The concepts of coupling and cohesion are as old as OOP and distributed systems. We already know how to solve this. We just have to do it.

Let the AI write the contents of the boxes. Humans still have to draw the boxes. That partition work is the cognitive scaffolding for the next engineer who has to debug the thing. The goal of engineering is to predict, with reasonable certainty, how a system will behave by reading the code, not by watching it in production.

5. Amplification

Slowification is about protected time. Amplification is about feedback loops. They work together but they are not the same thing.

Generated code has a specific failure mode. It looks right. The tests pass. The types line up. The names are sensible. But there is a subtle assumption buried in it that will not surface until production traffic hits an edge case. These are weak signals. In a vibe driven culture they get ignored because nothing is obviously wrong.

Amplification is the practice of making weak signals loud. Two things help.

  • The andon cord. A developer who does not understand a block of generated code should feel safe to pull the cord and stop the line. This is a cultural move, not a technical one.
  • Observability. Rigorous tests and monitoring are how you surface the failure when the model got it wrong. If you cannot see the failure immediately, the AI is not helping you move faster. It is helping you fail bigger.

At ThoughtWorks, we had information radiators on all our projects. We would have CI/CD systems, error dashboards, and application performance dashboards for the entire team to see. This is to ensure that there are no broken windows and the entire organization is informed about the overall health of the system. The point of a radiator is that weak signals become loud signals automatically. Nobody has to go looking for them.

The Bottleneck Is Not Typing

Vibe coding assumes the bottleneck is the speed of getting code from head to repo. In mature organizations, the bottleneck is somewhere else.

  1. Contextual awareness. Knowing why a change in Service A will break Service B.
  2. Maintainability. A human being able to debug the system when the AI context window runs out.
  3. Institutional knowledge. The due process that explains why the system looks the way it does.

Agents solve for typing speed. Wiring solves for the actual bottleneck.

Wire the Win

The value as a CTO is in designing the social circuitry.

If you let AI flood the codebase with unvetted, unpartitioned, undocumented code, you are wiring the organization for a short circuit. Output will spike. DORA metrics will collapse. Legacy debt will become a black box your team did not build.

The winning move is to use AI as a tool and spend the energy on slowification, simplification, and amplification.

Don’t just code the vibe. Wire the win.