Navigating the Fog of War: Age of Empires, AI Agents, and the Rise of Dark Code

This was a 1 hour round-table discussion with CTOs from Canada (TrueNorthCTO) on May 6th 2026. I gave the main talk and during certain parts we went into discussion mode. It was a lot of fun and afterwards there was plenty of discussion on their Slack channel, or so I heard, I'm not on there as I'm not a Canadian CTO ;)

Welcome, everyone. Today, we’re going to talk about "dark code," the value of system visibility, and what a classic real-time strategy game can teach us about managing modern software organizations. We’re living in one of the wildest eras of technology shifting under our feet, and as technology leaders, we need a new mental model to survive it.

To give you a bit of context, I'm 38 years old and have spent my career navigating different software paradigms. I spent seven years at Mendix, a low-code platform pioneer, which started in the Netherlands and then moved it's HQ to Boston. After that, I became the CTO of an online eye-testing medical device company in Amsterdam, where I learned a massive amount about regulations, building teams, and writing patents. I then spent three years working as a fractional CTO across 8 different companies, and today, I am the co-founder and CTO of Comper, which, if you look at my career timeline (7, 5, 3 years), will likely only be around for 1 year ;)

Jokes aside, we’re building a company to solve the very visibility issues I faced at every single company I was at before. At Comper, we make maps for software systems. It’s a simple philosophy: if you are lost, the very first thing you want to get your hands on is a map so you know where you’re going. We are trying to bring that exact utility to software.

We started the company in October, and things are moving incredibly fast. We are currently a team of seven full-time people, plus a few part-time contributors.

Our product provides a collaborative digital canvas that ingests your Git data to visually surface various aspects of your code landscape. You can zoom out to see the macro architecture or zoom all the way down to individual code details, allowing both human teams and AI agents to explore and explain code systems together.

Before diving into the core analogy, I want to pose a couple of questions. These aren't for immediate answers, but we'll come back to them later:

• What organizational issues have you seen stem from people simply not understanding how the technology in their own company works?

• How are you dealing with the enormous, unprecedented volume of code being created today via AI?

• What do you wish you had deep insights into that currently stands as a blind spot for you; and what do you wish other business leaders understood about your stack?

If you’ve ever played Age of Empires, you know it's a game entirely driven by a mechanic called the Fog of War.

When the game starts, the entire map is pitch black, it is completely unknown. When you send a scout out on a horse, you can suddenly see exactly what that unit sees in real-time. But as soon as your scout moves away, that territory relapses into a state of gray fog. You can still see the permanent outline of the terrain and buildings, but you have no idea if enemy units are moving through it. To maintain visibility, you have to strategically build watchtowers and position outposts to ensure the enemy cannot maneuver in the dark.

The absolute best Age of Empires players master this mechanic to dominate the game. They possess distinct traits:

• Extreme Velocity: They move so fast that they hit you before you even realize they're coming.

• Proactive Control: They dictate the pace of the game and take the fight to you; they are virtually impossible to surprise because they see threats miles away.

• Resource Efficiency: If you look at their resource graphs at the end of a match, they don't sit on vast, unspent hoards of gold or wood. They gather exactly what they need and build an army that is just good enough to win.

As CTOs and VPs of Engineering, our CEOs always demand that we build things good, fast, and cheap. We usually tell them to pick two. Yet, top strategy players manage to achieve all three simultaneously. 

Let’s look at three perspectives on how we can apply these lessons to our software organizations.

In the grand scheme, the game map is the broader market, and you are the player. Your army is your engineering team, your resources are capital (raised via investments or generated through sales), and your tech tree is your software stack.

To win against the world, the best companies optimize their internal feedback loops. They eliminate friction ruthlessly, ensuring pull requests are merged rapidly and customer feedback is captured instantly. In game terms, they place their villagers directly next to the gold mine to accelerate the economic engine.

They stay in control by investing heavily in research and scouting. They don't just build blindly; they set up watchtowers to evaluate shifting technology. This is incredibly critical right now, as the tech industry has never been more in flux due to AI. Furthermore, they maintain strategic reserves of time and money to absorb sudden market disturbances. Finally, they build cheaply by validating and selling a concept before over-engineering a massive full-feature product when a simpler solution would have sufficed.

Interestingly, the top companies also use the Fog of War to their advantage outside their walls. Keeping your internal roadmaps and strategic pivots hidden from competitors and vendors provides immense bargaining power.

