Most discussions of AI in the workplace assume a baseline of work that was already going to happen. The question asked is how much faster, how much cheaper, how much more accurate, metrics that measure acceleration along an existing axis. The framing is useful, but it captures only one half of what is actually changing. The other half, which is harder to measure and rarely discussed in those terms, is what happens at the edges: the work that was not going to occur at all, because the people close enough to see the need did not have the means to produce it.
This second shift is the more consequential one, because it changes not the speed of existing work but the boundary of what a single person inside an organisation can now be responsible for producing. I want to examine it through a specific case, one I have observed from the inside, at Naboo, the company where I work, because the pattern is sharper when looked at in detail than when described in the abstract. The case is not exceptional; it is becoming ordinary. That is precisely what makes it worth examining.
The application
Since October of last year, an internal application I built has gradually been adopted across most of the teams at the company. It is used for the marketing dashboard the acquisition team relies on, for sales forecasting, deal attribution, supply coordination, event operations, finance, and more recently for some of the onboarding and recruitment workflows run by HR. The project began as something I was working on alongside my existing responsibilities; over time, as more teams started relying on it, it became the work itself. None of this was planned as a system. It grew one feature at a time.
A year ago I could not have written any of it. I had always been interested in software and had built small sites over the years, but nothing that could carry operational load. What changed was access to code generation tools, first Cursor, which made the existing motions of writing code more approachable, and later Claude Code, which shifted the interaction toward something more conversational and more structural. Without either, I would not have written a faster version of this application. I would not have written a smaller one. I would not have started. The project does not belong to a category of work that was accelerated. It belongs to a category of work that was, from my position, previously impossible.
The moment it stopped being a side exploration was the marketing dashboard. Before that, what I was building looked like an experiment. A few pages, some data pulled from various tools, nothing anyone depended on. The dashboard consolidated the company's acquisition budgets and performance across channels, and from that point forward, decisions about how to allocate real money started flowing through something I had written. The object had not changed category overnight, it was still the same codebase, but its function had. What followed was not the result of a plan. Other teams saw the dashboard and began asking whether their own workflows could live in the same place. Each addition was incremental. The cumulative effect was not.
From tool adoption to workflow emergence
The dominant frame for studying AI in the workplace is productivity measurement. The most rigorous contribution in that tradition so far is Brynjolfsson, Li and Raymond's Generative AI at Work, published in The Quarterly Journal of Economics in 2025. Studying more than five thousand customer-support agents, the authors find a fifteen percent average gain in issues resolved per hour, with the effect concentrated almost entirely on the least experienced workers facing the least familiar problems. The finding is important, and its direction is telling: what AI assistance does, in that setting, is compress the distance between someone who does not yet know how to do a task and someone who does.
This result extends naturally to the case examined here. The same asymmetry is at work. A person without prior skill, facing a problem for which no preparation existed, produced something whose existence was not in the organisation's plan. But there is a difference that matters. In the study, the task existed before the tool. The support agent was employed, the problem was defined, the metric was in place. The tool made an existing axis faster. In the case examined here, no such axis existed. There was no prior version of the application, no team assigned to build one, no budget, no plan. What the tool enabled was not faster work, it was work that was not going to happen.
This is the shift the productivity frame cannot quite capture, because its instruments measure ratios, and ratios require a denominator. Something that goes from zero to operating across several teams has no denominator. It does not appear in the spreadsheet. And so the most consequential kind of change, the kind where a capability emerges rather than accelerates, tends to pass unobserved in the very studies that are otherwise the most rigorous.
What this does not mean
None of this supports the claim that software engineering is being replaced, or that individuals can now do the work of entire teams. The application described here would not survive the scrutiny a senior engineer would apply to a customer-facing product. It works because its users are internal, because its failure modes are visible quickly, and because the cost of a mistake is a dashboard showing a wrong number for a few hours rather than a system outage affecting customers.
The point is not replacement. It is that certain categories of internal work have quietly moved within reach of a single person, in a way they were not a year ago. These tend to share a few structural features: errors are recoverable, feedback from real use is immediate, and the person who needs the tool is often the same person who could now, plausibly, build it. That last condition is the one that matters most, and the one most likely to generalise beyond software.
The question this leaves open
The pattern suggests a question I am not yet ready to answer cleanly. If individuals inside organisations can now produce the infrastructure that previously required teams, budgets, and procurement cycles, what happens to the organisational logic built around the assumption that they could not? Most companies are structured, at some level, around the idea that building anything serious requires a formal process, an owner, a budget, and a delivery timeline. When the unit cost of building collapses for a meaningful class of internal systems, some of that scaffolding becomes overhead rather than structure.
I do not think this generalises to everything, and I am suspicious of anyone who says it does. But I think it generalises to more than most organisations currently recognise. The interesting work, both analytically and practically, lies in figuring out where the line sits, which categories of internal work are now within reach of an individual, and which are not, and why.
That is the question I want to return to.