The Brueghel Protocol: Why Agentic AI Demands Less Management and More Leadership
In the Musées Royaux des Beaux-Arts in Brussels hangs a masterpiece attributed to Pieter Brueghel the Elder. Painted in 1558, Landscape with the Fall of Icarus looks like a peaceful pastoral scene. A ploughman works his field, a shepherd tends his flock, and a stately galleon sails toward the horizon.
But look closely at the lower right corner, right into the green waves. There, you’ll see a pair of white legs disappearing into the water. Icarus’ wings, bound by wax, had melted, and he plummeted.
W.H. Auden famously captured this in his poem, Musée des Beaux Arts:
"...how everything turns away
Quite leisurely from the disaster; the ploughman may
Have heard the splash, the forsaken cry,
But for him it was not an important failure..."
I love this painting. It is not for the brushstrokes, but for the brutal truth of its story. It is a story about how easy it is, when we are all so very busy, to look right at a disaster and sail (or plough, in this case!) calmly on.
In our current rush toward AI-driven velocity, engineering leaders are making the exact same mistake. We are so infatuated with the speed of our new tools that we are missing the splashes in the water.
The Self-Preservation of the Four-Hour Recompile
I started my career as a compiler back-end developer in the 1980s, working predominantly in Assembly code and C. Assembly is fiercely unforgiving. Back then, there were no linters, no static analysis tools, and no automated testing suites.
Worse, recompiling the compiler took roughly four hours.
If you made a mistake, you fixed it, but you wouldn’t know if it actually worked until the clock ran out. I much preferred being at the pub or at home to trekking back to the office at 11:00 PM to check a failed build. Writing code that worked the first time wasn't an act of genius; it was a strategy for self-preservation. It forced a microscopic, agonizing focus on detail.
Today, that discipline is evaporating. We have trading desks, SaaS platforms, and agentic tools that can generate code in milliseconds. But velocity without rigor is just a faster way to drown.
2006: The Ghosts of Gurupa
We’ve seen this play out before, long before LLMs. In 2006, while at Amazon, we undertook a massive, high-stakes migration. We were ripping out our monolithic website rendering platform, Obidos, and replacing it with a service-oriented architecture (SOA) called Gurupa. You can still see the relic of that shift in Amazon URLs today: amazon.com/gp.
Moving an empire to SOA requires absolute, synchronized alignment. Every team had to meet the same API standards and deadlines. As the launch date approached, the vast majority of the org was buzzing.
But a few teams went quiet. Uh oh.
They weren't speaking up about their blockers. The rest of the company was ploughing ahead, while these teams had fallen into the ocean and were quietly drowning. We didn't punish them. Instead, we flooded them with attention. We emphasized that if they failed, we all failed. We injected additional resources and thoughtfully accepted calculated technical debt, which we guaranteed would be repaid post-launch.
We executed the switchover country by country over a grueling 24-hour period. We set up a war room packed with 30 people, whiteboards, and a mountain of pizza boxes. Every time a country successfully migrated, we checked it off. (I later had everyone sign that whiteboard, took it down, and encased it in perspex for posterity.)
The launch was a massive success. A few days later, during a review meeting, Jeff Bezos leaned over to me, smiled, and quietly said, "No more big bangs."
He was entirely right. A single missed detail in a global "big bang" hull can sink the entire ship.
The Illusion of Autonomous Velocity
Fast forward to today. We are in the era of Agentic Software Development, where autonomous digital agents don’t just suggest code, they execute outcomes.
The intoxicating promise is that we can build faster than ever. But consider this: if an AI agent can write 10,000 lines of code in seconds, it can also generate 10,000 lines of invisible, structural technical debt just as fast.
When a system fails under this new paradigm, I already know what the weak engineering manager will say: "But the app did X."
Let’s be ruthless here: "The app did X" is merely a poor workman blaming his tools.
AI agents are tools, nothing more. Tools are wielded by humans. It is the human who must possess the high-value judgment, the architectural vision, and a deep understanding of the signals indicating a deviation from the plan. If you do not know what your tools are doing, you have abdicated your role as an engineer.
The True Cost of Leadership
So how do we leverage agentic velocity without missing the details?
It isn't a tooling problem. It’s a cultural one.
We don't need management by fear, and we certainly don’t need leaders who hide behind automated green checkmarks on a CI/CD pipeline while their teams go quiet. We need intermediate milestones designed to catch deviations early. More importantly, we need a culture where throwing a red flag on the field is celebrated.
We win together, or we lose together. Admission of a mistake or a struggle shouldn't be a source of embarrassment; it is a data point for collective learning.
When you walk into your office or log into your workspace today, look past the vanity metrics of your sprint velocities and deployment frequencies. Stop acting like the ship in Brueghel's painting, sailing calmly along, assuming everything is fine just because the sun is shining.
Your job isn't to marvel at how fast the ship is moving. Your job is to watch the water.
Don't miss the splash.
————-
Notes:
I chose to spell Plough and Ploughman in the British way, a nod to the country of my birth, where I first became aware of Brueghel’s work. Plus, Auden uses Ploughman. So there.
I quote Dave Farley almost daily!