While the Fog of War is a useful defensive tool against the outside world, it is an absolute disaster when it exists inside your own company.

Whenever I’ve stepped into a new company as a fractional CTO, I've felt like I was navigating in the dark with nothing but a tiny torch. You can see a small sliver of code here, a tiny team interaction there, and you slowly try to construct a holistic mental model.

In a massive, complex enterprise, it takes an incredibly long time to piece that puzzle together.

The real danger occurs when different leaders operate on completely conflicting mental models of the same technology stack. I've witnessed immense organizational drama because of this misalignment:

• The Oblivious CEO: I once worked with a CEO who spent five years funding a single-tenant, gig-economy application. He suddenly decided he wanted to instantly pivot it into a multi-tenant, white-labeled platform, genuinely believing it would be an effortless switch. He had zero grasp of the profound architectural implications.

• The Blind CPO: I saw a Chief Product Officer make a disastrous decision to merge two entirely separate platforms. One stack was built on C# and Azure; the other was Java on AWS. He assumed that simply shifting engineers between teams would allow them to blend the platforms seamlessly. The engineering teams knew it would fail due to wildly disparate APIs, stacks, and cultures, but leadership pushed ahead blindly.

• The Reckless VP: I watched an incoming VP of Engineering immediately lay off a handful of engineers solely to make a visible corporate impact, entirely unaware that he had just fired the explicit linchpins holding the core infrastructure together.

We now went into a roundtable discussion on this topic, an audience member noted that a massive portion of a technology leader's role is balancing tech clarity for the C-suite without causing their eyes to glaze over. Another participant pointed out that architectural analogies are our best defense. Explaining that you wouldn't try to build ten concrete floors on top of a single-family residential house because it would obviously implode.

Another leader shared the acute friction of running a nimble, greenfield AI startup division inside a larger scale-up. Business executives frequently point to tiny, three-person external competitors and demand to know why an enterprise engineering organization supporting a ten-year-old codebase can't match that exact turnaround speed.

So my conclusion is that this is how the best technology organizations work. They have systems for onboarding and documentation, and measure and maintain it very well.

The third perspective centers on how we manage AI agents.

A couple of months ago, this blogpost did the rounds. The "five" or actually six levels of agentic engineering. It takes inspiration from the car industry where there are also distinct levels of autonomy:

• Level 1: Spicy Autocomplete — The initial wave of IDE code completion assistants we grew used to a few years ago.

• Level 2: The Coding Intern — Delegating minor isolated tasks, such as asking an AI to rewrite a specific function.

• Level 3: The Junior Developer — Handing off simple, end-to-end tasks and reviewing the output later.

• Level 4: The Developer — Treating the AI as a functional team member that autonomously investigates an issue and submits a pull request for human verification.

• Level 5: The Agentic Team — Deploying multiple sub-agents that collaborate uninterrupted for 12 hours or more on complex objectives, updating documentation, and fixing code across boundaries.

• Level 6: The Dark Software Factory — An operating model where code is autonomously generated, compiled, and deployed without a human ever reading or reviewing it.

The clear litmus test for moving into the Dark Software Factory is token expenditure; companies operating at this level burn $1,000 a day in LLM tokens per engineer. Very few companies are there, I am certainly not.

This brings us to the core definition of Dark Code: software that no human has ever written, read, or reviewed. While this is accelerating rapidly due to AI, dark code also exists in legacy systems. Many enterprises rely on ancient mainframe software where the original human authors left the company decades ago, leaving a grey box that nobody truly understands.

The terrifying reality of agentic velocity is that our human management tools have failed to keep pace.

Consider this real-world example from our own team: our designer used an AI agent to adjust frontend layouts and test the visual output directly on screen. Once satisfied, the agent generated a single pull request spanning 211 files and over 7,000 lines of code.

When Git platforms present this change as a standard, flat wall of code text, a comprehensive human line-by-line review becomes literally impossible. In practice, engineers look at the green checkboxes, see that the automated tests passed, verify the UI looks fine, and hit merge. We are losing granular visibility of what is happening under the hood. For a hardcore software engineer who prides themselves on elegant architecture, this reality is deeply uncomfortable, even if the resulting development speed provides an undeniable dopamine hit.

