Subscribe now

This one’s a bit different. If you’ve followed my writing, you’ve probably noticed the long silence — and I owe you an honest explanation: I was busy. Not the performative kind of busy, the kind where you look up and realize years have passed. This isn’t a technical post or a framework or a how-to. Think of it as an interlude. An intermission between chapters. Something I needed to write before I could figure out what comes next.

I spent nearly five years at StrongDM. Long enough to see it grow from an early-stage company into something real. Long enough to build a team, ship meaningful products, and feel the weight of what it takes to scale.

I joined because it was one of those rare opportunities where the problem mattered, the ambition was clear, and the early signals on the team were strong. In hindsight, that last part mattered more than anything else.

Last month StrongDM was acquired.

When the acquisition became real internally, my reaction wasn’t what most people expect. It wasn’t some overwhelming sense of victory or finality. It was quieter than that. A mix of immense pride in what we built, gratitude for the people, and a sharp awareness of just how much I’d poured into the work — the hiring calls, the hard sprints, the culture we’d shaped together over years.

Over time, what stayed with me wasn’t the milestone itself. It was how we got there. Five years is long enough to learn a few things the hard way, and when I distill it down, three lessons keep surfacing.

The first is deceptively simple: talent density is everything. Not in the abstract, but in the day-to-day reality of how a team operates. High talent density compresses time. Decisions happen faster. The quality bar stays high without constant enforcement. You don’t need layers of process because the people themselves are the system.

Once you’ve experienced that kind of density, it permanently changes your expectations. You develop very little tolerance for environments where it isn’t present — not out of arrogance, but because you’ve seen what’s possible when it is.

The second is about focus, especially during turbulent periods — which, in startups, is most of the time. There were moments of uncertainty, shifting priorities, external pressures, and the usual chaos that comes with building something from nothing. It’s easy in those moments to get pulled into things you don’t control: market narratives, funding dynamics, organizational noise.

The only thing that consistently worked was narrowing the aperture. Focus on what you can control. For me, that was building a great product and building a great team. Everything else — timelines, outcomes, acquisitions — sits downstream of that.

The third is about perseverance and grit — the kind that doesn’t get talked about in retrospectives because it’s not glamorous. Startups will test you in ways that are hard to explain until you’ve lived through them. Missed quarters. Missed deadlines. Key people leaving at the worst possible moment. Macroeconomic conditions shifting overnight and rewriting the rules you’d been playing by. There were stretches at StrongDM where the emotional weight of it was genuinely heavy — where showing up and holding the line for your team required something closer to stubbornness than strategy.

That takes a toll. It’s cumulative, and it’s personal. You absorb more than you realize at the time — the pressure of a quarter that didn’t land, the gut punch of losing someone you fought hard to hire, the slow grind of leading through uncertainty when you don’t have all the answers yourself. Grit isn’t a personality trait you either have or you don’t. It’s a practice. It’s choosing to keep going when the rational case for optimism is thin, because you believe in what you’re building and in the people building it alongside you. I even had to send myself motivational emails to push through some of these hard times :)

As I think about what comes next, these are the things I’m carrying forward. Not the mechanics of the acquisition, but the conviction that small, high-density teams can outperform much larger ones. That focus beats noise, especially when things get messy. And that building the right environment matters more than almost anything else.

Before any of that, though, I’m taking a break. A real one. Five years of building at startup intensity takes a toll that’s easy to rationalize in the moment and impossible to ignore once you stop. The truth is, sustained high performance requires recovery — and I got better at preaching that to my teams than practicing it myself. So for now, I’m stepping back, recharging, and giving myself the space to figure out what the next chapter looks like without rushing into it.

I’m deeply grateful to the team at StrongDM — for the craftsmanship, the intensity, and the way we pushed each other to be better. With a team like that, a lot more is possible than people think.

For now, onto diving the Forgotten Islands of the Banda Sea. See you in May!

Subscribe now

Most engineering organizations today are racing to adopt AI, but almost all of them are optimizing for the wrong future. They are adding copilots to existing workflows, measuring productivity in pull requests closed, and celebrating incremental gains in developer speed. All of this assumes that the core shape of software development will remain intact—that humans will continue to write code, review code, and act as the central bottleneck between intent and implementation. That assumption is quietly becoming false.

I wrote about this last August. I was directionally correct, but I got the time horizon completely wrong. The curtain won’t fall in five years, the curtain might fall by the end of this year.

4% of GitHub public commits are being authored by Claude Code right now. At the current trajectory, we believe that Claude Code will be 20%+ of all daily commits by the end of 2026. While you blinked, AI consumed all of software development. Source: SemiAnalysis

A more honest way to reason about what’s coming is to start at the limit. Assume a world where all production software is written by agents. Not assisted by AI. Not pair-programmed with AI. Written by it. This is not a prediction about timelines or a claim about general intelligence. It is a design constraint. If code generation becomes cheap, continuous, and autonomous, the human act of writing and reviewing code stops scaling long before it stops feeling familiar.

This, also, was something I predicted would happen, but admiteddly I didn’t envision that it would that soon.

The programmer’s craft will follow the same arc as animation. In place of writing every line, much of the work will involve guiding and integrating what machines produce: defining the architecture, reviewing generated components, making judgment calls on trade-offs and user experience, and ensuring the final system works as intended. Code generation, testing, optimization, and deployment will be handled largely by automated systems. The value shifts from typing instructions into a machine to shaping, supervising, and combining the work of many machine contributors into a coherent, functioning whole.

Once you accept that asymptote, many of today’s “best practices” collapse immediately. Human code review becomes a bottleneck that cannot keep up with machine-generated change. Readability becomes a proxy for trust rather than a guarantee of correctness. The software development lifecycle—built around human scarcity and fallibility—starts to look less like a process and more like a historical artifact. The uncomfortable conclusion is not that engineers are obsolete, but that much of what we currently call engineering exists only because humans used to be the ones writing the code.

If your system needs humans to read code to trust it, it won’t survive a world where AI writes all software.

At StrongDM, we decided to take this limit seriously rather than treat it as a distant abstraction. Instead of asking how AI could make our engineers faster, we asked a harder question: what would break if humans were removed entirely from the act of writing and reviewing code?

That question led us to form a small, dedicated team operating under deliberately extreme constraints. The rules were simple and non-negotiable: no code written by humans, and no code reviewed by humans. Agents were not assistants. They were the builders. We called the combined team of humans and agents the Software Factory

These constraints were not chosen because they were safe or efficient. They were chosen because they surfaced reality quickly. The moment humans stop filling in gaps—intuiting intent that was never written down, fixing edge cases in reviews, compensating for brittle tests—the weaknesses of tooling, process, and assumptions become impossible to ignore. Specifications that once seemed adequate weren’t. Tests that validated implementation rather than intent failed outright. Workflows built around pull requests, ownership, and manual approvals collapsed under the weight of autonomous change. What initially felt reckless turned out to be clarifying. The discomfort was not a signal to stop; it was evidence that we were finally seeing the system as it actually was.

From those experiments emerged a set of first principles that now anchor how we think about the future of software development. The first is that code is disposable. When generation is cheap and continuous, long-lived codebases are not assets to be preserved but byproducts to be replaced. This has profound implications too. If code is not an asset and code can be readily and easily created, what then is the moat in software?

The second is that human readability is not a scalable safety mechanism. Trust in autonomous systems cannot come from inspection; it must come from validation—scenarios, simulations, invariants, and continuous observation of outcomes.

The third is that programming is no longer the act of writing instructions, but the act of shaping constraints. Humans define intent, boundaries, and failure modes; agents explore the implementation space within them.

Taken together, these principles force a reframing of what it means to do engineering. If no human can or should read most of the code, the traditional software development lifecycle stops making sense. Design, implementation, review, and testing collapse into a continuous control loop: generate, validate, observe, adapt. Quality is no longer something you approve at a moment in time; it is something the system proves continuously. This is not a speculative future. It is the logical conclusion of tools that already exist.

The question, then, is what a present-day engineering organization should do if it believes this future is real. Below are some of the lessons we learned as we embarked on this journey at StrongDM.

The first step is to create a small, explicitly AI-first team that operates under these principles. This team should not be measured by features shipped or velocity improved. Its purpose is to discover where reality breaks: where specifications are too vague, where validation is insufficient, where tooling assumes a human will intervene. This team will invest heavily in areas most organizations underinvest in—scenario frameworks, agent workflows, memory and feedback systems, observability, and outcome-based validation. Their role is to let the future collide with the present in a controlled way. This is the team that built our Software Factory, which is a combination of best practices, tooling, teachings and new processes.

The second step is to let those learnings spread without coercion. Practices should cross-pollinate into the broader engineering organization organically, not through mandates. Some teams will adopt them quickly; others will move more slowly. That is fine. What matters is that leadership is explicit about direction. This is not a side experiment or a temporary optimization. It is where the organization is heading. Engineers should be free to move at their own pace, but no one should be confused about which way the river flows.

The third step is to build real software this way—software that matters to the business. Not internal tools, not prototypes, and not experiments that can be quietly abandoned. Choose a system with real users, real constraints, and real consequences, and build it using these factory principles. No human-written code. No human code review. Agents own implementation end to end; humans own intent, validation, and outcomes.

This is not a risk-free move, and pretending otherwise would be dishonest. But the real risk is not that agents will fail. The real risk is continuing to insulate organizations from reality by only trusting AI where failure is inconsequential.

Organizational change does not happen because people are persuaded by arguments about the future. It happens when existing assumptions stop working. When real systems are built this way, the conversation stops being philosophical. Engineers stop debating whether agents can do the work and start confronting what it takes to let them do it well. Practices spread not because leadership mandates them, but because nothing else scales.

You don’t have to move all at once. You don’t have to move blindly. But you do have to move deliberately. The world where humans write most production code is already receding, whether organizations acknowledge it or not. The only remaining choice is whether you encounter that reality gradually, on your own terms—or all at once, when the gap between how you build software and how the world builds software becomes impossible to ignore.

It is a disruptive moment, but also a rare one: a chance to learn faster, rethink fundamentals, and combine AI with human judgment and curiosity to build systems we simply couldn’t before. What a time to be alive!

Related readings

• Claude Code is the Inflection Point from

• Building a C compiler with a team of parallel Claudes

• How StrongDM’s AI team build serious software without even looking at the code

Subscribe now

Not long ago, the enterprise software stack felt settled—like a set of tectonic plates that had stopped moving. You picked your CRM, your ticketing system, your BI dashboards, your data warehouse, your ERP. You paid your subscriptions, hired specialists to operate the tools, and accepted that progress in business software came in the form of quarterly releases and incremental UX improvements.

Then vibe coding happened.

The term sounds flippant, but the implication is serious: software creation is being compressed into language. Andrej Karpathy popularized “vibe coding” to describe a mode where you stop writing code in the traditional sense and instead steer an AI system with intent—describing what you want, iterating in natural language, and letting the model generate the implementation.

What makes this disruptive isn’t that engineers get faster. It’s that the cost of making software is collapsing.

The old moat is eroding

For decades, the most powerful moat SaaS had wasn’t a feature set or a UI. It was the reality that building software—especially enterprise software—was expensive. It required teams, timelines, coordination, and maintenance. Even when SaaS felt overpriced, it was still cheaper than reinventing it yourself.

Vibe coding changes that assumption. It drives the fixed cost of producing software down so aggressively that the build-vs-buy calculation begins to tip. When a team can describe an internal workflow in natural language and generate a working app in days, the software itself starts to feel less like a product and more like a commodity.

The SaaS model rested on this asymmetry: companies absorbed high fixed costs to design and maintain software, then scaled to millions of users at high margins. AI destabilizes this model. By automating coding, debugging, and maintenance, it drives the fixed cost of creation toward zero. With both creation and distribution essentially free, the foundations of the industry shift.

And once software becomes cheap to create, the expensive part of enterprise operations becomes harder to ignore: the human labor embedded inside workflows.

SaaS is a workflow product

There’s a simple way to describe most SaaS categories: they don’t do the work, they organize it. Support platforms don’t resolve issues—they route them. BI tools don’t produce insight—they help humans translate questions into queries. SOC tooling doesn’t remediate incidents—it creates queues of alerts for analysts to triage.

This distinction matters because the economic value of many SaaS products has always been tightly coupled to human effort. The workflow may be digitized, but it is still human-operated.

Agentic AI changes the structure of this bargain. It turns the workflow itself into something executable:

• The agent reads the ticket, opens the Jira, pulls the logs, drafts the customer response, and writes the postmortem.

• The agent correlates alerts, enriches with threat intel, contains the endpoint, and files the incident report.

• The agent qualifies the lead, sequences outreach, follows up, and books the meeting.

That’s not a UI improvement. It’s labor substitution.

Most “AI replaces SaaS” takes focus on interfaces: chat replaces dashboards, copilots replace forms, natural language replaces clicks. Those shifts are ergonomic, but the deeper disruption is economic. SaaS products have two major cost components: the upfront cost to build the software, and the ongoing cost of operating workflows through it—including, critically, human effort.

The thesis in one line:

Vibe coding collapses the build cost. Agents collapse the workflow tax.

The counterargument: why SaaS may prove stickier than expected

The disruption case is compelling in theory. In practice, several forces work against it.

Switching costs are brutal

Enterprise software doesn’t exist in isolation. It’s woven into identity systems, data pipelines, compliance frameworks, and years of accumulated configuration. Salesforce isn’t just a CRM—it’s a system of record that dozens of other tools depend on. Ripping it out to replace it with an AI-native alternative isn’t a product decision; it’s a multi-quarter migration project with real risk of data loss, broken integrations, and user revolt.

Even if an AI-built alternative is functionally equivalent, the cost of switching often exceeds the cost of staying.

Enterprises pay for accountability, not just functionality

When a SaaS product breaks, there’s a vendor to call, an SLA to invoke, and a contract that assigns liability. When an AI-generated internal tool breaks, the team that built it owns the problem—and they may have moved on, lost context, or never fully understood what the AI produced.

Regulated industries make this even starker. Banks, healthcare systems, and government agencies don’t just need software that works—they need software they can audit, explain to regulators, and defend in court. “The AI wrote it” is not yet an acceptable answer in most compliance frameworks. Incumbents have an advantage here; they are already in the enterprise.

Organizational inertia is a feature, not a bug

Large organizations are slow to change not because they’re stupid, but because they’ve learned that rapid change is risky. The people who operate existing SaaS tools have built expertise, careers, and political capital around them. Replacing Tableau with an AI-native BI tool doesn’t just require better technology—it requires retraining analysts, rebuilding dashboards, convincing executives that the new approach is trustworthy, and managing the inevitable disruption to reporting workflows.

Many enterprises will rationally choose “good enough and familiar” over “potentially better but unproven.”

Data gravity is real

Your data lives in your existing systems. Moving it is painful, risky, and often incomplete. Even if an AI-native tool is superior, it starts cold—without the years of historical data, learned patterns, and institutional knowledge embedded in your current stack. That’s one of the reasons Salesforce is starting to lock down access to its data, notably Slack.

