Context is the New Code

I’m a Head of Product. I don’t write production code. And in the last twelve months, I’ve built more working software than most engineers.

I built an AI deal desk where agents are given the actual identities of real executives, trained on their decision-making patterns, red lines, and tradeoff hierarchies, so sales reps can get directional guidance before formal review. I built a shared context layer designed so that what a collections agent learns about a customer compounds into smarter forecasting and deal-desk decisions downstream. I built the architecture for a multi-agent AR automation system that’s now in production. None of that required an engineering background. It required knowing the domain cold.

What happened to me is about to happen to a lot of people, and most organizations aren’t ready for what it means.

The Bottleneck Just Moved

For decades, software development required a translation layer. The domain expert would articulate what they wanted. An engineer would translate that into how to build it. The gap between intent and implementation was where time, cost, and fidelity were lost. Sprints, tickets, handoffs, backlog grooming, specs written for an audience that didn’t fully understand the problem, revised by people who understood the problem but not the system. A whole organizational apparatus existed to manage that translation.

AI just made it unnecessary.

Klarna’s CEO Sebastian Siemiatkowski said it plainly in February: during the first two years of Klarna’s AI strategy, they focused on hiring engineers. “That has switched, actually. It’s almost the opposite.” The business knowledge of non-coders who can use AI to code but also know what kind of dashboards or features are actually needed is increasingly valuable. “The engineers, they’re like, ‘okay, I coded this feature. What do I do next?’”

Knowing what to build next has always been a domain problem, not a technical one. AI just made it the only problem that matters.

What This Looks Like in Practice

Stripe built “Minions,” fully autonomous coding agents that now ship over 1,300 pull requests per week with no human writing a single line of code. What’s notable isn’t the volume. It’s who’s using them. Non-engineers at Stripe are starting to use Minions to ship code. The activation mechanism is a Slack message, written in plain language, describing what needs to happen. The agent reads the thread, pulls the context, and delivers a finished pull request. The person closest to the problem initiates the work. The person with the domain knowledge is now also the person shipping.

A product team profiled in VentureBeat recently described the same inflection. One of their product managers built and shipped a feature, not spec’d it, not filed a ticket, built it and shipped it to production, in a day. Their designer noticed UI drift, opened an agent, adjusted the layout directly, and pushed the fix. No ticket. No sprint slot. No translation. Their observation afterward: “All the coordination mechanisms we’d built to protect engineering time were now the slowest part of the system. We were optimizing for a constraint that no longer existed.”

At Duolingo, the chess lessons product started as a rapid prototyping experiment by a designer and a product manager, not an engineering initiative. The people with pedagogical expertise originated and built the product, without filing a single ticket.

Shopify’s Tobi Lütke coined the term “context engineering” to describe the fundamental skill AI requires: the ability to state a problem with enough context that, without any additional information, the task becomes plausibly solvable. Context engineering is not a technical skill. It’s a domain skill. The person who understands accounts receivable deeply enough to specify the edge cases, the exceptions, the relationship dynamics, the escalation logic, is better at context engineering than an engineer who doesn’t. Domain expertise was always the scarce input. AI just revealed it.

The Org Chart Nobody Drew

Here is the uncomfortable implication for software companies and finance organizations alike: the processes built to manage the translation layer are now overhead.

Specs exist to communicate intent across a knowledge gap. When the person with the intent can act on it directly, the spec is redundant. Ticket systems exist to queue work for a constrained resource. When implementation capacity is no longer the constraint, the queue is the problem, not the solution. And handoffs exist because different people hold different pieces of the work, when one person can hold all of it, the handoff is pure latency.

This does not mean engineers disappear. It means the value of engineering shifts. The Stripe Minions architecture is instructive: what made it work wasn’t a better AI model, it was the infrastructure built around the model. The isolation, the sandboxing, the blueprint system, the curated tool access. Engineers built the harness. Domain experts pull the lever. The compounding happens when those two things work together without a translation layer between them.

Engineering teams that try to control this aren’t protecting quality. They’re protecting relevance. There’s a difference. When a PM ships a feature in a day and the engineering response is a new review gate, a merge policy, or a fresh category of ticket, the team has revealed what it’s actually optimizing for. Not speed. Not outcomes. Not the organization’s ability to move. Its own position in the chain of custody. The irony is that this accelerates the very thing they’re trying to prevent. The organizations that route around resistant engineering teams won’t be competitors, they’ll be the domain experts already inside the building, quietly learning to ship without asking permission.

What I Know from Building It

The thing I keep noticing, having spent the last year building agent systems from the product side, is that the hardest problems were never technical. They were domain problems dressed up as technical ones. What should the collections agent do when a high-value customer goes silent? That’s not an engineering question. What context does the deal desk agent need to reason about margin tradeoffs the way a specific executive actually does? Not an engineering question. How should the context layer handle the difference between real-time transaction data and slower-moving policy data without poisoning one with the other? That’s an architecture question, but the answer comes from understanding the business process, not the tech stack.

The people who can answer those questions are not the constraint anymore. The organizations that haven’t figured that out yet are.

The people I’ve found hardest to work with in building these systems are engineers who want to solve the technical problem before understanding the domain problem. The people I’ve found most valuable are the ones who can hold both, whether their title is engineer or product manager or operations lead.

Twenty-five percent of Y Combinator’s last cohort shipped codebases that were 95% AI-generated. Forrester found that 87% of enterprise developers now use low-code platforms for at least part of their work. The prediction era is over. This is just happening. The more interesting question is what “software development” even means when the bottleneck is knowing what to build rather than knowing how to build it.

The engineering layer that justified the org chart, the tickets, the sprints, the specs, the handoffs, is collapsing. The organizations that redesign around this will look radically different from the ones that treat it as a productivity enhancement to the existing process.

The constraint has moved. Most organizations are still optimizing for one that no longer exists.