So again, in the agentic world, we can learn a couple of things from AoE. Make sure your codebases are top-notch: CI/CD, linters, quick reviews. Keep docs up to-date automatically. Explore new solutions. Make sure tech debt is tracked, and keep your context windows up to date.

During our discussion, an audience member posed a fundamental question: "If AI is generating and parsing code at this velocity, is traditional, human-consumable documentation even relevant anymore?" One participant revealed that their organization completely abandoned writing standard internal readmes for humans. Instead, they write "meta-documentation" specifically formatted for AI consumption; explicitly mapping out service boundaries, architectural rules, and information flows so agents don't waste millions of tokens rediscovering the environment. To combat the sloppy code duplication that agents naturally introduce when working in isolation, they run nightly cleanup agents to ruthlessly refactor and prune the codebase.

However, as another roundtable member argued, "epistemic debt"—the risk of completely losing the human understanding of how a system functions, is incredibly dangerous. We have already seen major cloud outages extend for hours simply because the on-call human engineers didn't understand the underlying automation well enough to fix it when it broke. Senior developers must maintain high-level conceptual maps of the stack, even if they cede line-by-line execution to the machines.

We have arrived at a fascinating, paradoxical crossroads: as a society, we have never relied more on software, yet we have also never understood it less. To understand this transition, we can look back at early 20th-century manufacturing.

When electrical power first became available to industrial factories, managers didn't immediately change how they built plants. For the first 20 to 30 years, factories kept the exact layout of the old steam-engine era. They maintained a single, massive central drive shaft running through the ceiling of the factory, powered by a massive central motor, and mechanically hooked individual electric tools to that turning shaft.

It took decades for industrialists to realize the true paradigm shift of electricity: you could entirely eliminate the complex central shaft, run flexible wires through the grid, and place a tiny, independent electromotor inside every single machine.

Right now, we are in that exact same awkward middle phase with AI engineering. We are using incredibly advanced agentic capabilities, but we are still forcing them to work within the legacy "central drive shaft" paradigms of flat file repositories and line-by-line text pull requests. We desperately need entirely new visual and architectural tools to manage this paradigm. Fortunately, unlike Age of Empires, the rules of the real world aren't fixed. We have the agency to invent the new tools ourselves.

This brings us back to the map. To navigate this sea of dark code, tech leaders need an altitude-adjusted view of their infrastructure.

When Comper connects to your GitHub or GitLab accounts, it parses the entire system into a live, multiplayer canvas. Instead of cloning fifty separate repositories and running throwaway terminal commands to understand an ecosystem, teams can look at a unified landscape.

We allow you to toggle various data overlays instantly:

• Code Complexity & Health: Highlighting highly complex or problematic areas in red so you can visualize structural risk

• The Bus Factor: Color-coding the canvas based on authorship so you can instantly see knowledge silos. For example, you can filter by a specific engineer to see exactly which components they've touched over the past year.

• Code Velocity & Age: Shading components based on how recently they were modified, providing an instant heatmap of where active engineering hours are being spent.

We also auto generate documentation and keep it up to date when the codebase changes.

This was the end of the talk, we then had another 20 minutes or so of discussion.

When an audience member asked how to translate these visual "red zones" into language a CEO actually cares about, the answer came down to product roadmapping. If we map explicit software features directly onto this canvas as first-class citizens, a CTO can tangibly show business leadership: "You want to build feature X. To do that, we have to cut directly through this highly complex, technical-debt-heavy red zone. This is exactly why it will take 20% longer and cost more money." Visualizing true cross-application dependencies gives engineering leaders the exact empirical backing they need to justify architectural refactoring to boards and executives.

When you begin measuring lines of code or raw engineering hours directly, the metrics inevitably break down under Goodhart's Law, especially when AI can generate thousands of lines in seconds. But by tracking feature cycle times across a visual system map, we can accurately measure true organizational efficiency.

To leave you with a final bit of irony: when we originally started building Comper, we built a mini-game inside it inspired by Geoguessr. The tool would show an engineer a random snippet of code from their company's repository, and the engineer had to guess where on the corporate software map it belonged. It was an amazing, fun way to test codebase literacy.

But as AI adoption skyrockets and engineering teams produce vast oceans of code they've never personally read, we've noticed something funny: the game has become completely impossible to play. Nobody knows the literal text anymore. The era of dark code is officially here, and it’s time we built the maps to navigate it.

Thank you very much for your time.