One early spring morning in 1535, the residents of Stockholm awoke to a most curious sight. Six suns lit up the sky, connected by bright halos, as immortalized in Vädersolstavlan, seen here. Today, we recognize these atmospheric effects as a parhelion (also referred to as ‘sun dogs’)—an illusion caused by light refracting off crystalline formations in the atmosphere.

At the time, the appearance of these false suns caused no small amount of controversy, as they were concomitant with the major social and religious upheaval blazing a trail across Europe at the time—the protestant reformation. In 1527, Gustav Vasa, the king of Sweden, carried out sweeping reforms that demolished Catholic churches and monasteries, depriving Rome of both financial and religious support. A clergyman from Örebro named Olaus Petri, a key ally of Vasa, came into conflict over the way these reforms were carried out. A dedicated reformer, influenced by Martin Luther and Philipp Melanchthon, he found Vasa’s methods to be—in a phrase—excessively worldly, more focused on controlling the power and wealth of the Church in Sweden, rather than on restoring man’s relationship with God.

Petri, among others, witnessed these false suns and found himself moved to preach about them. He commissioned Vädersolstavlan and spoke to his congregation, believing that their appearance was a sign from God. He was not overly confident in his interpretation of the sign, however, and his sermon reflected that. He explained that there are two kinds of omens; ones produced by the devil to lure mankind away from God, and ones produced by God to attract mankind away from the devil—and it’s hopelessly difficult to tell them apart. In the context of the power struggle between Vasa and Petri, the meaning was obvious: the progress of the Reformation, spurred on by Vasa, was indistinguishable from a blatantly corrupt power grab dressed up in godliness.

Vasa, for his part, was unimpressed. Sun dogs were known in the Middle Ages, the effect faded, and life continued as normal. He was so unimpressed with Petri’s response—and the dissension that he was fomenting against his authority—that he had several prominent German burghers imprisoned and accused Petri of replacing the law with his own “act of faith,” to which Petri escalated with increasingly pointed sermons over the next few years claiming that the Devil ruled the world and that irrevocable doom was at hand.

Um, AI? Observability? Hello?

A parhelion is created when light refracts through hexagonal ice crystals in the atmosphere, forming bright spots that appear on the horizon, connected by a faint halo.

You don’t have to squint very hard to appreciate how relevant this is to our current AI moment, where we’re surrounded by token leaderboards, TikTok videos showing rapidly depleting API balances as a handful of brogrammers prompt the next B2B SaaS sensation into life, and an endless stream of OpenClaws spewing text onto LinkedIn.

I argue that these metrics—usage, adoption—are the false suns that we should beware of. The real sun is still there, it’s still bright—and at the end of the day, it’s still us asking, “Are we solving actual problems for our users, and are they having a good experience with our software?”

What do we value?

The agile manifesto famously concludes by noting that ‘there is value in the items on the right, but we value the items on the left more.’ Individuals and interactions over processes and tools, working software over comprehensive documentation, etc. I believe that this basic dichotomy is at the heart of the great dissent in software organizations—places that value what is built and places that value how they build. This is not to say that these are maximalist positions; the most driven ‘what-ers’ do not exist in a permanent state of limbic anarchy, nor do the most fervent ‘how-ers’ exist solely to craft beautiful code.

AI does make this gap highly legible to the organization, though, because it demonstrates which of these values the organization prioritizes. To a what-oriented organization, the benefit of agentic engineering and AI is readily apparent. The outcome doesn’t change—ship fast, forever. This was the desired outcome before AI, because the proof of the what-oriented organization is in the adoption and usage of their products. It can be a ‘measure once, cut twice’ affair as problems can always be put off by throwing more elastic resources at it—more code, more features, more servers, more whatever. The want of the what-er is that there’s not enough hours in the day to deliver everything.

How-ers tend to optimize for different outcomes. These organizations still want to build software, but the outcomes they value tend to be ones of omission rather than inclusion. This is to say, the point of the process is to protect the organization by not doing the wrong thing. Code is expensive, after all. Even if it’s cheap to write, it’s costly to maintain. Every new service, every new dependency, each of these creates compounding risk. Clearly, these teams also want to build reliable software that solves problems for their users, but their challenge is that there’s not enough hours in the day to deliver that value while meeting their safety constraints.

Personally, I’m a what-er. It’s why I’m drawn to open source. Got a great idea? Build it. If it’s great enough, people will come! When I discuss this dichotomy with friends, I get opinions on both sides of this divide, but one that’s really stuck with me was a buddy of mine saying that “I’ve never cared about writing code except to meet whatever constraints exist… I do not want to code, I want to have coded.” Other friends have put forth the exact opposite argument, around craft identity. “People mostly still want to do work they recognize as good, which is not always the same as whether the customer values it.”

This isn’t in and of itself a novel observation—Hofstede identified “process-oriented vs. results-oriented” culture decades ago. More recently, Westrum’s typology of organizational cultures maps the ‘what-ers’ to a generative culture and the ‘how-ers’ to a bureaucratic one.

