Lately, I’ve been thinking a lot about what it actually means to write software in this new era. Not the tools themselves, we’re all already talking about those, but the habits and assumptions we keep carrying forward without questioning them.

I keep noticing that some people move much faster than others, that a small group seems to “get it” while the rest struggle to keep up. The instinctive response from most organisations is to push more guidelines, more documentation, more examples. But skill doesn’t spread through documents. It spreads through momentum, through systems that make the right thing the easy thing.

I still hear estimates framed in months, and most of that time isn’t spent coding. I’ve had variations of this conversation with founders running small teams and with peers in organisations of hundreds of engineers. The pattern is familiar: AI tool adoption is heavily skewed. Smaller teams, often working with smaller codebases, use more AI tooling and ship more features, sometimes almost entirely written by AI.

That’s far less true in larger companies. There, AI is used for debugging, security fixes, infrastructure work, incident response, parsing logs, and observability. But feature development still moves slowly, unless you’re building something net new. Most of the time is spent orienting: understanding the system, aligning with other teams, and figuring out where changes are supposed to live.

That’s not a tooling problem. It’s a routing problem.

If we don’t know how work flows through a codebase, no amount of AI assistance will save us. A single, ever-growing “source of truth” file doesn’t solve this either. High-level context is useful, but most daily work is local. People don’t need a god’s-eye view of the entire system; they need a sharp, well-scoped understanding of the part they’re touching.

What feels missing is abstraction at the right level. Instead of expecting every developer to reconstruct the system from scratch, manually or with an AI, we should be encoding knowledge where it belongs. In practice, that looks like:

  • Agents that understand specific modules.
  • Workflows that know how changes propagate.
  • Orchestrator’s that connect the dots across boundaries.

That’s where speed actually comes from. And that’s also where the real challenge lies, because it forces us to go beyond code.

It asks us to share ownership, dissolve silos, and admit that the hardest part of this transition isn’t technical at all, it’s human.