What won’t be disrupted

This framework clarifies why some categories are resistant: not because they’re loved, but because they’re hard to replicate economically.

Foundational infrastructure—database engines, distributed compute, message queues, storage platforms—is engineered for reliability, performance, and fault tolerance. These systems are already highly optimized ways to minimize compute cost per unit of work.

Consider this thought experiment: an AI data warehouse. You stream records into an LLM-backed store and query it conversationally. It sounds elegant, until you try to run a real workload. Query performance, concurrency, determinism, caching, and predictable cost behavior are not UX details—they are the product. Snowflake, Databricks, and data vendors will do just fine in this world.

An LLM can’t reason its way into being a better warehouse engine. And if the AI system “solves” this by calling DuckDB, Snowflake, or Postgres, it is relying on the very thing it is trying to replace.

Where disruption pressure is highest

Above infrastructure, the calculus flips.

The higher you go, the more enterprise software becomes about translating messy human intent into structured steps. That translation layer is expensive in one way: human time.

Business Intelligence (BI) tools like Tableau, Looker and so on sit above warehouses and translate data into charts and dashboards. But the hidden cost of BI isn’t compute—it’s the labor required to translate business questions into SQL, curate dashboards, maintain reporting logic, and interpret results.

LLMs can collapse the translation layer. They can query databases with natural language input and generate charts and narratives directly. Even if compute costs rise, the human cost drops sharply, and that’s what drives displacement pressure. I’ve lived this at StrongDM and opted to invest in an AI native tool - Arka - vs traditional BI. See here for a case study

Support is one of the clearest examples of SaaS as workflow.

A typical support flow involves reading tickets, searching knowledge bases, pulling customer context, checking logs, coordinating with engineering, escalating, and following up. These are labor-heavy steps coordinated by software, not executed by it.

AI agents can execute large portions of this workflow directly, which is why support SaaS is highly disruptible under the cost framework.

If the cost framework is right, disruption won’t hit SaaS evenly. It will hit where:

• workflows are repetitive and text-heavy

• outputs are verifiable

• compute requirements are manageable

• and human effort dominates the cost

Below is a practical view of enterprise SaaS verticals that are most exposed.

The realistic outlook

The real takeaway is that the disruption window is open—but it’s not wide, and it’s not moving at internet speed.

Agent adoption is still early. According to recent research, only about 5% of enterprise respondents are deploying AI agents in production at scale. A full 71% are either in pilots or in production at small scale, and 22% aren’t deploying agents even in pilots. This makes the “agents displace humans” bear case premature in the near term.

AI Agent Adoption is Very Early: Beyond employee productivity (M365 Copilot), coding (GitHub Copilot) and creative (Google Veo) use cases, the deployment of autonomous AI agents has attracted the most attention and has become a focus area for OpenAI and Anthropic as they look to better penetrate the enterprise. The investor consensus, which we share, is that adoption remains very early-stage. Only 5% of enterprise respondents are deploying AI agents “in production at scale”, with a full 71% either in pilots or in production at a small scale. A full 22% aren’t even deploying AI agents even in pilots. While deployment is too early-stage to support the “AI agents displacing humans” bear case, the risk is that enterprise adoption remains slow against a backdrop of many AI technology suppliers – Nvidia, OpenAI, Anthropic and the apps firms such as Salesforce and ServiceNow – describing a world in which agents drive material revs and/or GPU consumption. Source: UBS AI Research

But early does not mean irrelevant. Vibe coding is collapsing the upfront cost of building software, and agents are steadily compressing the day-to-day workflow tax that many SaaS products monetize.

The most plausible outcome isn’t a sudden SaaS extinction event, but a slower repricing of outcomes. Challengers can win by targeting high-toil workflows with agent-native products. Incumbents can win too—if they’re willing to embrace the innovator’s dilemma and cannibalize their own products with agentic equivalents before someone else does.

The enterprises that benefit most will be those that recognize which of their SaaS tools are genuinely load-bearing infrastructure and which are expensive ways to coordinate human labor that could be automated. The former are worth keeping. The latter are worth questioning—even if the replacement isn’t ready today.

The disruption won’t be uniform, it won’t be instant, and it won’t be inevitable. But for the first time in a decade, the tectonic plates are moving again.

Related articles:

• Clouded Judgement 1.30.26 - Software is Dead...Again!

• UBS Evidence Lab, AI Research; Enterprise AI Adoption is Slow but Ramping

• The Ambient AI Era: Clawdbot (OpenClaw)’s Ripple Effects

• Battery Ventures - State of AI 2025

• Menlo Ventures - State of Generative AI in the Enterprise

Subscribe now

AI is no longer just answering questions. It’s taking actions.