The challenge that both of these camps face is that AI is rapidly clawing away at the boundary of ‘how.’ A year ago, ‘slop PRs’ were the bane of open source maintainers. Today, frontier models like Mythos are restricted due to emergent capabilities around cybersecurity. Things that weren’t true yesterday might be true today, and adapting to these changes takes more time than the pace of innovation is allowing. I believe this is why this cultural split is crucial for understanding AI adoption. Generative cultures already exist in a space where adaptation comes easier to them, and they’re able to lean into this accelerated rate of change.

‘Production’ means a lot of things

A recent blog argued that production is where the rigor goes, and I’d tend to agree, but I’d also extend that into our framing of what vs. how. Production isn’t just running code, it’s not CI, it’s not any of the arbitrary divisions we might make about how and why code runs. Production is the combination of what and how. Production exists as knowledge, embedded into the channels of how software is built and operated at a company.

In my experience, generative cultures tend to outperform here. Conway’s Law is instructive, but a paper from MacCormack, Baldwin & Rusnak in 2012 validated the intuition that loosely-coupled organizations produce more modular products than tightly-coupled organizations. These loosely-coupled products, by definition, require less knowledge transfer across the organization because they assume that callers will self-regulate and that their domain boundaries are inviolate.

Conversely, bureaucratic organizations rely on greater social and team cohesion in order to achieve these benefits. This can result in cleaner architectures and simpler deployments, but with a tradeoff—the blast radius of changes is less understood. Dependencies are meshed together, and it requires more explicit coordination between teams and individuals to ship cross-functional changes. Documentation, and personal experience, become more paramount; there are always things that aren’t written down.

DORA has found in the past that loose coupling is positively correlated with all four delivery performance metrics, so evidence exists that counters the implication of ‘generative == fast but shoddy’ and ‘bureaucratic == slow but stable.’ We know that the best organizations get both! What we’re missing with AI is that AI has to be a co-equal partner to humans in the development lifecycle in order to gain these benefits as well.

If production is embedded knowledge in the team, then yes, AI is a black hole for knowledge assuming your knowledge transfer mechanism is humans talking to humans.

Let’s talk about this through the lens of code review, often the throttle of iteration in any software organization—especially modern ones. Irrespective of how process-driven your review standards are, at the end of the day, review is a personal judgement call between the reviewer(s) and authors. Cross-team PRs wind up with both a higher perceived burden on both parties (the reviewer is probably busy with their own work and has fewer soft escalation paths available when dealing with cross-team dependencies, while the reviewee is almost certainly working on something adjacent to their portfolio and doesn’t have a great attachment point for streaming their work into the reviewer’s) as well as far lower acceptance/merge rates in most places.

Why is this? You might intuit that the reason has little to do with code quality; even small changes can suffer from this review burden. Indeed, most code review has more to do with the rate of change of the knowledge graph of the business. It’s less “this code is good” and more “I’m willing to accept the future operational debt of this code.” Even in businesses where review is not the primary throttle (e.g., deployment-constrained orgs) the basic logic still remains true: the quality of the code is secondary to the organizational dynamics.

Perhaps even more paramount, though, is that code review is an organizational proxy for who even counts as a developer. Even in the most valorous organization imaginable, there’s extremely real status erosion via AI! If designers, product managers, or sales engineers all have equal capability to make broad changes in response to perceived or actual demand, you have to wonder about the actual value of existing developers in the organization. I can assure you that your developers are thinking of this.

The false light

Right now, we’re all staring at the horizon, trying to interpret the omens we see in the sky. What-ers think the bottleneck in delivery is always speed. AI removes it, problem solved. How-ers think the bottleneck is rigor. AI threatens it, circle the wagons.

Speed without verification is just generating expensive garbage, quickly.

Rigor that depends on humans carefully reading every line of code doesn’t scale.

The actual bottleneck of software development has always been feedback.

The solution has been there all along, behind our false lights. In the same way that tests verify intent against specification, observability verifies behavior against reality.

DORA’s State of AI report in 2025 noted that AI acts as an amplifier for existing culture. Strong teams become stronger, weak teams struggle more. Focusing on individual productivity, token usage, or PRs generated is the wrong way to look at it.

In 2024, DORA found that a 25% increase in AI adoption was associated with a reduction in stability, even as respondents reported higher individual productivity!

Giving your developers access to Copilot or Cursor and saying you’ve ‘adopted AI’ is like pouring rocket fuel into a lawnmower and thinking you’ll cut your grass twice as fast. Instead, you’ll probably just catch your lawn on fire and go through a few different lawnmowers.

Observability acts as a great leveler for this discussion because it’s a verification loop that can not only encode intent—instrumentation of code becomes a form of communication between humans and agents, between humans and other humans, between the past and future you—but also because it makes the question of “who’s a developer” irrelevant. The answer to this question is determined by production behavior rather than your position on the org chart. It’s not a crisis for a designer to ship a PR as long as the outcome is verifiable. Observability democratizes the verification function in the same way that AI democratizes the creation function.

Petri looked at the horizon and saw omens he couldn’t understand, and preached caution. We’re staring at the same sky, seeing the same uninterpretable signs (token leaderboards, open PRs, and increasing burnout). Unlike Petri, we have instrumentation, telemetry, and the ability to verify the change we’re making in the world. Let’s use it.