At Google I/O 2025, Sundar Pich`ai offered a definition that quietly reset the stakes:

Agents are systems that combine the intelligence of advanced AI models with access to tools, so they can take actions on your behalf, under your control.1

That framing matters, because it marks a shift from AI as software that responds to instructions to AI as software that pursues goals. And that shift is already underway.

Across enterprises, AI systems are moving beyond chat interfaces and single-shot automations toward agentic architectures that can plan, execute, observe outcomes, and adapt their behavior. These agents write code, query databases, operate browsers, interact with CRMs, deploy infrastructure, and orchestrate workflows across systems that were never designed for autonomous decision-makers.

Security, meanwhile, is still catching up to the idea that software can decide what to do next.

Despite the hype, true agentic AI is still early. Industry data shows that only about 16 percent of enterprise deployments and 27 percent of startup deployments qualify as genuine agents2—systems where an LLM plans and executes actions, observes feedback, and adapts over time. Most deployments today are still fixed workflows wrapped around a model call.

But the adoption curve is steepening fast. By the end of 2025, roughly a third of enterprises had agentic systems running in production, with nearly half planning to deploy within the following year. Almost nine out of ten organizations experimenting with agents reported positive early ROI. At the same time, reasoning-token consumption exploded by more than 300x year over year, a signal that systems are no longer just generating text but reasoning through multi-step tasks at scale3.

Agents rarely arrive as labeled products. They appear as internal tools. CI jobs. Background services. Automation scripts with tool access and an LLM API key attached. To a security team, they look indistinguishable from ordinary services—until they start behaving very differently.

Every major platform shift creates a new kind of shadow IT. SaaS created unsanctioned apps. Cloud created unknown infrastructure. Agentic AI creates something more subtle: autonomous actors embedded inside trusted systems, often without anyone explicitly acknowledging that they’ve crossed from automation into autonomy.

Which leads to the first security failure mode.

Discovery comes before security

You cannot secure agents you don’t know exist.

Discovery in the agentic era isn’t about inspecting code for the word “agent.” It’s about recognizing behavioral signals of autonomy. Long-lived processes that repeatedly call LLMs. Services that dynamically choose tools based on model output. Workloads that chain actions across systems without human prompts at every step.

Traditional asset inventories don’t capture this. IAM systems don’t flag it. SIEMs record events without understanding intent. As a result, many organizations cannot answer a simple question: how many autonomous systems are currently acting inside our environment, and where do they have reach? The closest proxy they use today to try and answer this question is to discover NHIs.

This isn’t a hypothetical risk. It’s the same pattern security teams saw with early cloud adoption, only now the workloads don’t just run—they decide.

Discovery is the prerequisite for everything that follows. Until agents are identified as agents, governance is impossible. And once they are discovered, a second problem becomes unavoidable.

What exactly are they doing?

Observability, rewritten for agents

Traditional observability tells you what happened. Agentic systems demand that you understand why it happened.

Agents operate through non-deterministic reasoning loops. They perceive context, reason about goals, act through tools, and learn from outcomes. Logging an input prompt and an output response captures almost none of that. It doesn’t tell you what the agent considered, what options it rejected, or how it decided that one action was preferable to another.

In security terms, this creates an observability gap. When an agent behaves unexpectedly—querying the wrong data, modifying the wrong system, or triggering a cascading failure—there is often no intelligible explanation available to humans.

This is why agent observability has become its own discipline.

The industry has begun standardizing around richer telemetry models, particularly through OpenTelemetry’s GenAI semantic conventions. These conventions don’t just log requests and responses. They capture tasks and subtasks, tool invocations, intermediate artifacts like generated code or retrieved documents, and the persistent memory that allows agents to carry context across steps.

The result is something closer to a reasoning trace than a log file. You can see the goal the agent was pursuing, the sequence of actions it planned, what it actually executed, and how each decision flowed into the next.

This level of visibility isn’t just useful for debugging. It’s foundational for security. It enables audit. It enables anomaly detection. It enables the most basic form of trust: the ability to reconstruct what happened after the fact.

But visibility alone doesn’t prevent damage. It just helps you understand it.

To prevent harm, agents need to be governed at the points where their reasoning turns into action.

Control starts with identity

The first place control breaks down is identity.

Most agents today operate by impersonation. They inherit a user’s OAuth token. They reuse a service account. They act as “someone else” because existing identity systems don’t offer a better model.

This approach collapses accountability.

When an agent deletes a record, queries sensitive data, or triggers a workflow, security logs show a human user did it. There is no way to distinguish between an intentional human action and an autonomous decision.

Legacy identity protocols weren’t designed for this world. OAuth, SAML, and OIDC assume a human is present, authorizing a specific interaction. Agents don’t behave that way. They delegate to sub-agents. They operate at machine speed. They spin up and down by the thousands. Sometimes they interact with front-end interfaces rather than APIs, leaving no place to pass “on-behalf-of” context at all.

The solution the industry is converging on is authenticated delegation.

In this model, agents receive their own first-class, non-human identities. Those identities are independent of any single user, but every action the agent takes is explicitly attributed to a human or organizational principal through delegated, time-bound authority. The agent authenticates as itself. Delegated authority is conveyed through short-lived, scoped tokens. Audit logs show not just what happened, but who the agent was, who it was acting for, and under what constraints.

This restores accountability. It also enables revocation. If an agent deviates from expected behavior, access can be cut without disabling a human user or breaking unrelated workflows.

Identity is where control begins, but it doesn’t end there.

Continuous authorization: Governing action without killing autonomy

The instinctive reaction to autonomous systems is to lock them down. But agents derive their value from flexibility. Strip that away, and you’re left with brittle automation dressed up as intelligence.

The real challenge isn’t whether to authorize an agent. It’s how often.

Traditional security models assume authorization is a one-time event. A user logs in. A token is issued. Access is granted. From that moment on, actions are implicitly trusted until the session expires. That model collapses in the presence of agents.

Agents don’t perform a single action and stop. They reason continuously. They branch. They delegate. They observe outcomes and adjust their plans. Each step may touch a different system, invoke a different tool, or operate under different risk conditions than the step before it.

In an agentic world, authorization can’t be static. It must be continuous.

Continuous authorization treats every meaningful action as a decision point. Instead of asking “is this agent allowed to run,” the system asks, repeatedly, “is this action allowed now, given what we know?”

That context includes who the agent is, who (or what) delegated authority to it, what goal it is pursuing, what it has already done, and what it is attempting to do next. An agent may be permitted to read data but not modify it. It may be allowed to act for a short window but not indefinitely. It may be authorized to access one system but denied access to another as its behavior evolves. It might be allowed to perform an action if it is acting on a particular user, but not another.

When agents operate locally, continuous authorization governs what they can execute, what files they can touch, and what network destinations they can reach. Sandboxed environments, minimal file systems, and explicit allowlists ensure that even if an agent’s reasoning goes off course, its ability to cause harm is constrained.

When agents interact with other systems, continuous authorization becomes an egress problem. Calls to databases, CRMs, internal services, or MCP servers are not blindly trusted. Each interaction is evaluated against current policy, agent identity, delegated scope, and observed behavior. If context changes, authorization can change with it.

This is where identity, visibility, and control converge.

An agent authenticates as itself. Its actions are observed in context, which includes who it is acting on. Authorization is enforced dynamically, not assumed. Permissions can narrow, expand, or be revoked as conditions warrant—without disabling the agent entirely or breaking unrelated workflows.

The result is autonomy with guardrails. Agents retain the ability to plan and act, but they do so inside a system that never stops asking whether the next action still makes sense.

That shift—from static permission to continuous authorization—is what makes agentic AI deployable in environments where trust, auditability, and control still matter.

For a fun little tool that helps you observe what agents are doing both locally and otherwise, take a look at Leash from StrongDM. Leash is both an observability tool - for a single agent - and allows to allow/deny actions both locally and remotely.

Software no longer just executes instructions. It forms plans, makes decisions, and acts over time. That breaks security models built on static permissions, human identities, and predictable execution paths.

The constraint on agentic AI is not intelligence. It’s control.

Enterprises that cannot continuously discover agents running in their environments, cannot observe what those agents are doing, and cannot continuously authorize their actions will eventually shut them down—or never deploy them in the first place.

The next era of software will be autonomous.
The next era of security must make autonomy governable.

Anything less turns agency into risk.

Subscribe now

About a year and a half ago, the AI coding landscape was a very different place.

At the time, GitHub Copilot was the category. There weren’t multiple competing models, no real choice of interaction styles, and certainly no sense that AI was a general-purpose programming companion. Copilot lived inside the editor, completed a few lines ahead of you, and mostly tried to guess where your keystrokes were headed. Claude didn’t exist in any practical sense. Codex wasn’t something teams used directly. Chat-based workflows were clumsy, slow, and easy to dismiss as novelty.

So when I pulsed my engineering team about 1.5 years ago about adoption and value of AI coding assistants, I was really asking whether Copilot was effective. The answer then was unsatisfying but honest: sometimes helpful, often marginal, rarely transformative. Adoption was uneven. Productivity gains were hard to isolate. Code quality improvements were unclear. For many engineers, Copilot was fine for boilerplate, occasionally useful for tests, and largely irrelevant for harder problems. The conclusion wasn’t that AI didn’t work—it was that it hadn’t yet earned a central place in the workflow.

Back then we abandoned GitHub Copilot and other similar tools. Fast forward to today, and that framing no longer holds.

When I recently ran a new survey across the engineering organization, the results reflected that shift immediately. People aren’t debating whether to use AI anymore. They’re deciding which AI to use, when, and for what. That’s a drastic change from the Copilot survey which revealed that most of the engineers weren’t using it.

The most important change isn’t that one tool got better. It’s that the entire tool landscape shifted. AI is no longer a single autocomplete engine living in your editor. It’s a constellation of tools with different strengths, latencies, and interaction models. Engineers move fluidly between chat-based systems, in-IDE assistants, reasoning-heavy models, and increasingly, internal tools designed to apply AI to very specific domains.

Unsurprisingly the most popular tool, which has been true since the release of Sonnet 3.6 in late 2024, is Claude Code. The tools are used daily, often continuously, and across a wide range of activities—from implementation to refactoring to debugging to documentation. Additionally, tool usage is not limited to one. Oftentimes engineers use more than 1 tool, mixing and matching between Claude, Codex, ChatGPT and Gemini.

What stood out right away was how clearly engineers felt the speed difference. Compared to the Copilot-era experiment, the perception of increased velocity is no longer ambiguous. Most people feel that these tools help them complete tasks faster, sometimes marginally, sometimes dramatically. From a throughput perspective, AI is now doing real work. The question “does this help me move faster?” has, for most engineers, been answered.

But if the productivity story has sharpened, the quality story has not fundamentally changed.

Despite stronger models and better tooling, AI-generated code is still rarely perceived as superior to human-written code. At best, it’s comparable. Often, it’s worse. Very little of it is considered truly ready to ship without human intervention. Engineers expect to polish it, restructure it, or in some cases discard it entirely. That instinct mirrors what we saw in the Copilot study: AI can accelerate getting something on the screen, but it does not relieve us of judgment, taste, or responsibility.

That skepticism shows up even more clearly in how people review AI-generated code. Trust remains low. Most engineers approach AI output with heightened scrutiny, reviewing suggestions line by line rather than assuming correctness. The model may get the logic roughly right, but factoring, clarity, and long-term maintainability still require human care. In other words, while AI has become faster and more capable, it has not been granted a lower bar. Nor should it be.

This is where the real tension emerges. AI shifts work earlier in the pipeline. It compresses the time it takes to produce code, but it doesn’t eliminate the need to understand it. In some cases, it increases the surface area of change, making reviews heavier and more cognitively demanding. Without discipline, speed simply pushes cost downstream—into review, refactoring, and long-term maintenance.

Flow, too, has re-entered the conversation in an unexpected way. The older Copilot model felt instantaneous but shallow. Today’s tools are deeper, but not always invisible. Latency matters. Waiting on responses, switching contexts, or iterating through prompts can interrupt concentration in ways that feel familiar to anyone who remembers long compile times. AI can accelerate progress, but it can also fracture attention if used carelessly.

What I found most encouraging in the new survey wasn’t that AI “won,” or that the tools suddenly became magical. It was the maturity of the posture. Engineers understand the trade-offs. They use AI where it helps and disengage when it doesn’t. They move faster, but they don’t pretend that faster automatically means better. The codebase remains a human responsibility. “The AI wrote it” isn’t an explanation—it’s just an implementation detail.

The headline from the Copilot survey was engineers abandoning AI coding assistants.

Today’s headline is markedly different: Engineers are using these tools, perceive productivity gains and generally enjoy using them.

Looking back, the Copilot experiment wasn’t wrong. It was early and the tool was premature. What’s changed since then isn’t the fundamental nature of software engineering. It’s the availability of leverage. AI now meaningfully accelerates parts of the job—but it doesn’t absolve us of ownership. Used deliberately, it makes good engineers more effective. Used carelessly, it amplifies debt.

Subscribe now

Prologue

It might not come as a surprise that I use GenAI to both help me research and edit my content. My usage of GenAI products, at least in relation my posts has been editorial and research versus strict content creation. This article is different. It has been ideated and written entirely by GenAI. My motivation in using various GenAI models to create this article wasn’t because they can write better than me, which they absolutely do. It was my attempt to use them to project a future world, one in which I am trying to comprehend and predict.

I gave the following prompt to Gemini, ChatGPT and Claude

You are a futurist technologist. You think about innovation waves, like AI, and how they might shape and change society. You are now thinking about how AI might impact software organizations of the future. I want you to start by benchmarking today’s software organizations: companies who build software products. How are they staffed and organized. I then want you to project how AI might change that. Be bold, but pragmatic and whenever possible tethered into reality. Try and get examples from current AI-native companies and project forwards into the future.

Each model generated its own content, which I then edited in various modes. First, I challenged some of the assumptions, asking questions, challenging their argument, pushing them to be bolder, yet realistic (although to be honest, is anything unrealistic with the advent of AI now?). I also asked each model to review and edit the content created by the other models. I went back and forth for a few days between probing each model, tossing one model’s content to another to critique it, until I - or more appropriately we - settled on the below

The year is 2035. Eliza stands in what used to be called The Stack—fifty engineers, bright monitors, the low thrum of a hundred keyboards clattering out React components. It had taken them six months to ship version one.

Today, the room has a new name: The Engine Room. And it’s silent.

Eliza isn’t an engineer anymore. She’s a Chief Intent Officer. And there are only two other people in the room.

But to understand where we’re going, you need to see what’s dying right now.

The age of the human bottleneck

“It feels like a superpower,” says an engineer at a seven-person startup in 2024. He doesn’t know it yet, but he’s witnessing the beginning of the end—not of software development, but of software developers as we’ve known them for forty years.

A traditional 2020 software company was predictable: 50 people, Series A funded. CEO, CTO, five engineers, three product managers, two designers, four marketing people, three salespeople, two customer success reps. The math was fixed: one revenue-generating employee for every $200K in ARR. A typical startup burned $1 million to reach $1 million in revenue.

The process was equally predictable. The Product Manager would spend weeks writing user stories. The UX Designer would spend another week mapping pixels. Then came ten engineers—what Eliza would later call “the Scribes of the System”—painstakingly translating English and Figma into thousands of lines of code.

“We were glorified typists,” Eliza would later say. “We were paid to translate the same five design patterns over and over.”

Then came the Cycle of Hand-Offs: two days for code review, a week for QA testing, a day for DevOps deployment. It was a beautiful, bloated bureaucracy built entirely around managing human error and communication lag.

It took six weeks to ship a button.

Until 2024, when the law broke.

AI-native startups today generate $3.48 million in revenue per employee—six times higher than traditional SaaS companies. The numbers are almost obscene:

• Gamma: tens of millions in ARR from 50 million users with 28 employees. “If we were part of the previous generation, we would easily have around 200 employees,” says co-founder Grant Lee.

• Cursor: $100M ARR in 21 months with 20 people.

• Bolt: $20M ARR in two months with 15 people.

And here’s the part that breaks everyone’s brain: they’re intentionally capping their size. Runway Financial will stop hiring at 100 employees. Agency plans the same. The growth-at-all-costs mentality—the defining characteristic of startup culture for thirty years—is being abandoned.

Not because they’re failing. Because they’re winning so efficiently they don’t need more people.

Eliza remembered the moment she knew the old world was doomed. It was 2026, and she was testing Project Chimera—the first system built entirely by an Autonomous Agent Pipeline.

She spent an afternoon writing a five-page specification: Increase widget customization rates by 25% by allowing users to upload custom textures. Must maintain latency under 100ms, cost less than $100 monthly.

She hit GO.

The system generated an Architectural Proposal—fully documented backend services, frontend components, optimized database schema, plus a Risk Assessment that flagged three security vulnerabilities before the code was written.

She handed it to Damon, the sole Agentic Architect. He didn’t write a single line of application code. He spent his day tuning agent parameters—adjusting the Code Generation Agent’s language bias toward Rust, tightening the Testing Agent’s input validation focus. Within 72 hours, Chimera was in production. Fully tested, fully documented, self-healing.

The old guard engineers watched in horror. By 2027, it wasn’t a fluke. It was the new standard.

By 2030, a new software company starts with what Eliza calls the Nuclear Core:

Eliza: The Intent Officer (formerly “CEO/Product”): Doesn’t manage features; manages simulated futures. Focuses solely on defining high-leverage problems AI should solve next. Writes strategic intents: “Increase conversion by 15% while reducing support tickets by 20%.” The AI figures out how.

Damon: The Agentic Architect (formerly “CTO”): Rarely looks at generated code but obsessively monitors Agent Telemetry—the metrics of the system that builds the system. Doesn’t write code; conducts an AI symphony. One developer called it “God mode”—able to conjure code at will. The Architect lives there permanently.

Maria: The Quality Sentinel (formerly “Head of Engineering/QA”): Final human oversight. Ensures output is secure, compliant, adheres to ethical guardrails. Doesn’t test code—tests the systems that test code.

The Supporting Cast is all AI: coding agents, customer support agents, auto-generated documentation, 24/7 QA testing, self-healing DevOps, marketing content generation, financial modeling.

By 2035, when Eliza stands in the silent Engine Room, this isn’t revolutionary. It’s just how software works.

Gone is the old way: PM writes epic (2 weeks). Designer creates mockups (1 week). Ten engineers translate to code (3 weeks). QA tests (1 week). DevOps deploys (1 week). Total: 8 weeks minimum.

Brainstorm in the morning, prototype by midday, polished product by night. This is the new normal.

The silence is perfect execution

Walk into a software company in 2035 and the first thing you notice is the silence. Not because nothing’s happening—because so much is happening seamlessly.

Eliza’s display shows Agent Telemetry: thousands of micro-decisions per second, code being generated and tested and deployed, user feedback analyzed and incorporated, A/B tests running in parallel universes of possibility.

The three humans aren’t coding. They’re thinking. They’re defining the next strategic intent. They’re asking questions the machines can’t:

Should we enter healthcare? Is this growth sustainable? What problem are we really solving?

These are human questions requiring judgment that can’t be automated—not yet, maybe not ever.

The office is quiet because the age of human labor in software is over. The age of Human Intent—amplified by the machine—has begun.

Three people. A codebase ten times larger than fifty people managed a decade ago. Output measured not in closed tickets, but in validated strategic outcomes.

On the wall: three simultaneous development cycles—a security patch, a UI/UX experiment, a market expansion. No humans involved in execution. Just the Nuclear Core, defining what should happen.

Then watching it happen.

If you’re building a software company in late 2024, you’re living through the transition. The Age of the Human Bottleneck is ending. The Age of Human Intent is beginning.

You can be Eliza, learning to define strategic outcomes rather than manage features. You can be Damon, learning to conduct the AI symphony rather than play each instrument. You can be Maria, learning to audit systems rather than test code.

Or you can be one of the Scribes, still typing away, convinced this is hype, that humans will always be needed to translate business logic into code.

The Engine Room is being built right now. The silence is coming.

The only question left is: will you be one of the three people in the room?

Or will you be the reason the room is silent?

Epilogue

When I first started to work on this article with the aforementioned models 3 weeks ago, I had no intuition as to what they would generate. Somewhat surprising to me, all three painting a picture that is not to different that Eliza’s world in this article. All three agreed that today’s world of software development will radically change.

The question I ponder is this one: Will the change represented here materialize?

And the answer, at least from my own experience using and observing GenAI being used in software development, is yes. There’s an separate question on how satisfying this mode of work is relative to how software is built today. It’s akin to programming a loom versus hand-weaving a rug. The art of the craft dies and is replaced by (cold) automation.

Todays models can almost certainly build - almost autonomously - a wide class of software applications. These might be simple: a frontend, an API middle-tier and a Postgres database. But that’s usually how disruption starts, from the bottom and moving upstream. Today the simple three-tier web/mobile application is disrupted, tomorrow the enterprise SaaS product.

I suppose we will know when we have approached this moment when Anthropic, OpenAI and the other labs stop hiring software developers altogether.

We have time. All are still hiring :)

Subscribe now

Last week, I wrote that as AI makes it trivial to create apps it will unleash a Cambrian explosion of software, and consequently new aggregation platforms to curate these new apps.

AI will allow anyone with an idea and curiosity to build something that works. But that flood has consequences. Hundreds of near-identical AI-generated tools will appear overnight, many indistinguishable in function or quality. Just as streaming turned the music economy into a power law—where a tiny fraction of artists capture the majority of plays—the software market could polarize between a few aggregators and millions of niche creators barely scraping visibility. The next Spotify or YouTube for software won’t be a tool that helps people make apps—it’ll be the system that helps people find them.

It didn’t take long for the idea to materialize. With OpenAI unveiling apps inside ChatGPT, the Cambrian explosion—and the aggregation platform I’d been thinking about—has begun to take shape.

The announcement transforms ChatGPT from a product into a platform: an intelligent substrate where anyone can build and distribute software through conversation. It unifies the flood—one interface, one ecosystem, one operating system for AI-native software.

The parallels to Apple’s App Store moment are hard to miss. In 2008, the iPhone was a sleek gadget until Apple opened it to developers and gave them a distribution channel. Suddenly, a device became a platform, and a whole generation of new businesses—Uber, Instagram, WhatsApp—emerged from that ecosystem. ChatGPT is stepping into the same role, but at a higher layer of abstraction. Developers can now build apps that live inside the assistant, not on your home screen. You don’t download them; you summon them by name or by intent. “Spotify, make me a playlist.” “Booking.com, find me a hotel in Lisbon.” The app materializes in the chat—interactive, visual, contextual. There’s no install, no tab switching. The interface is the conversation itself.

For developers, the opportunity is enormous. ChatGPT already reaches more people each week than most platforms ever do—hundreds of millions of users—and the new Apps SDK gives them a direct, built-in audience. Apps can even be surfaced contextually as ChatGPT interprets a user’s goal: mention moving cities and it might suggest Zillow; plan a trip and it might bring up Expedia or Booking.com. Distribution becomes AI-driven discovery. OpenAI is introducing a directory, a review process, and a commerce protocol for in-chat payments. It looks and feels like an app store reborn for a world where code is abundant and attention is scarce.

This fits a deeper pattern. Computing platforms tend to evolve in roughly ten-year cycles, each one moving closer to human intent. The PC era revolved around desktop operating systems like Windows. The 2000s shifted power to browsers and search. The 2010s crowned the mobile OS and its app stores as the dominant distribution layer. Now, the AI assistant is emerging as the next platform—the place where computing begins and ends. ChatGPT’s leadership calls it a “chat-driven OS.” That description feels right: a new layer where software runs through dialogue instead of clicks, and where the AI, not the user, handles the orchestration of tools.

The difference this time lies in how we interact and how work gets done. The first shift is in interface. For half a century, we’ve interacted with software through visual metaphors: windows, buttons, icons, menus. ChatGPT replaces that with language. You describe what you want, and it decides which apps or APIs to call. The boundary between your intention and execution dissolves. Software becomes conversational—adaptive, continuous, and human-shaped. It’s as if the command line, the GUI, and the touchscreen all evolved into a single interface: dialogue: written or conversational.

The second shift is orchestration. Until now, users have been the glue between apps. You open Expedia for flights, Booking.com for hotels, OpenTable for restaurants. You copy, paste, compare, confirm. The AI platform reverses that dynamic. It becomes the orchestrator. Tell ChatGPT, “Plan me a weeklong trip to Lisbon and Valencia in June, budget three hundred a night, walkable neighborhoods, one Michelin lunch and a few cozy bistros,” and it will coordinate the entire workflow. Expedia finds flights, Booking.com filters hotels, OpenTable reserves dinners, a rail app handles the train. Each app contributes a piece, and the assistant threads them together into a single itinerary—complete with confirmations, payments, and live updates—all inside the same conversation. The operating system isn’t managing windows anymore; it’s managing your intent.

What’s emerging isn’t just a new way to use software—it’s a new way for software to exist. Each platform shift in computing has compressed the distance between human intention and machine execution. The desktop gave us personal control, the web gave us reach, the smartphone gave us immediacy. The AI platform is giving us agency. We no longer tell machines how to do something—we tell them what we want, and they decide the how. That’s the deeper revolution hiding inside OpenAI’s announcement. It’s not about a new feature or SDK; it’s about a redefinition of computing itself. The interface becomes language, the operating system becomes intelligence, and the app store becomes a living conversation—an infinite canvas where creation and coordination happen in the same breath.

Subscribe now

For decades, the music and entertainment industries were shaped by scarcity. Recording an album or producing a show required capital, studio access, and a distribution network—barriers that kept creative output limited and controlled by a few large players. The internet erased those barriers. Platforms like YouTube, Spotify, and TikTok made creation and distribution nearly free, flooding the world with new artists and independent producers. The result was a structural shift: creation became abundant, attention became scarce, and the balance of power moved from the producers to the platforms that organized their work.

Something similar might happen to software.

AI is driving the cost of making software toward zero. A solo founder can summon an application from a prompt, iterate it in hours, and ship globally without touching a line of code.

“Starting a business may become so cheap and hassle-free that anyone will be able to become an entrepreneur much as anyone can become a YouTuber,” The Economist - August 2025.

Code, in other words, is about to go the way of music: infinite supply, negligible marginal cost, and a flood of new creators. This is software’s Cambrian explosion—a phase of evolutionary overproduction where every niche, every problem, every fleeting idea can spawn its own micro-app.

To see what that might look like, we need to rewind to the internet’s first great abundance experiment. Before YouTube, TikTok, and Spotify, the entertainment industry ran on scarcity. Access to distribution—airwaves, stores, or cable channels—was limited. Record labels and TV networks were the gatekeepers, rationing what reached the public. Then came the platforms.

A musician no longer needed a label; a teenager with a phone could find a global audience overnight. By 2024, nearly 99,000 songs were uploaded to streaming services every day, amounting to 202 million tracks online by year’s end. 12 million artists uploaded music to Spotify in 2024, up from 10 million the year before. The scale dwarfs anything the old industry could have imagined.

But abundance has gravity. Eighty-six percent of Spotify tracks attracted fewer than 1,000 streams, effectively vanishing into the long tail. “Streaming has allowed millions to easily share their music globally,” Spotify noted, “but the sheer volume of uploaders means the fraction who find success appears smaller over time.” The bottleneck shifted: creation was easy, discovery was hard. Algorithms—once invisible curators—became the new tastemakers.

Legacy players didn’t vanish; they mutated. Labels and studios survived by cutting deals with platforms, licensing catalogs, and feeding the algorithm with steady output. But they ceded the high ground. Power moved from those who produced content to those who distributed and curated it. Spotify, YouTube, and TikTok became the new gatekeepers, filtering the flood through recommendation engines and playlists.

I believe that software is about to undergo that same transformation.

As AI makes it trivial to create apps, websites, and agents, the scarcity in software will no longer be code—it will be distribution, data, and trust. When marginal cost approaches zero, markets explode outward. Problems once too small to attract venture dollars—say, a dashboard for mushroom farmers or an AI concierge for wedding planning—suddenly become viable.

AI will allow anyone with an idea and curiosity to build something that works. But that flood has consequences. Hundreds of near-identical AI-generated tools will appear overnight, many indistinguishable in function or quality. Just as streaming turned the music economy into a power law—where a tiny fraction of artists capture the majority of plays—the software market could polarize between a few aggregators and millions of niche creators barely scraping visibility. The next Spotify or YouTube for software won’t be a tool that helps people make apps—it’ll be the system that helps people find them.

In Ben Thompson’s Aggregation Theory, the internet shifted power from producers to the platforms that organize them—a pattern now replaying at planetary scale. The winners of the software Cambrian explosion won’t be the thousands of AI developers churning out clones of each other’s tools, but the ecosystems that aggregate, distribute, and power them. On one level, these aggregators will take the form of app stores, plugin marketplaces, and trust layers—Spotify playlists for code, recommendation systems for tools.

However, underneath that creative surface lies a deeper concentration of power. The abundance of software rests on a foundation of extraordinary consolidation: a handful of companies provide the hardware, compute, and intelligence that make the entire explosion possible. NVIDIA is the pick-and-shovel vendor of this gold rush, minting revenue on every GPU that fuels the boom. Above it sit the GenAI model providers—OpenAI, Anthropic, Mistral—each competing to become the default intelligence layer for millions of new applications. Beneath it all hum the hyperscalers—AWS, Azure, and Google Cloud—whose data centers, energy contracts, and fiber networks form the physical substrate of abundance. Together, these layers make up the new industrial stack of software: decentralized creation running on centralized infrastructure. The creative layer fragments, but the substrate concentrates.

The tension between decentralization and concentration defines this new era. Abundance empowers individuals, but dependence on shared infrastructure ensures that power and profit remain concentrated among a few dominant players. For developers and entrepreneurs, this dual reality will demand realism: access and opportunity have never been greater, but so too is reliance on the invisible scaffolding of compute, models, and networks owned by others.

The Cambrian explosion will produce extraordinary diversity, but the ecosystem that sustains it will remain highly managed, capital-intensive, and vertically integrated. And immensely profitable.

Subscribe now

For generations, careers have begun the same way. You took an entry-level role, slogged through repetitive tasks, and slowly built the skills that prepared you for more responsibility. The work wasn’t glamorous, but it was essential — it was the first rung on the ladder.

Artificial intelligence is removing that rung.

New research from Stanford economists Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen - see the Canaries in the Coal Mine paper. - shows employment among 22- to 25-year-olds in AI-exposed jobs has dropped sharply since late 2022. In software development, headcount for that group is down nearly 20 percent. Customer service and translation show similar patterns. Older workers in the same jobs are largely unaffected.

The explanation is clear: AI is replacing codified, rules-based tasks — exactly the kind that once defined entry-level work — while leaving tacit, experience-based skills intact. The result is fewer opportunities for new graduates trying to gain a foothold in the labor market.

Not everyone accepts this as inevitable. Matt Garman, the new CEO of Amazon Web Services, has called the idea of cutting junior developers “one of the dumbest things I’ve ever heard.” His reasoning is simple: junior employees are the cheapest on the payroll, they are “AI-native” — already comfortable with the tools — and they form the pipeline for tomorrow’s leaders. Stop hiring them today, and in ten years you’ll have no bench.

It’s a compelling argument, but it has limits. Being “AI-native” doesn’t automatically make someone effective. A novice carpenter with a set of power tools won’t suddenly produce masterwork furniture. Without experience, they may misuse the tools, make errors they can’t diagnose, or fail to see how the pieces fit together. The same tools in the hands of a skilled carpenter, however, produce extraordinary results. AI is no different. Pair it with senior developers and the output is amplified; pair it with juniors lacking context and the result can be brittle or even harmful. AI plus seniors is far greater than AI plus juniors.

So what now? If AI has automated away the first rung of the ladder, how do we create new ways for people to climb? Two paths stand out.

First, universities and the education system must adapt. Relying on entry-level jobs to serve as training grounds is no longer viable. Schools need to prepare students for a higher starting point, emphasizing problem framing, system design, and AI supervision instead of rote coding or repetitive analysis. The missing rung must be rebuilt in the classroom.

Second, companies must resist the temptation to cut off entry-level hiring. Business continuity depends on a steady pipeline of talent. Even if juniors are less effective with AI today, firms cannot afford to leave the bench empty. Structured programs, apprenticeships, and explicit training can help bridge the gap, ensuring that new entrants still accumulate the tacit skills machines cannot provide.

AI has made intelligence abundant, but experience remains scarce. Eliminating the first rung of the ladder leaves the entire structure unstable. If universities reimagine how they prepare students, and if companies continue to invest in new talent, the ladder can be rebuilt.

If not, abundance risks becoming exclusion — a world where opportunity exists only for those who already sit at the top, and that’s very short-sighted.

Subscribe now

Economics begins with scarcity. Land, labor, and capital have always been limited, and societies have been organized around how best to allocate them. The theory of abundance argues that artificial intelligence is eroding scarcity in two of those inputs: intelligence and labor. Tasks that once demanded months of work by skilled professionals — writing software, analyzing data, drafting contracts, designing campaigns — can now be done in minutes, replicated infinitely, and adapted at no meaningful cost.

The effects of this shift ripple far beyond software. As AI reduces the marginal cost of intelligence-based work, it threatens to automate away millions of jobs, displacing workers in sectors from customer service to law. The abundance of digital labor also creates pressure on wages, polarizing labor markets between those who supervise, govern, and direct AI systems and those who are displaced by them. Society will need to confront the consequences: new definitions of meaningful work, new safety nets, and new forms of inequality. At the same time, AI-driven robotics and scientific discovery could push abundance into the physical world — lowering the cost of housing, medicine, and energy, and shifting scarcity into areas like trust, distribution, and governance.

Each of these transformations deserves deep analysis. But to make the discussion concrete, this article will focus on software, the first domain where abundance is already being felt. By examining how AI reduces the marginal cost of software to nearly zero, we can see more clearly how industries are unmade and how new winners emerge. Future essays will return to labor markets, society, and the broader economy.

Software has always been unusual in its economics. Copying it has been nearly free, but creating and maintaining it has been expensive. The SaaS model rested on this asymmetry: companies absorbed high fixed costs to design and maintain software, then scaled to millions of users at high margins. AI destabilizes this model. By automating coding, debugging, and maintenance, it drives the fixed cost of creation toward zero. With both creation and distribution essentially free, the foundations of the industry shift.

That shift raises the central question: in a world where software itself is abundant, how does a software company compete, and how can it win? The answer lies in recognizing where scarcity has reappeared.

One arena is what might be called the outcome economy. If anyone can build a tool, the tool itself no longer commands a price. What is scarce is the ability to credibly guarantee results. Many vendors will claim their product improves conversions or resolves support tickets faster. Very few will be able to measure those outcomes rigorously, integrate into workflows to prove them, and assume risk if they fail. The scarce good is not outcomes in the abstract, but trustworthy accountability: verifiable, contractually guaranteed results.

Another arena is data. Code may be free, but proprietary datasets remain deeply scarce. They make outcomes measurable, they enable personalization, they fuel trust, and they drive speed. More importantly, they compound: usage generates data, which improves performance, which attracts more users, which generates more data. Companies already recognize this dynamic. Salesforce’s restriction of AI access to historical Slack data is a vivid example: strategically, it locks in a moat. Only Salesforce can use Slack’s conversational history to power its models, turning that dataset into both a competitive fortress and a guarantee of trust to its customers.

Closely related to data is context and attention. Not all data is equal; raw data is abundant, but context-rich data that maps to user preferences and workflows is scarce. It is what makes personalization meaningful, allowing software to become uniquely indispensable to each user. Attention is scarce for the same reason. With infinite personalized tools vying for mindshare, the battle shifts to who can maintain durable engagement and weave themselves into daily routines.

A fourth arena is the explosion of niche applications. When software creation is practically costless, problems once considered too small to matter suddenly get solved. Millions of micro-apps and AI agents will emerge — some serving whole industries, some only one company, and some even a single individual. But this proliferation creates fragmentation, and fragmentation shifts scarcity to those who can provide trust, integration, and distribution. This is where Ben Thompson’s aggregation theory becomes crucial. Thompson showed how internet-era power shifted from producers to aggregators — platforms like Google, Facebook, and Apple that organize abundance and control demand. The same logic applies here: the winners in the AI era will be those who aggregate countless micro-apps into cohesive ecosystems. They will orchestrate secure environments with identity, billing, compliance, and interoperability baked in, becoming the trusted gateway through which abundance flows.

Finally, in a world of infinite competitors, speed itself becomes scarce. When anyone can generate an app overnight, the half-life of innovation shrinks dramatically. The scarce factor is the organizational ability to learn, adapt, and deploy faster than the rest of the market. It is not just speed of shipping that matters — code is abundant — but speed of learning, iteration, and trust-building. Companies that can close feedback loops quicker — translating usage data into improvements and then into stronger customer relationships — will pull ahead in ways others cannot replicate.

This is how scarcity reappears when software becomes free: it migrates into domains where abundance cannot follow. And it is in these domains that companies must compete.

In a world of zero-cost software, five scarcities define the new competitive order. Not all of them are equal, and their relative importance determines the depth of the moat they provide:

• Data sits at the foundation. It is the hardest to replicate, compounds over time, and fuels everything else.

• Trust and Integration come next. Platforms that aggregate abundance into secure, reliable ecosystems become irreplaceable gateways.

• Accountability follows, powerful because customers will pay for outcomes, but dependent on the data and trust that make outcomes measurable and credible.

• Speed is critical in the short run, enabling firms to outpace infinite competitors, but it erodes quickly unless anchored by stronger foundations.

• Context and Attention are valuable for personalization and stickiness, but the most fragile, as attention is fickle and context loses strength without the anchor of proprietary data.

Software companies will not win by producing code — anyone can do that. They will win by mastering these scarcities in order of their strategic depth. Those who secure data and trust will build enduring advantages; those who rely only on speed or attention will find their lead fleeting. In the age of abundance, the hierarchy of scarcity will decide the hierarchy of winners.

Suggested Reading

• Sam Altman, “Moore’s Law for Everything” (2021) — outlines how AI and robotics could make most goods radically cheaper, driving a future of abundance (moores.samaltman.com).

• OpenAI blog: “Planning for AGI and beyond” (2023) — explores abundance, inequality, and safety in a world of artificial general intelligence (openai.com).

• Herbert Simon, “Designing Organizations for an Information-Rich World” (1971) — classic essay introducing the idea that in abundance, attention becomes scarce.

• Ben Thompson, Aggregation Theory (Stratechery, 2015–present) — the definitive modern analysis of how aggregators organize abundance and capture demand.

• Nick Srnicek, Platform Capitalism — a critical take on how platforms build power through data and ecosystems.

Subscribe now

When I wrote about the last generation of programmers, I ended with a thought:

the age of human code is ending. What comes next is not ours to write — but to imagine.

This is one such imagining. If the keyboard is no longer our chisel, what tools will take its place? If the long hours of typing give way to something else entirely, what will the craft look like on the other side? History offers clues. Industries have been here before — changed not by the vanishing of their purpose, but by the reinvention of their methods. If AI does to software what computers once did to animation, the result may not be an extinction, but a transformation — one where the craft survives by changing shape, and the credits look very different than they do today.

In the old Disney studios, the air smelled faintly of paint thinner and coffee. Animators hunched over desks lit by swinging lamps, pencils scratching one frame at a time, walls stacked high with translucent cels like panes of stained glass. Every second of film demanded twenty-four drawings, each one touched by human hands. The workflow was an endless relay of sketches, tracings, and paint — armies of ink-and-paint artists passing each frame down the line like a sacred scroll.

Decades later, the scratching pencils are gone. In their place, the quiet whir of GPU fans. The same craft — storytelling through movement — now plays out in sleek software like Maya and Blender, characters rigged with digital bones, worlds rendered by machines that never tire. Frames aren’t painted; they’re computed - see here for more on the making for Frozen 2. What was once an artisanal marathon is now a high-tech relay, where creative leads direct armies of specialized artists, technical directors, and render farms.

Animation didn’t die when computers arrived; it adapted. In the 1980s and 90s, a single Disney feature like The Lion King employed armies of artists — as many as 600 animators and technicians working across inking, painting, and cel photography to get a film onto the screen. By contrast, when Pixar released Toy Story in 1995, the studio itself had only 129 employees, supported by a render farm of 294 processors. A few years later, Monsters, Inc. was built by a team of around 175 people — lean by Disney’s traditional standards, but augmented by the accelerating power of software and hardware.

What disappeared wasn’t animation, but the need for vast pools of manual labor. Technology changed how those stories were made, not that they were made. The workflow shifted from one long, linear assembly line to a parallel, multidisciplinary sprint. Modelers built characters, riggers wired their skeletons, animators posed the key moments, and software filled in the frames in between. Render farms took over the grunt work of lighting, shadows, and effects. Entirely new roles emerged — technical directors, shader developers, effects artists — titles that didn’t exist in the cel era but are now indispensable.

The result? More animation than ever before. A recent estimate pegged the valuation of the global animation industry valued at $270 billion in 2023 with 600 new animated films are released worldwide each year (source: here). There might be fewer people drawing frames by hand today, but more people overall work in animation today relative to these early halcyon days.

Today’s programming still looks, in many ways, like cel animation in its prime. We write code line-by-line, class-by-class, building our own in-betweens. Yes, we have compilers, frameworks, and IDEs, but the human still types the bulk of the logic. AI is our CAPS moment — the Computer Animation Production System Disney introduced in 1989 to digitize ink-and-paint. It didn’t automate the whole movie, just the tedious, repetitive parts. But it changed the economics of animation so profoundly that an entire stage of the pipeline vanished in a few short years. The AI coding assistants of today are doing the same. First they autocomplete the boring stuff. Then they scaffold entire features. Tomorrow they’ll handle full vertical slices: requirements in, production code out. And like CAPS, they’ll force us to rethink what roles exist in the pipeline.

In the animation analogy, “writing every frame” is giving way to “directing the scene.” The programmer of the future will be less the line-by-line scribe and more the maestro — orchestrating AI agents, code generators, and simulation environments. We’ll still have people who can code from scratch, just as some animators still draw by hand, but most will work in a hybrid environment, adjusting the AI’s output, setting creative and technical direction, and managing a much larger scope than any one developer could handle alone. Maybe there will be a niche industry for “hand-written software” :)

The programmer’s craft will follow the same arc as animation. In place of writing every line, much of the work will involve guiding and integrating what machines produce: defining the architecture, reviewing generated components, making judgment calls on trade-offs and user experience, and ensuring the final system works as intended. Code generation, testing, optimization, and deployment will be handled largely by automated systems. The value shifts from typing instructions into a machine to shaping, supervising, and combining the work of many machine contributors into a coherent, functioning whole.

The trick is to see AI not as the machine that replaces the human, but as the render farm: tireless, exacting, and utterly useless without a clear creative brief. The animator’s craft didn’t vanish when the pencil left the desk; it shifted into new tools, new workflows, and new creative horizons.

Marginal cost and abundance might also come in play. Jevons’ paradox tells us that when a resource becomes cheaper and more efficient to use, demand for it can increase rather than shrink. AI is set to do this for software. As the cost of building and maintaining applications falls, organizations that once couldn’t justify a custom solution will commission one. Niche tools, one-off internal apps, specialized workflows — all will become economically viable.

“If AGI is successfully created, this technology could help us elevate humanity by increasing abundance, turbocharging the global economy, and aiding in the discovery of new scientific knowledge that changes the limits of possibility.” OpenAI

Our future might see software companies employing far fewer engineers than today, but the total number of companies creating software, and the breadth of what they build, could grow substantially. That’s the abundance theory that we hope AI will unleash.

We’ll just have to wait and see how “great plot unfolds”

Subscribe now

At the dawn of the industrial loom, few weavers realized they were witnessing the end of their world. The whirring of mechanized looms in distant mills must have sounded like progress, not obsolescence. When electricity began to light city blocks, it arrived first as a novelty—a flickering bulb in a wealthy home—before spreading like wildfire through factories, streets, and lives. History has taught us that technological revolutions do not announce themselves with clarity. They arrive in whispers, scattered breakthroughs, subtle shifts in how we work and what we value. Then, all at once, the ground gives way. In the moment, it never feels like a transformation. It feels like turbulence. Confusion. Even boredom. Only later, in hindsight, do we see the rupture for what it was.

Today, I can’t help but wonder: are we in software development the frogs in the pot, warming to a boil we refuse to notice? Is AI merely making us faster—or quietly making us irrelevant?

This post explores one extreme of the AI endgame: not collaboration, but complete human displacement from the act of writing software.

In 1900, 41% of Americans worked in agriculture. By 1950, that number had dropped to 12%. Today, it's less than 2%. The transformation wasn’t gradual—it was a cascade that began slowly, then accelerated with breathtaking speed once mechanization crossed a critical threshold.

We are now witnessing the opening act of an identical drama in software development. And the final curtain will fall within five years.

The analogy goes beyond job displacement. Just as the combine harvester didn’t merely help farmers work faster—it rendered most of them obsolete—AI isn’t simply making programmers more productive. It is redefining what programming is, who can do it, and whether humans should be involved at all.

Consider the printing press. Scribes didn’t evolve into “printing assistants.” Their profession vanished. Those who adapted became editors, publishers, or moved into entirely new domains. A handful remained as luxury artisans, hand-copying wedding invitations and illuminated manuscripts for the wealthy. This is the future awaiting software engineers: a tiny class serving niche markets, while machines handle the industrial production of code.

The signs are already here, and traditional software companies should be alarmed. GitHub Copilot now generates nearly half of the code in projects where it’s enabled (see here). GPT-4 builds entire applications from natural language descriptions. Claude debugs complex systems and refactors legacy codebases. But these are just the opening moves. The real disruption comes as these capabilities compound.

By 2027, we will see the rise of what I call software synthesis systems—AI that doesn’t just autocomplete snippets, but architects entire applications from high-level business requirements. Imagine describing a banking platform to an AI that understands regulatory compliance, scalability, security frameworks, and UX best practices. Within hours, not months, it delivers production-ready code, complete with tests, documentation, and deployment pipelines. This isn’t science fiction. It’s the logical evolution of tools we already have.

The pattern of disruption will follow history: it begins at the bottom and moves up fast. Junior developers will disappear first. Their work—applying familiar patterns to well-scoped problems—is precisely what AI does best. We are already starting to see stress signals from the job market, especially for college graduates impacted by this “hollowing-out” effect:

At Chicago recruiting firm Hirewell, marketing agency clients have all but stopped requesting entry-level staff—young grads once in high demand but whose work is now a “home run” for AI, the firm’s chief growth officer said. Dating app Grindr is hiring more seasoned engineers, forgoing some junior coders straight out of school, and CEO George Arison said companies are “going to need less and less people at the bottom.” source: WSJ

But the cascade won’t stop there. AI systems are already outperforming senior engineers in narrow domains: optimizing queries, designing APIs, even making complex architectural trade-offs. The hallowing-out will move up the stack.

The most profound shift will be in who creates software. Just as desktop publishing democratized design and eliminated the typography profession, AI will make software creation accessible to anyone. Product managers will describe features and see them implemented “instantly”. Business analysts will prototype workflows without technical intermediaries. The barrier between idea and implementation will evaporate.

This will transform the very structure of companies. Today’s software organizations employ armies of engineers, architects, DevOps specialists, QA testers, and project managers. By 2030, a typical software company might consist of a handful of AI orchestrators, a few domain experts who deeply understand the business, and one or two humans to handle edge cases. The familiar engineering hierarchy—junior, senior, principal—will feel as anachronistic as the typing pools of the mid-20th century.

The economic implications are staggering. Software development today employs millions of highly paid professionals. These are not roles that can be easily absorbed elsewhere. They sit at the apex of the knowledge economy. When agriculture was automated, farmers became factory workers. When factories were automated, many moved into services. But where do programmers go when thinking itself is outsourced?

The answer lies in identifying what humans alone can contribute. Just as the rise of automobiles created new roles—traffic engineers, car designers, logistics planners—AI will open new frontiers. But those frontiers won’t be about typing code. They’ll be about directing AI systems toward valuable outcomes, integrating business and ethical context, and shaping the goals of machines that can build anything but understand nothing.

The most successful companies of 2030 will be those that adapt early. They’ll hire AI orchestrators instead of programmers, domain experts instead of technical specialists, and creative directors instead of engineering managers. Their edge won’t come from implementation talent, but from their ability to envision, constrain, and deploy machine intelligence with precision and imagination.

This will not be a slow, decades-long handoff between humans and machines. Technological disruption doesn’t wait politely. It gathers in the background, invisible at first, then arrives all at once. The companies still hiring traditional software engineers in 2029 will resemble newspapers employing typesetters in 1990—technically operational, but drifting toward irrelevance.

The last generation of programmers is already among us. Many don’t realize it yet. They merge pull requests, review PRs, and plan their careers as if the ground beneath them isn’t shifting. But a few—the perceptive, the pragmatic, the quietly anxious—have begun preparing. They are learning how to direct AI rather than outpace it. They are developing deeper domain fluency, ethical intuition, and creative judgment. They are asking new questions.

Because something else is being lost. And the loss is not just economic.

It’s the late-night debugging session that ends in triumph and relief. The click of minds aligning in front of a whiteboard. The slow, quiet transformation from apprentice to master, measured not in promotions but in clarity of thought. That rhythm is fading. In its place: infinite ambiguity, frictionless generation, the disorienting pace of tools that invent faster than we can absorb. Everything is faster, but nothing settles. The future arrives before the present is done loading.

Still, history reminds us that the end of one practice is often the beginning of another.

When photography arrived, painting didn’t die—it turned inward and reimagined itself. When the synthesizer appeared, music fractured, recombined, and gave birth to entirely new genres. Software may do the same. Stripped of its syntax and tedium, it may evolve into something more expressive, more philosophical, more strange. We may stop writing code not because we’ve lost the will, but because we’ve found a better canvas.

And so the next revolution in software may not be in the writing at all, but in the choosing. In the asking. In the quiet, human work of deciding what should be built when anything can be.

The age of human code is ending.

What comes next is not ours to write—but to imagine.

Subscribe now

In the early days, all startups are products. They solve a narrow, painful problem exceptionally well—better than anything that exists. Their advantage is sharpness. They can move fast, iterate quickly, and deliver value to a specific user or team without needing buy-in from the entire org.

But as they grow, they encounter a powerful adversary: the Platform.

The platform doesn’t need to be better. It just needs to be broad. It doesn’t win because it delights users—it wins because it satisfies buyers. The platform is not about elegance; it’s about inevitability. The Platform, in the words of Steve Ballmer is:

“There was IBM man. IBM was still the sun, the moon, and the stars" Source: Acquired

What Is a Platform?

A platform is not just a big product. It’s a unified system that serves multiple use cases across different teams. It offers extensibility, integration, and a coherent architecture that can absorb new features and surface areas without losing control.

Salesforce is a platform. It began as a CRM, but expanded horizontally into service, marketing, analytics, and development tooling. More importantly, it opened itself vertically—via AppExchange and Force.com—to become programmable and integratabtle. That’s when it stopped being a product company and became a gravity well.

Why buyers prefer Platforms

Multi-Use justification
Products often serve one team or use case. Platforms can spread their value across many teams and use cases, they can often span the entire organization. That makes the buying decision easier to justify internally.

One vendor, one contract
Procurement prefers fewer vendors. It reduces compliance surface area, legal overhead, and integration risk. Platforms win here by simplifying the relationship—even if the tools are weaker.

Pricing power through bundling
Platforms can offer “good enough” features for free as part of a broader package. A standalone vendor charging six figures for a specialized tool can’t compete with a bundled checkbox.

Perception of integration
Even if the experience isn’t perfectly integrated, the illusion of cohesion—one UI, one login, one data model—is powerful. Platforms promise harmony, even if it’s shallow.

The result? Buyers choose platforms more often than not. Even when products are better. So, if you’re a startup building a great product, what can you do?

So what can a startup that it at the product stage do to counter a platform? There are four paths that I can think of.

Become a Platform

The first and most ambitious path is to fight fire with fire: build enough surface area to become a platform yourself.

Databricks is the clearest modern example. It started as an execution engine for Apache Spark—focused on distributed compute for data science. Over time, it expanded across every layer of the data stack. It launched Delta Lake its own table format (it also acquired Tabular), then Unity Catalog (governance and security), added Databricks SQL to support traditional BI workloads, and most recently moved into OLTP via its acquisition of Neon. It now serves ML, analytics, storage, security, governance, and transactions—all within one programmable control plane.

Databricks didn’t just build more features. It built a system. It stitched together a coherent and expanding story that let it compete not just with Snowflake on storage and analytics, but with the entire enterprise data platform ecosystem.

Becoming a platform means you have to scale your roadmap, your architecture, and your market narrative—all at once. It is capital intensive, organizationally demanding, and technically non-trivial. But if you succeed, you escape product gravity and create your own.

Become a 100x better Product

If you can’t match breadth, you can still dominate through depth. You can win by being so much better than the platform’s equivalent that buyers are forced to notice—and adopt—even if it creates friction.

Wiz is the canonical example here. The cloud security market is filled with platform incumbents: Palo Alto, CrowdStrike, Check Point, and more. But Wiz redefined the category with a radically better product. It was agentless, deployed via cloud provider APIs, and delivered full-stack visibility within minutes. It worked across AWS, Azure, and GCP without deep installation work. No agents, no fragmentation, no stitching together consoles.

Wiz didn’t try to integrate with the legacy platforms. It ignored them. Instead, it focused on clarity, speed, and usability. In doing so, it made everything else look slow and bloated. That strategy powered it from launch to a $10B+ valuation in less than five years, culminating in a $32B acquisition offer from Google.

This approach works when the buyer is facing a deep enough pain that “good enough” won’t do. It works when your product reframes expectations, not just improves metrics. But being 100x better isn’t easy. It means you can’t just be faster—you have to be unignorable.

Own a niche the Platform ignores

Most platforms follow the money. They build for large markets and common denominators. That creates white space—edges and verticals where they can’t, or won’t, focus.

Dremio may represent this play. Competing with Snowflake and Databricks on performance or ecosystem is difficult. But there's a niche hiding in plain sight: on-premises Hadoop modernization.

There are still thousands of enterprises running on-premises Hadoop clusters—many of them large, complex, and too risky to “lift and shift.” Snowflake and Databricks are largely cloud-native, and neither has invested deeply in hybrid execution or transitional architectures. Dremio, with its roots in Apache Arrow and focus on data lake query acceleration, could position itself as the best migration bridge for organizations stuck on Cloudera-era tech.

Being a niche player means accepting a smaller TAM. But it also means less competition, more defensibility, and longer customer retention—especially if the niche is underserved and high-margin. Niches can also be acquisition targets for Platforms. A Platform player might want to acquire a Niche player to extend its Platform into an area the Niche serves.

Become a zombie

The final option isn’t really a strategy—it’s what happens by default if you do nothing.

You stay a product. The platform copies your feature. Or gives it away for free. Or makes the buyer feel like your existence is friction, not leverage. You become a zombie.

Without enough differentiation, and without ecosystem leverage, you drift into procurement purgatory. You get cut in every budget cycle. Your ACVs shrink. Your growth stalls. And eventually, your best customers churn—because they were only using you until the platform was “good enough.”

This is the quadrant nobody wants to be in—but one many startups find themselves in without realizing it.

So What should you do?

In retrospect, the most successful startups almost always follow one of two paths: they either become platforms, or they become 100x better products. That’s where outsized outcomes live. That’s how you change the game.

Becoming a platform gives you gravity. Becoming a 100x product gives you velocity. One lets you pull others into your orbit. The other lets you break free from theirs.

But not every startup can get there.

Becoming a platform requires capital, long-term vision, and organizational range. You need to build surface area fast enough that your expansion feels like momentum, not distraction. That’s not just a roadmap problem—it’s a team, execution, and funding challenge.

Becoming a 100x product demands deep product insight, technical elegance, and absolute clarity about what pain you’re solving. It often means ignoring everything that doesn’t contribute to core value—and enduring the friction that comes from standing outside the ecosystem.

If you can't do either, the next best option is to own a niche. A narrow but defensible segment. A vertical where the platform is weak or absent. A buyer persona overlooked by the mainstream. You won’t win the market, but you can win a market—and build a durable business on that footing.

But there’s no dignity in drifting.

If you fail to choose, you end up in the dead zone. Not differentiated enough to command attention. Not integrated enough to ride coattails. Not focused enough to dominate a niche. You become a zombie—just good enough to stay alive, but not good enough to grow.

So choose. Choose boldly and early. Be a platform. Be a 100x product. Own a niche. But whatever you do, don’t drift into irrelevance hoping the market will notice. It won’t.

Subscribe now

This post is a little different than my usual ones. It lives somewhere between my day job—thinking about identity, access, and governance at StrongDM—and a topic that seems to have taken over every architecture conversation lately: AI agents. You can’t swing a virtual stick these days without hitting a demo where an agent is booking meetings, writing code, or orchestrating cloud workflows. But with great autonomy comes great... attack surface. This is a longer, deeper dive into one specific corner of the problem space: how we govern and secure what these agents can actually do. If it reads a little nerdier than usual, that’s because it is. But if your AI agents are starting to look less like chatbots and more like coworkers with API keys, I think you’ll find it relevant.

AI agents are rapidly becoming a new force in enterprises, evolving into sophisticated digital co-workers. These autonomous, AI-driven programs can perceive, decide, and act within digital systems, offering capabilities far beyond traditional scripted chatbots or robotic process automation (RPA) scripts. From customer support bots that resolve complex issues to finance agents that analyze and even initiate transactions, AI agents are redefining how businesses operate. Unlike their predecessors, modern AI agents possess a remarkable degree of autonomy and adaptability, enabling them to pursue higher-level goals, interact with multiple applications, and make independent decisions.

The very qualities that make AI agents so powerful—their autonomy and ability to dynamically plan actions—also introduce unpredictability. Earlier generations of AI, like simple chatbots or recommender systems, only responded to specific prompts. In contrast, an autonomous agent can initiate actions independently, creating ambiguities in oversight and accountability. For instance, an AI agent integrated with HR and finance systems might decide to issue a refund or reconfigure a server without explicit human intervention. This level of initiative can quickly become a security nightmare if not properly governed.

At their core, AI agents introduce a new type of non-human identity within our digital systems—one that can act with substantial independence. This new paradigm has caught many organizations off guard. Just as human users require rigorous authentication, authorization, and oversight, these non-human agents demand similar scrutiny. However, the practices for doing so are still nascent. Key security requirements are emerging, including identifying human users to the agent, enabling the agent to securely call APIs on users’ behalf, managing long-lived agent workflows, and enforcing fine-grained data access so agents only see what the user is permitted to. Enterprises are currently scrambling to address these needs, often building ad-hoc, "DIY" controls due to the lack of an established blueprint for securing AI agents end-to-end.

AI Agents ~= Microservices?

While securing AI agents presents unique challenges, we can draw valuable inspiration from a field that previously dealt with a similar challenge of distributed, non-human actors: microservices. The shift to cloud and microservices over the past decade forced organizations to secure a complex web of APIs and automated services communicating with each other. This led to the development of robust security patterns that are highly relevant to AI agents today. At a high level, the industry learned to treat every service or workload as an independent principal with strict security controls, embodying the essence of modern zero trust architecture: even within your network, every request between components must prove its identity and be explicitly authorized.

Specifically, microservice architectures adopted several key practices that map well to the security needs of AI agents:

Workload identity + mTLs + e2e encryption: Instead of implicitly trusting a service because it resides on the internal network, each microservice is issued a unique cryptographic identity (e.g., an X.509 certificate or JWT). Services authenticate to each other via mutual TLS handshakes or token exchange, cryptographically verifying the origin of every call. This approach, pioneered in cloud-native systems, ensures that no service communicates with another without proof of identity. The same principle applies to AI agents: every agent instance should present credentials (certificates or tokens) that a target system validates on each interaction. By using strong, auto-rotating identities instead of static API keys or passwords, it becomes significantly harder for an attacker to impersonate an agent or intercept its communications. Additionally, all service-to-service communication is typically encrypted and authenticated, often via service mesh infrastructure, ensuring that messages cannot be read or tampered with even if an attacker sniffs the internal network.

Fine-Grained Access Control (FGAC): Identity alone is insufficient; it's also crucial to restrict what each service or agent is allowed to do. In microservices, this led to the adoption of fine-grained authorization policies, often implemented via policy engines or attribute-based access control. Instead of a service having blanket "admin" rights, it receives only the minimum permissions it absolutely needs—the principle of least privilege. For example, a reporting microservice might only be allowed to read customer data but never delete it. Similarly, an AI sales agent designed to draft emails and log notes should only have permission to create records in the CRM, not to drop entire tables.

Delegated access (OAuth2): When microservices need to access data on behalf of a user, they commonly use protocols like OAuth2 rather than storing user passwords. A classic pattern involves the OAuth2 client credentials or token exchange flow, where the service obtains a scoped token that specifies, "This is Service X acting for User Y, allowed to do Z." This enables backend services to make delegated API calls with bounded scopes, meaning that if the token is leaked or misused, its powers are limited and time-bound. AI agents should follow this practice. For instance, if an AI customer support agent needs to retrieve a user’s order history from an e-commerce API, it should use the company’s OAuth mechanism to request a token scoped to "read order history for user X," rather than logging in with a master admin credential.

In summary, the microservices world taught us to treat machine identities seriously and eliminate implicit trust. We implemented strong identities, thorough authentication on each request, fine-grained authorization, encryption in transit, and robust auditing.

AI Agents != Microservices

While many microservice best practices carry over, AI agents are not identical to microservices. Their unpredictability and learning capabilities introduce aspects where the traditional model falls short, requiring adaptation.

Dynamic and unpredictable behavior: Microservices execute code that developers explicitly wrote and vetted. An AI agent, on the other hand, can dynamically devise new action sequences in response to changing inputs. This means an agent might attempt an operation no one explicitly anticipated. Static roles and permissions cannot fully capture the fluid context in which agents operate. What’s needed are context-aware, just-in-time permissions that adjust based on the agent’s current task, risk level, and observed behavior.

Extended privileges and lifecycle: Microservices typically run with fixed scopes and are often short-lived processes designed to perform a single task. AI agents, however, might persist and evolve over time; some agents even generate new code or spin up sub-agents as part of their operation. This blurs the boundary of what exactly we are securing. If an agent can instantiate new helper processes to handle subtasks, those new processes also need identities and oversight. A misconfigured agent could accidentally launch a tool that bypasses normal controls. In contrast to microservice security’s assumption of a relatively static topology, agent security must handle a more fluid, self-modifying environment.

Human+AI : With microservices, human intervention for routine API calls was rarely considered, as the logic was deterministic. But AI agents can venture into ambiguous territory where a human approval step is prudent. We might need to define which agent-initiated actions require a "checkpoint"—be it a manager’s approval, a secondary confirmation from another system, or additional validation. This concept of human-in-the-loop checkpoints adds an extra layer on top of microservice-style controls.

Its worth noting that, AI agents are susceptible to novel attack vectors, such as prompt injection, where malicious inputs can trick the agent into performing unintended actions. These attack vectors are unique to agents and have no equivalent in the microservices space. Hence, the ability to map security principles from microservices 1:1 to agents will not cover the idiosyncratic security challenges of agents.

The bottom line is that microservices security provides a necessary foundation, but AI agents demand an even more fine-tuned and vigilant approach. We must assume these agents will surprise us, so our security model has to be dynamic, granular, and infused with skepticism at every turn.

Zero Trust: Agent edition

To effectively govern and secure autonomous AI agents, organizations should adopt a forward-looking, Zero Trust mindset combined with granular policy guardrails. In practice, this means treating AI agents as untrusted by default—just like any external user or service—and enforcing strict verification, least privilege, and continuous oversight. Therefore, my key principles for robust AI agent security include:

Trust, but verify: Every interaction involving an AI agent should require explicit authentication and authorization, as if it were an external entity. No agent gets a free pass simply for being "inside" the firewall. We must "assume the worst"—that any agent or component could be compromised—and verify every call and request in your systems accordingly. This includes internal API calls, database queries, file access, and more. Each time, the agent’s identity, the action it’s attempting to perform, and the context should be meticulously checked against policy.

Least privilege access: As with microservices, granting AI agents the minimum privileges they need is crucial—arguably even more so, given their inherent unpredictability. If a customer support agent only needs to read knowledge base articles and create support tickets, that’s all it should be allowed to do. Least privilege significantly limits the damage if an agent malfunctions or is hijacked.

Dynamic, Just-In-Time access: Given the fluid nature of AI workflows, it’s wise to use short-lived credentials and dynamic privilege escalation rather than static keys or permanent admin rights. In cloud security, we’ve learned to use ephemeral tokens (e.g., AWS IAM roles that issue temporary credentials for 15 minutes). AI agents should be equipped similarly. Issue them short-duration tokens or certificates that expire quickly, so even if leaked, they cannot be abused for long. If an agent needs elevated access for a special task, adopt a just-in-time access model: have it request the higher privilege at the moment of need, obtain approval (automated or human), and then auto-revoke it after a brief window

Continuous Monitoring and Verification: AI agents operate continuously, potentially making thousands of decisions. Security cannot be a one-time gate at login; it must be an ongoing process. Organizations should monitor agent behavior in real-time and flag anomalies. This could involve tracking metrics such as: Is the agent suddenly reading an unusual amount of data? Is it accessing systems it has never used before? Such monitoring might feed into an automated risk scoring system that can dial down permissions or alert security staff if an agent acts out of bounds. Equally important is maintaining detailed logs of all agent actions—every API call, every critical decision—to enable forensic analysis and accountability.

Policy-as-Code: This is arguably the most critical element and is key for FGAC. In a complex, dynamic environment, manual or ad-hoc security rules will not scale. Enterprises should express their AI governance and security rules as code, similar to how infrastructure-as-code revolutionized operations. Using a policy-as-code framework ensures that all these decisions (what an agent can access, when to require human approval, what constitutes abnormal behavior) are defined in a versioned, testable, and automatable way. For example, a policy rule might state: "AI agent X may only access database Y during business hours and must have an active user session token if it’s reading personal data." By encoding this in a policy engine like StrongDM’s Cedar Policy Engine, enforcement becomes consistent across all systems. Policy-as-code also simplifies audits by providing a single source of truth for agent permissions. It's an approach that vendors have promoted to unify security checks in an auditable, automated framework and is increasingly considered a best practice.

There’s one wrinkle to FGAC and policies: where and who evaluates these policies?

If every system an agent touches—databases, SaaS APIs, internal services—enforces policy independently, it becomes nearly impossible to manage or reason about the agent’s effective privileges. Policies will diverge, gaps will emerge, and no centralized system will have visibility into what the agent is actually allowed to do in any given context. The result is an incoherent security posture vulnerable to drift and privilege escalation. The solution is to shift policy enforcement up to the agent orchestration layer—the component that mediates between the agent’s reasoning loop and the concrete actions it takes on enterprise systems. By enforcing FGAC policies in the orchestrator, organizations can apply consistent, context-aware rules across all tools and services the agent might access. Backend systems should still maintain static guardrails, but dynamic policy—governed by who the agent is, what data it has seen, what user it may represent, and what the current risk posture is—must be enforced at the orchestration layer, before actions are executed.

I started this (lengthy) post drawing on an analogy between AI agents and microservices. At first glance, both appear similar. Both are automated actors operating in distributed systems, invoking APIs, exchanging data, and requiring authentication and authorization. It is natural—and useful—to borrow proven patterns from microservices security as a starting point for governing agents.

But this is ultimately an analogy, and analogies can introduce dangerous biases. Where microservices execute predefined, deterministic code, agents reason dynamically, generate novel actions, and evolve their internal state over time. Microservice interactions are typically bounded; agent workflows are stateful, open-ended, and prone to influence by untrusted inputs. Relying too heavily on the analogy risks underestimating these differences and overlooking the need for new control points—especially around information flow, prompt lineage, orchestrator policy enforcement, and dynamic privilege management.

The core lesson is this: we should absolutely leverage the security insights of the microservices era, but we must also recognize where agents fundamentally differ, and design accordingly. The cost of getting this wrong is high—not just fragmented policy, but real risk of uncontrolled agent behavior.

Subscribe now

Over the past two weeks, I’ve been using OpenAI Codex extensively—and the experience has been nothing short of profound. It reminded me of the first time I used the internet or sent an email: that jolt of realization that everything was about to change. With Codex, I wasn’t just writing code—I was collaborating with a system that could understand intent, anticipate next steps, and translate natural language into functional software. It was equal parts exhilarating and unsettling. In those moments, it became clear to me that we’ve reached a watershed moment in the history of software development. The tools we use, the skills we prioritize, and even the very identity of a software developer are all on the brink of transformation. This isn’t just an incremental leap in productivity—it’s the dawn of an entirely new era.

We are approaching a profound inflection point in software development. For decades, writing software meant wrestling with syntax, typing logic line by line, and debugging flows manually. But with the rapid ascent of generative AI, this model is breaking down. Soon, code won’t be handcrafted—it will be inferred, synthesized, and generated from natural language. The developer’s primary task won’t be writing code, but expressing intent.

This shift isn’t a matter of productivity alone. It rewires the fundamentals of what it means to build software. In a future where AI writes most of the code, the role of human developers evolves from coders to intent architects. They won’t be programming machines—they’ll be shaping systems, guiding models, and validating behaviors. And this shift will be as disruptive as it is liberating.

Humans as intent architects

In the new paradigm, humans define what they want software to do, not how to implement it. Developers articulate goals, constraints, and desired behaviors in natural language or domain-specific formats. AI then translates these specifications into executable code, often generating everything from the user interface to backend services and deployment pipelines.

This doesn’t mean the developer disappears. Instead, their expertise migrates upstream. They become curators of clarity—refining how problems are framed, ensuring that context is captured accurately, and steering the AI toward solutions that align with business and ethical goals. Programming becomes less about syntax and more about intent refinement, architecture shaping, and iterative dialogue with intelligent agents.

But this upstream shift in responsibility brings with it a new kind of challenge—one rooted not in creation, but in comprehension. As AI becomes the primary author of software, the scale and volume of code being produced will vastly outstrip human capacity to parse it line by line. The act of reading code, once a cornerstone of engineering rigor, becomes increasingly obsolete. We’re already starting to see signs of this strain on human software developers with some Amazon developers comparing their jobs now, with AI, resembling that of warehouse workers

In this new landscape, how do we ensure that what the machine builds is correct, secure, and aligned with our goals?

As AI systems generate more code than any human could review, the traditional concept of code review breaks down. It simply won’t be feasible—or useful—for humans to read every line. Instead, validation becomes the new review. Rather than inspecting source code, developers will validate behavior: Does the system do what we expect? Does it meet performance constraints? Are security and compliance guarantees upheld?

Testing becomes both broader and deeper. Developers write declarative specifications of what the software should do, and AI executes thousands of permutations, simulating edge cases and probing for logical flaws. The human engineer becomes the overseer of test outcomes, watching for deviations and updating constraints rather than chasing bugs through lines of code.

And just as humans can no longer keep up with the sheer scale of code output, we will increasingly rely on AI systems not just to write, but to police each other. This evolution in oversight redefines how trust and reliability are enforced.

To manage the scale and complexity of AI-generated code, we’ll deploy AI agents to test and monitor other AI agents. Dedicated watchdog systems will continuously observe application behavior, looking for regressions, performance drifts, or security anomalies. Adversarial agents will attempt to break the system—stress-testing logic and simulating attacks.

This creates a self-regulating ecosystem, where AI writes the code, other AIs validate and harden it, and humans supervise the orchestration. Much like modern airplanes are flown by software that is itself monitored by redundant control systems, future software will be created and sustained through layers of autonomous agents designed to cross-check and audit one another.

And within this AI mesh, the human’s job becomes less about operational control and more about architectural influence—designing constraints and guiding principles rather than functions.

With AI generating the actual implementation, human developers focus on designing the scaffolding around the system: constraints, boundaries, guardrails. They shape operating envelopes—what the system is allowed to do—and define high-level policies that guide AI decision-making. Rather than debugging functions, they define what safe, secure, and ethical behavior looks like.

This also shifts responsibility. The engineer becomes accountable for the system’s intent and alignment, not just its output. They must ensure that the AI optimizes for the right objectives and that unintended consequences are caught early. Governance becomes a core skill, as developers act more like system stewards than builders.

In essence, the nature of software creation becomes more abstract, and in doing so, more holistic. The emphasis moves from construction to choreography.

Eventually, “programming” may resemble simulation and systems design more than traditional development. Developers will construct hypothetical models of what a system should do, simulate its behavior in sandbox environments, and deploy iteratively. Tooling will evolve to provide explanations—summaries of what each AI-generated module does, how it was derived, and where it diverged from previous behavior.

In this world, developers will spend more time watching systems behave than typing logic. It will feel less like writing code and more like directing a living organism. The interface between humans and machines will shift from keystrokes to iterative interaction—hypothesize, test, refine, and observe.

And yet, with this remarkable transformation comes a subtle loss—one that developers will feel in ways that aren’t easy to quantify.

The creativity impact: Is intent enough?

There is an inherently creative joy in writing software—the act of shaping ideas into logic, the satisfaction of elegant syntax, the meditative rhythm of solving problems through code. When that work is offloaded to AI, we don’t just eliminate drudgery; we surrender a part of the artistic process.

Reviewing code is not creative. Shaping architecture, validating tests, and managing system alignment—these are necessary and critical, but they are not the same as building from scratch. We risk turning the developer into a curator of behavior rather than a maker of tools.

Yet perhaps this is a narrow view of creativity. Perhaps the creative act isn’t writing the code—it’s defining the intent behind the code. Maybe creativity now lives in how we describe problems, how we imagine new systems, how we constrain and orchestrate AI’s execution.

Still, something changes. The tactile intimacy of code vanishes. And as we enter this new age, we must ensure we don’t lose sight of the human spark that made software beautiful in the first place.

Ultimately, the most profound change is philosophical. Humans stop being the authors of software and start becoming the governors of software-producing systems. We stop wrestling with the machine and instead guide the machine that builds the machine. Our job is to test alignment, spot drift, shape ethical boundaries, and ensure that the systems we create serve meaningful human goals.

This won’t be easy. It demands new skills, new tools, and a rethinking of software education. But it also offers a path toward unimaginable productivity and creativity. In the end, AI won’t make developers obsolete—it will elevate them, allowing them to operate at the level of ideas, not syntax.

The future of software isn’t less human. It’s more human, because we’ll finally be free to focus on what matters most: vision, values, and intent.

Subscribe now

There’s a moment in every startup’s life when the code starts creaking.

The product is taking off, engineering headcount is doubling, and delivery pressure is peaking. But the codebase — the quiet foundation beneath it all — is groaning under the weight of shortcuts, TODOs, and one-off hacks that were never meant to last. The team is shipping fast, but you can sense the drag. New engineers get stuck. Features take longer. Bugs feel familiar.

Welcome to the invisible gravity of technical debt.

At a fast growth startup, this moment comes fast and hard. You’re hiring aggressively, onboarding new engineers weekly, and running sprints at full tilt. There’s no appetite for a six-month rewrite. But there’s also no future in letting tech debt accumulate unchecked. So the question becomes: how do you sustain velocity without mortgaging the long-term health of your codebase?

Here’s how we think about it.

Integrate tech debt into the sprint — always

Don’t treat tech debt as a separate initiative. It lives inside the sprint (or whatever working model you are adopting), side by side with feature work. That means that every team, every sprint, is expected to allocate a portion of their capacity to paying down debt — reviewing brittle code, refactoring awkward abstractions, deleting dead paths.

Some teams keep it loose, picking up debt items mid-sprint when they hit friction. Others are more structured, blocking off a fixed percentage of sprint time. My preference is to not allocate a fixed capacity and instead deal with it as it arises. Either way, the mindset is the same: tech debt is not a tax, it’s a part of the work. You don’t pause to clean the kitchen — you clean as you cook.

The upside is obvious: you reduce entropy incrementally, without stalling delivery. The risk, of course, is that tech debt becomes an afterthought — deprioritized when deadlines loom. That’s why we pair this practice with something else: visibility.

Visibility: maintain a living backlog of technical debt

It’s tempting to let tech debt live in engineers’ heads. Don’t.

You should maintain a shared, visible backlog of known debt — real items, with descriptions, tags, severity levels, and suggested owners. It’s treated like any other backlog. Product managers, tech leads, and ICs can all contribute. It’s a running inventory of the friction points we’re actively choosing to accept (or not).

And here’s the nuance: don’t just wait for teams to volunteer to fix it. EMs and tech leads should routinely pull from the backlog and assign items into sprints — often framing them as enabling work for upcoming features. This bridges the gap between debt and delivery: you’re not just fixing things for the sake of tidiness; you’re paving the road for what’s next.

Visibility turns technical debt from a vague, ambient concern into a trackable, solvable problem. It also has the pleasant side effect of reminding leadership that these issues exist — and that resolving them pays real dividends.

Invest in a Platform team to fight systemic debt

At some point, your product engineers will hit limits they can’t solve within their own domains. CI pipelines that crawl. Internal tools that nobody maintains. Shared libraries that everyone’s afraid to touch. This is the territory of systemic debt — and it demands a systemic solution.

Enter the Platform team.

Platform teams are not a catch-all infra group. It’s a focused crew tasked with reducing friction across the entire engineering org. Their roadmap is built from pain: slow test runs, flaky deploys, repeated “how do I…” questions in Slack. They abstract, automate, and clean up the places where local debt becomes global dysfunction.

Crucially, this team isn’t off to the side. They partner closely with feature teams, embed when needed, and treat developer experience as their customer. Their metric is not uptime — it’s flow.

The investment isn’t cheap. You’re trading product velocity for foundational improvement. But in a hypergrowth environment, every hour you save across the org compounds. And there’s no better way to amortize that cost than by making the whole system faster.

Foster a culture of quality

Processes and backlogs only get you so far. Culture fills the gap.

Engineers should be expected to leave the codebase a little better than they found it. That could mean renaming a confusing variable, simplifying a conditional, or deleting a function that nobody uses. These aren’t grand refactors. They’re tiny acts of care. Call it opportunistic cleanup. Call it pride. But over time, it adds up.

Code reviews reinforce this ethos. They should encourage questions like: “Is this the simplest thing that could possibly work?” “Is there an abstraction here we’re prematurely introducing?” “What would this look like if we deleted it instead?”

And as new engineers join, this culture needs constant reinforcement. It’s modeled in onboarding, in pair sessions, in Slack threads. And it’s protected by the same people who carry the roadmap: EMs and tech leads who know that velocity today means very little if the engine seizes tomorrow.

Putting it all together

Here’s the punchline.

You don’t solve technical debt by stopping. You solve it by embedding its maintenance into the rhythm of the org. Debt lives in the sprint. It’s tracked like any other work. It’s tackled opportunistically and systematically. And it’s everyone’s job — not a ticket, not a team, not a quarterly offsite.

The beauty of this approach is that it scales. As your team grows, new engineers adopt the habits they see modeled. Leaders prioritize work that enables the next layer of speed. And your codebase — imperfect but healthy — remains a place where people can move fast without fear.

In a hypergrowth startup, you’ll never have zero technical debt. But you can keep it low, visible, and shrinking. And that, more than any perfect abstraction, is what keeps the machine running.

To dive deeper into the principles and practices behind managing technical debt—especially in fast-paced, high-growth environments—here’s a curated list of standout articles and engineering blogs that have shaped our thinking; they offer firsthand insights, frameworks, and field-tested strategies from teams who’ve lived through the same scaling challenges.

Alex Ewerlöf Notes

We invested 10% to pay back tech debt; Here's what happened

Anyone who has maintained software for a while knows that it tends to rot over time. It takes deliberate effort to prevent that from happening. In this post I will tell a story about how one team successfully dealt with it and conclude with some practical tips…

Read more

3 years ago · 51 likes · 2 comments · Alex Ewerlöf

• Martin Fowler – Technical Debt Quadrant

• Kelly Sutton – Managing Technical Debt Like a Financial Portfolio

• InfoQ – Netflix's Tech Debt Reduction Strategies

• Netflix Tech Blog – Freedom & Responsibility

• Stripe – Refactoring at Scale

• The Debt Trap: How Tech Debt Sabotages Innovation

• The Pragmatic Engineer – Tech Debt and the Pragmatic Middle Ground

• Atlassian – What is Tech Debt? Signs & How to Effectively Manage It

• Thoughtworks – Identify, Manage and Overcome: A Guide to Technical Debt

• Code Climate – Our 10-Point Technical Debt Assessment

Subscribe now

In the first experiment, I tested whether LLMs could act as code reviewers, asking them to define a rubric for high-quality code and then critique a given implementation based on their own criteria. Some models excelled at structured feedback, others were too vague, and a few lacked the depth we expect from a seasoned software engineer.

Now, I’m flipping the test. Instead of just reviewing code, the LLMs have to write the code themselves.

The challenge? Implement a prefix calculator in Go.

Each LLM was given the same prompt and asked to generate a function that correctly evaluates a prefix notation expression—a classic problem in computer science. Then, all five implementations were compiled and fed back to the LLMs, asking them to rank the five versions from best to worst based on the code review criteria they created in the first experiment.

This setup created a double-layered challenge:

1. How well can each LLM write structured, correct, and maintainable code?

2. Can the LLMs objectively evaluate their competitors’ work? Or will they show bias toward their own implementations?

The results? Some clear winners, some biased reviewers, and some models that were more self-critical than expected.

Breaking down the rankings

After compiling all the rankings, I calculated the average score each LLM received. The lower the score, the better that model performed in the eyes of its peers.

The rankings alone don’t tell the full story. The feedback each model provided about its competitors offers an even more insightful look into how LLMs evaluate code. Here’s a snapshot of some of the feedback each LLM provided to the 5 version of th prefix calculator implementation

1. Claude 3.7 ⭐⭐⭐⭐⭐ (5/5)

   • Modular and Extensible: Uses a PrefixCalculator struct with separate methods for tokenization and evaluation, making it highly maintainable and scalable. Best support for multi-digit numbers, structured design with a tokenizer, excellent error handling, modular and maintainable.

   • Error Handling: Thoroughly handles invalid inputs, division by zero, and malformed expressions.

   • Readability: Well-structured code with clear separation of concerns and meaningful method names.

   • Recursive approach may cause stack overflow in deep expressions, slightly more complex than others.

2. Gemini Advanced ⭐⭐⭐⭐½ (4.5/5)

   • Stack-Based Approach: Uses a stack to evaluate the prefix expression, which is efficient and easy to understand.

   • Error Handling: Covers basic errors like insufficient operands and division by zero.

   • Readability: Code is straightforward but lacks the modularity and extensibility of the top two. Uses helper functions, efficient stack-based approach.

3. ChatGPT (Ranked 3rd) ⭐⭐⭐ (3/5)

   • Stack-Based Approach: Uses a stack to evaluate the prefix expression, which is efficient and easy to understand.

   • Lacks modularity, no separate token validation functions

4. DeepSeek (Ranked 4th) ⭐⭐⭐ (3/5)

   • Recursive Approach: Uses recursion to evaluate the prefix expression, which is elegant and easy to understand.

   • Error Handling: Catches edge cases like division by zero, invalid tokens, and malformed expressions.

   • Readability: Code is clean and well-organized, with helper functions for clarity.

5. LLaMA 3.0 (Ranked 5th) ⭐⭐ (2/5)

   • Basic Implementation: Uses a stack-based approach but lacks modularity and thorough error handling.

   • Readability: Code is simple but less structured compared to the top three.

   • Error Handling: Handles division by zero and invalid tokens but misses some edge cases.

These rankings align with my own analysis, which found Claude’s implementation to be the most structured and maintainable, while LLaMA’s code lacked robustness in several areas.

Did LLMs overrate themselves?

One of the most revealing aspects of this experiment was whether LLMs were biased toward their own code. The short answer? Yes, some were.

DeepSeek, for example, rated its own implementation second, which isn’t unreasonable—but other models placed it lower due to its inconsistent style and recursion-heavy approach. Meanwhile, Claude’s self-ranking closely matched the peer rankings, suggesting a more objective evaluation.

This indicates that some models are better code reviewers than they are code generators—and vice versa.

Did LLMs hallucinate?

No, not exactly, but some provided in accurate feedback including to their own code. For example, ChatGPT incorrectly flagged its own implementation (and others) as lacking the ability to handle multi-digit numbers, which is incorrect. I had to prompt the LLM to point it to this error

Key takeaways

1. Last week we learned that DeepSeek was the preferred LLMs for code reviewing tasks, based on an evaluation by its peer LLMs. The survey I sent out also validated this outcome. Humans and LLMs prefer DeepSeek to review their code :)

   

2. Claude 3.7 Sonnet is the best overall performer, both in writing and evaluating code. If you’re looking for an LLM to assist with maintainable, high-quality engineering work, it’s the top choice.

3. Not all LLMs judge their own work fairly. Some models overrated their own implementations, while others were more even-handed.

4. Trust yet verify LLMs; they can still hallucinate or give incorrect recommendations.

Subscribe now

A year ago, GitHub Copilot was the best AI-powered assistant a developer could get. It felt like magic at first—code autocomplete that worked well enough to be useful, even if it had a tendency to hallucinate, get stuck in repetitive loops, and misunderstand broader context. It was helpful, but it was never quite enough. You could feel the ceiling on its capabilities, and in fact, that is reflected with our experience at StrongDM, using Github Copilot about one year ago.

Fast forward to today, and Copilot feels almost primitive compared to the latest wave of AI coding tools. The field has evolved at an astonishing pace. LLMs are no longer just glorified autocomplete—they’re becoming fully-fledged engineering collaborators. Take Cursor, for example. Instead of just completing code, Cursor acts as an agent, iterating, debugging, and even proposing refactors in a way that actually feels context-aware. And it’s not alone. LLMs today are being fine-tuned for specific coding tasks, trained on massive repositories of open-source software, and integrated directly into development workflows with a level of fluidity that wasn’t possible a year ago.

t’s clear that autocomplete isn’t the future—agency is, I think. The real power of modern LLMs isn’t just in suggesting the next token; it’s in their ability to step back, analyze, and provide meaningful feedback. And that’s what we’re here to test today.

The real test: Can LLMs code review like a senior engineer?

If LLMs are going to be real engineering assistants, they need to do more than just fill in blanks. They need to think. They need to critique, refine, and evaluate code in the way a strong human engineer would. So today, we’re running an experiment.

We’re going to pit five of the best LLMs against each other—not to see which one writes the best code, but to see which one thinks the best.

The challenge is simple but revealing: Who is the best AI code reviewer?

To find out, I designed a two-part test. First, we asked each LLM to define what makes a good code review—essentially, to generate a rubric for evaluating code quality. I selected what I thought was a thorough and decent set of criteria and then moved on to the next stage of the test. The selected review criteria is shown below.

With the code review criteria defined, I fed them all the same piece of code and asked them to review it based on those criteria. The code I fed each LLM was code I very quickly put together to implement a very primitive prefix calculator. I implemented it in golang in two ways; once via recursion and another using a stack. It lacked tests, any sort of validation and didn’t support dealing with multi-digit numbers (or -ve values for that matter). Quick, dirty and hacky code.

The real twist? Each LLM was also tasked with ranking the others' reviews, including its own. The contenders in this battle:

• ChatGPT 4o (OpenAI)

• DeepSeek

• LLaMA 3.0 (Meta)

• Gemini Advanced 2.0 (Google)

• Claude 3.7 Sonnet (Anthropic)

Each of these models has its own strengths. Some are optimized for reasoning, others for speed, others for sheer volume of training data. But which one actually feels like a competent senior engineer when reviewing code?

The ranking per LLM is shown in the table below. Each model rated itself and the other 4, across a 1-5 rating, where 1 is best and 5 is worst. The diagonal cells show each model’s self-assessment. The average row is simply an average ranking of the model across its own rating and that of its peers.

A few observations from the above:

• DeepSeek and ChatGPT seem to be universally (scoped to a universe of 5 LLMs) regarded as better than the other 3 LLMs in this task. Side observations, DeepSeek’s output at times was eerily similar to ChatGPTs 🤔

• Gemini has an inflated self-worth? It rated itself highest, yet the best it got from its peers was an average rating.

• Gemini also seems to be polar opposite to its peers. It rated both DeepSeek and ChatGPT the lowest at performing this task whilst its peers tended to rate those two highest

• Llama is not particularly good at this task. But at least it's aware of that limitation - see its own self-assessment 😊

Obviously all the models were able to point out the very many flaws in my code from the obvious ones to some more subtle ones. The difference, at least to me when reading them, was more stylistic and tone vs actual content. Some models excelled at summarizing and providing actionable feedback in the form of recommendations. Oftentimes those would be in priority order too. I also found that the LLM ranking was aligned with how I ranked these models too. I preferred DeepSeek and ChatGPT over the rest.

In summary, do I believe that this generation of LLMs can craft code review best practices and also help (human) software engineers with code reviews? Yes and yes.

Lastly, I shared all the model outputs for both review criteria and each model’s CR for my input code on Github here. I also have a very short survey to get human input on which models is the best for CRs. The models have been anonymized in my survey. Please take a minute to fill it out.

I will share the responses in my next post, which will cover another LLM battle: which one is better at writing code.

Subscribe now

One of the most common challenges engineering leaders face as their organization grows is creating a clear, fair, and scalable career ladder. When your team is small, career progression often happens organically. Engineers take on more responsibility, and their impact naturally grows over time. But as your team scales, the absence of a formal structure can lead to confusion, misaligned expectations, and even attrition.

An effective career ladder not only provides clarity for your engineers but also serves as a powerful tool for retaining top talent, fostering growth, and aligning individual contributions with business objectives. To build a career ladder that truly works, it must align with the culture you are trying to create or maintain.

Aligning Career Principles with Culture

Let’s start by discussing why alignment with culture is so essential. Imagine your culture places a strong emphasis on empowering decision-making at both the individual and team level. To uphold that, your career ladder must reward behaviors that reflect autonomy, ownership and initiative. Engineers who proactively lead projects or experiment with new ideas should see those efforts recognized and rewarded. Similarly, if collaboration is a core value, then your ladder must elevate those who contribute to team success, mentor others, and create environments where everyone thrives. The more clearly your career development framework reflects your cultural values, the easier it becomes to scale that culture as your team grows.

Crowdsourcing levels and titles

Designing a career ladder can feel particularly challenging if your organization doesn’t have established levels or titles. Here’s where a collaborative approach can make all the difference. I’ve found that crowdsourcing levels and titles is a method that not only aligns with a culture of empowerment but also generates invaluable insights. Begin by gathering your team to brainstorm the distinctions between roles. What separates a “Senior Engineer” from a “Staff Engineer”? What outcomes and behaviors define success at different stages? Encourage broad participation through workshops or surveys, ensuring diverse perspectives are included. This input not only makes the framework more comprehensive but also fosters a sense of ownership among your team.

Once you’ve identified the levels and their accompanying competencies, the next step is to incorporate peer input into the process. Self-leveling, where engineers and their peers evaluate one another against the defined criteria, often yields more accurate and equitable results than decisions made solely by managers. Peers who work closely together can provide nuanced feedback that managers may not see from their vantage point. This approach also reinforces transparency and trust, as it’s clear how evaluations are conducted and decisions are made.

As your framework takes shape, you’ll need to define separate tracks for individual contributors and managers. This distinction allows engineers to pursue growth paths aligned with their interests and strengths. Individual contributors can advance by deepening their technical expertise, driving large-scale initiatives, and mentoring others. Meanwhile, managers grow by developing their teams, fostering alignment with company goals, and ensuring their engineers are supported in their work. These tracks are equally valuable, and your career ladder should make that clear.

Clarity is key when defining levels. Each level should articulate its scope of impact, technical expectations, and leadership requirements. For instance, a “Senior Engineer” might focus on delivering high-quality code and mentoring junior team members, while a “Staff Engineer” leads the technical design for cross-functional projects and drives strategic initiatives. Observable behaviors—such as “mentors peers” or “leads incident post-mortems”—help ground these descriptions in reality, making them more actionable for everyone involved.

Equally important is making your career ladder accessible. Engineers should know exactly what is expected of them at their current level and what they need to do to advance. Publish the framework in a central location, and make it part of ongoing conversations. Regular workshops or one-on-one discussions can demystify the process further, ensuring everyone feels empowered to take ownership of their growth.

Avoiding common pitfalls

When designing a career ladder, it’s important to avoid common pitfalls that can undermine its effectiveness:

• Overemphasizing tenure instead of impact, leading to promotions based on time served rather than contributions.

• Leaving criteria too vague, which creates confusion and frustration among engineers.

• Neglecting growth paths for individual contributors, making it seem like management is the only route to advancement.

• Providing inequitable access to opportunities, which can leave some engineers feeling excluded based on team or project assignments.

• Divergent compensation between individual contributors and managers, which can devalue one track over the other. Both tracks should offer equitable compensation for equivalent levels of responsibility and impact.

  ---

Creating a career ladder isn’t a one-and-done task. It requires regular calibration to ensure fairness and consistency across teams. Managers need to be trained not only in using the framework but also in providing actionable feedback that aligns with it. Calibration meetings, where leaders review and discuss promotion decisions together, help ensure standards are applied evenly. Revisiting the framework annually allows you to adapt it as your organization evolves.

Supporting your engineers goes beyond defining a ladder. Mentorship programs, stretch assignments, and access to training resources all play a crucial role in helping individuals succeed at their current level while preparing for the next. Career growth isn’t just about promotions; it’s about providing opportunities to build skills, expand influence, and deepen impact.

A well-designed career ladder is more than a tool—it’s a reflection of your commitment to your team’s growth and success. By aligning it with your culture, crowdsourcing input, and fostering transparency, you’ll create a framework that not only helps your engineers thrive but also strengthens your organization as a whole. As your company grows, so will your career ladder. Iteration and feedback will ensure it remains a living document, one that evolves alongside your team.

Subscribe now

AI-powered code completion tools like Github Copilot, Tabnine, Amazon Q, cursor and codeium have been all the rage over the past year or so. The promise of an all powerful AI that can augment or entirely replace a human software developer is partly behind this immense appeal and promise of these tools. On its most recent earnings call, Google, announced that 25% of its code was generated by AI tools like GitHub Copilot 🤔

“Today, more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers." Sundar Pichai

Yet amidst all of this excitement and promise of an all-mighty AI that can write software products on its own, Microsoft dropped this bit of news:

Now automatically integrated into VS Code, all of you have access to 2,000 code completions and 50 chat messages per month, simply by signing in with your personal GitHub account. Or by creating a new one. And just last week, we passed the mark of 150M developers on GitHub. 🎉

Copilot Free gives you the choice between Anthropic’s Claude 3.5 Sonnet or OpenAI’s GPT-4o model. You can ask a coding question, explain existing code, or have it find a bug. You can execute edits across multiple files. And you can access Copilot’s third-party agents or build your own extension.

Source: GitHub

This decision raises a compelling question: why would Microsoft give away such a powerful tool for free?

GitHub monetization

GitHub's monetization relies fundamentally on its core function: storing source code. As the world’s leading source version control platform, GitHub underpins a variety of revenue-generating products and services designed to cater to individual developers, teams, and enterprises. Its pricing structure includes tiers like the free plan for basic users, GitHub Pro for enhanced personal productivity, GitHub Team for collaborative work with advanced features, and GitHub Enterprise for large-scale organizations needing enterprise-grade security, compliance, and scalability. These offerings are complemented by add-ons like GitHub Codespaces, a cloud-based development environment, and GitHub Advanced Security, which provides tools for vulnerability detection, code scanning, and secret management. Additionally, GitHub is not just a standalone platform; it is a gateway to Microsoft’s developer tools and other services available through Microsoft Azure.

To repeat, the foundation of Github’s monetization model is storing source code files. Said otherwise, if source code files start migrating away to other platforms, GitHub’s entire ecosystem of products and services—and their associated revenue streams—face potential erosion.

The strategic paradox: Why free?

Microsoft’s decision to offer GitHub Copilot for free can be explained by two seemingly contradictory rationales. On one end of the spectrum the decision was sparked because of Copilot’s immense value and on the opposite end for the exact opposite, its complete lack of value. Both perspectives ultimately align with a single goal: protecting and enhancing GitHub as a base platform.

Reason 1: Copilot is immeasurably valuable

Copilot’s ability to drastically improve developer productivity is its greatest strength—and, paradoxically, a potential threat to GitHub’s core business. As Copilot grows in popularity, the risk emerges that developers might value Copilot more than the platform it runs on. If AI code completion tools like Copilot become the primary driver of developer engagement, developers could shift allegiance to other ecosystems offering similar, or better code-completion capabilities capabilities. In this scenario, the platform (GitHub) risks becoming a secondary consideration.

In this scenario the primary motivation for storing source code is no longer the core of what GitHub offers: a source version control system, but instead it becomes AI code-completion. Products that offer better AI code-completion capabilities relative to GitHub Copilot can therefore erode all of Github’s business.

By offering Copilot for free, Microsoft is protecting itself from such a situation. It set the price of AI code-completion products to $0. All the emerging competitors, with far fewer resources than Microsoft will struggle to compete against a free product.

Reason 2: Copilot offers little value

On the flip side, Microsoft may have recognized that code completion tools - as a category - offer limited value to end software developers. By acknowledging this, Microsoft acted to protect against the potential defection of its developer base to try alternative platforms that might offer better AI-powered tools. This preemptive move reduces the incentive to try other AI code completion tools and migrate source code en masse. Why bother try if all products offer no to little value and developers already have one for free from GitHub?

I had earlier published empirical data from our (StrongDM’s) own usage of GitHub Copilot which showed little to no value. Perhaps this sentiment is felt broadly amongst other software developers, leading Microsoft to just offer it for free vs monetizing it at all.

Regardless of the motivations, in this scenario too, Microsoft is effectively commoditizing the market. In doing so, it reduces the incentive for developers to switch platforms in search of better AI tools. After all, if GitHub already offers an AI assistant at no cost, there’s little reason to explore alternatives. This strategy protects GitHub’s position as the dominant platform for developers and ensures that the value proposition of competitors remains limited.

In both scenarios, the underlying strategy is clear: Microsoft is commoditizing Copilot, and subsequently a very popular developer category to safeguard GitHub’s position as the world’s leading developer platform. By keeping developers firmly rooted in GitHub’s ecosystem, Microsoft strengthens its ability to cross-sell other offerings, from cloud hosting to advanced analytics, not to mention protecting GitHub’s own revenue streams. Masterstroke.