One operator, a fleet of agents

The MIT Project NANDA report of July 2025 handed the world the number 95 percent and dropped a far more interesting sentence on the way. In more than 90 percent of the firms surveyed, employees reported regularly using personal AI tools for work, although only about 40 percent of firms said they had bought an official language-model subscription. Access to the same models therefore lies on both sides of the line between success and failure. My claim is that the edge of a one-person operator with a fleet of agents grows out of something nobody invoices: the internal layer of coordination between employees drops away there. So more of the leverage goes into the output than in an organization. The decision that hangs on this is yours, and it is uncomfortable — hire the next person, or buy the next degree of autonomy for the agent you already have.

The number that changed its unit inside the report itself

The MIT Project NANDA team published The GenAI Divide: State of AI in Business 2025 in July 2025 (Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari). It rests on a review of more than 300 publicly disclosed AI initiatives. To that were added interviews with representatives of 52 organizations and survey responses from 153 senior leaders, collected at four industry conferences; the research period was January to June 2025. The authors call their findings preliminary and caution that the six-month observation period may understate success rates for longer-term implementations. In one paragraph of its summary the report says that 95 percent of organizations are getting zero return. It also says that only 5 percent of integrated pilots pull millions in value out of AI, while the vast majority show no measurable effect on the income statement.

The first sentence is about organizations, the second about pilots.

The distinction is not pedantry. A company running twenty pilots of which one earns money lands both among the 5 percent and among the rest, so the second sentence says little about the company itself. Further on, the report attaches a 5 percent figure to enterprise tools as well as to enterprises, and does not say what sample it was derived from. It also cautions that the figures are directionally accurate and based on individual interviews rather than on official company reporting, and that sample sizes vary by category. The findings rest on interviews and self-reported answers, the report is an initiative's document and did not appear as a peer-reviewed paper, and its appendix holds questionnaires but no data.

Let us name the mechanism straight away: the unit of the number changes within one paragraph of the summary, so whoever cites it has to pick one of the two, and nobody lies along the way.

The same document holds the finding my whole claim rests on. The authors write that workers at more than 90 percent of the firms surveyed reported regularly using personal AI tools for work, and they call it the shadow AI economy. The prose speaks of firms, while the chart on the same page labels the 90 percent as employees, a different unit, so I take the firm-level wording. I treat that figure as an order of magnitude, because it comes from a survey and interviews rather than telemetry. An order of magnitude is enough. If in the overwhelming majority of surveyed firms, including those whose initiatives fail to deliver, somebody reaches privately for the same models I do, then access to those models stops explaining anything at all. This does not prove those employees work better for it. The report claims that this zone often yields a better return than official initiatives, but it shows no measurement, and picking up a tool is not yet a result or even the promise of one. In my view the barrier does not sit on the access side.

There is a third observation in that report, and it is the most sardonic of the three. The report says back-office automation often returned more, and some of its most dramatic documented savings come from replacing outsourced services and agencies. Yet in the split of a hypothetical budget that executives were asked to make, sales and marketing took about half, and in another place about 70 percent. Spending was not measured, so this tells us where executives say the money would go, not where it went. It still points one way: the report itself ties the front office's budget lead to how easily its results can be attributed and seen. Technology settled nothing here. The stated split of the budget followed the visibility of the result, and visibility is set by whoever signs that result off.

The model: coordination effort grows combinatorially

Frederick P. Brooks Jr. laid out this arithmetic in The Mythical Man-Month (Addison-Wesley, 1975), drawing on his own work on OS/360. If every part of a task has to be agreed separately with every other part, effort grows as n(n−1)/2. Four people means six channels. Ten means forty-five. Fifty means one thousand two hundred and twenty-five channels, and nobody has yet been issued a day longer than twenty-four hours. Hence Brooks's law: adding people to a late software project makes it later.

Brooks gave an analytical model and an observation from a single undertaking, not a study with a sample.

A related link between organizational structure and code quality was studied by Nachiappan Nagappan with Brendan Murphy and Victor Basili in The Influence of Organizational Structure on Software Quality (ICSE '08, Leipzig 2008). They took data from Windows Vista and asked what predicts whether a single binary fails after release. A model built on eight organizational metrics reached precision of 86.2 percent and recall of 84.0 percent. The metrics included how many engineers who touched the binary were still at the company and how many had since left it. They also covered how deep the ownership of the code ran and how many organizations each contributed more than 10 percent of the changes. That beat models built on code churn, code complexity, test coverage, dependencies, and the count of pre-release defects.

Organizational structure predicted failures better than metrics of the code itself. It is a case study of one product at one company, and a predictive correlation rather than a causal experiment, and it does not test Brooks's law about late projects. The authors themselves write that little data existed on the relationship. The direction agrees with Brooks's claim that organizational structure affects quality.

The second frame came from an economist. Ronald H. Coase asked in The Nature of the Firm (Economica, 1937) why firms exist at all, if the market supposedly allocates resources more efficiently. His answer: using the price mechanism costs something. You have to find a counterparty, negotiate terms, write the contract, enforce it. A firm comes into being to move those transactions inside and pay less for them. It grows for exactly as long as the cost of organizing one more transaction internally stays below the cost of arranging the same one on the market.

Agents lower one side of that equation, because part of the coordination between people stops being needed. A one-person firm can therefore take inside work that used to require hiring, and that is the entire economic case my one-person product studio with a fleet of agents stands on. Coase has a second half, though, which writing about AI keeps quiet: he also described the entrepreneur's diminishing efficiency as the number of transactions rises. One head has a throughput limit. An agent does not add a head. It adds hands.

The missing link I found in Nicholas Bloom, Luis Garicano, Raffaella Sadun and John Van Reenen, The Distinct Effects of Information Technology and Communication Technology on Firm Organization (Management Science 60(12), 2014). They pulled apart two things usually thrown into one bag labelled "digitalization". Information technology gives knowledge to the person at the bottom and widens their decision autonomy. Communication technology carries information upward cheaply and centralizes the decision.

That settles the argument over whether a tool by itself shortens the decision loop. It does not. It shortens the loop when the knowledge lands with the person who decides. For a one-person operator those two people are the same person by definition, so every tool works there as information technology. Inside an organization, the very same agent very often works as communication technology: it produces material for the next round of sign-off, a slide for the next review, a justification for the next budget request.

The last piece of the puzzle was supplied by Oriana Bandiera, Andrea Prat, Stephen Hansen and Raffaella Sadun in CEO Behavior and Firm Performance (Journal of Political Economy 128(4), 2020). They gathered time diaries from 1,114 CEOs across six countries and classified their behaviour without imposing categories in advance. Two types fell out. One kind sits in cross-functional and senior meetings; the other in one-on-ones with core functions. Firms of the first kind do better, except that the effect only surfaces after three years. The authors themselves put the difference down to the fit between style and firm rather than to one type being superior.

What interests me is something the authors had no reason to stress, because to them it was obvious. A chief executive's working material is the meeting. Not out of laziness. Inside an organization, coordination simply is the work, and the most expensive hour in the company goes into letting two other hours begin.

The mechanism: what an agent does not do, and what it takes in exchange

Take any task that passes through three divisions in an organization. Count what happens to it along the way.

Someone has to define the scope. Someone else has to approve it, because he carries the budget. A third person checks that the task breaches nothing she is accountable for. A fourth asks why it was not done in her team. Each of these people brings real knowledge and a real interest to the matter, and none of them is a villain. Together they produce a cost nobody books, because coordination has no line in the chart of accounts.

Now the same task at an operator with an agent. The agent does not negotiate scope. It does not defend a budget, having no budget to defend. It has no career to secure in passing, no division whose interest it represents, and no need to look busy in a quarter with nothing to ship. It takes an instruction and either delivers a result or does not. None of which means coordination inside an organization is waste, because a good share of it exists so that somebody says "no" in time, and that function an agent does not perform.

Work that decomposes into coordination inside an enterprise programme stays work for a one-person operator.

In that single sentence I see the cause of the disproportion visible in the NANDA numbers. I need no assumption that worse people work in corporations. The people there are usually better. They have better data, better infrastructure and larger token budgets than I will ever have. They also have more people who must be aligned before a decision becomes a result, and the number of possible pairs grows as n(n−1)/2.

Let us measure that loop, because without a number it stays a pretty sentence. Changing a price in my studio takes checking two things: whether the new price covers the cost to serve, and whether it breaks commitments to existing customers. An hour, sometimes two. In an organization the same decision passes through the product owner, finance, legal and communications, none of whom works on it continuously. Calendar time then runs in weeks, even where the sum of person-hours comes close to mine. The effort comes out comparable. The calendar does not come out comparable at all.

Honesty demands the other side of that ledger immediately, because it is just as mechanical. A firm does not keep those channels out of fondness for meetings. It keeps them because they buy things a single person cannot purchase at any price. Capital that lets you survive eighteen months without revenue. Distribution, meaning a list of customers you only have to call. Institutional trust, meaning that procurement at a bank will open your offer at all. And continuity: if the person running the project ends up in hospital, the project carries on.

The same property that lifts the internal layer of coordination off a one-person studio takes all four away. You cannot have one without the other, because this is a single parameter seen from two sides. Whoever does not do that arithmetic beforehand rather than afterwards is selling himself a fairy tale about freedom.

The leverage is narrowband, and the bandwidth can be measured

Both numbers go on the table, the uncomfortable one included.

Sida Peng, Eirini Kalliamvakou, Peter Cihon and Mert Demirer described a controlled experiment (The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023). The task was to write an HTTP server in JavaScript. Participants received a template repository with the task description and a code skeleton, and twelve tests decided whether the task was complete. Among those who finished, the group with an assistant was 55.8 percent faster, with a confidence interval from 21 to 89 percent. Worth recording alongside: the co-authors include employees of the company that makes the tool.

Now the second study. A METR team led by Joel Becker and Nate Rush ran a randomized experiment (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv:2507.09089, 2025). Randomization ran at the level of the task: sixteen experienced open-source developers, 246 tasks in mature repositories where they had an average of five years behind them. Before the study, the participants forecast that their time would fall by 24 percent. After it, they judged that they had worked 20 percent faster.

The measurement showed they were 19 percent slower.

The gap between self-report and measurement came to thirty-nine percentage points. The confidence interval for that slowdown reached from plus two to plus thirty-nine percent, and the sample was sixteen people drawn from one population, so this is no verdict on the industry. It is, though, the best-documented case of practitioners being wrong about their own speed while doing the work with their own hands.

The most honest move in the whole story was made by the authors themselves. In February 2026 METR published a note on changing the design of the experiment. It judged the data from the newer round, begun in August 2025, an unreliable signal, mainly because more developers did not want to take part in the study without AI. It also wrote that developers are probably more sped up now than in 2025. The raw results of that round are a change in working time of minus 18 percent for those of the original developers who took part in the newer round and minus 4 percent for newly recruited ones. Minus means a shorter time here, and in both cases the intervals cross zero. The authors called it very weak evidence for how much the speed-up has grown since 2025. In addition, between 30 and 50 percent of surveyed developers admitted to not submitting some tasks, unwilling to do them without AI. So tasks with a high expected gain are missing, and the note treats these estimates as probably understating the effect.

The two studies differ in nearly everything at once. The 2022 Copilot study used the Codex model, and 95 freelancers from Upwork did one standard task from a ready template, and 35 completed it. The 2025 METR study mostly used Cursor Pro with Claude 3.5 and 3.7 Sonnet, and sixteen experienced maintainers of large repositories did 246 tasks of their own. The model, the tool, the participants, the task, the measure and the year all differ, so the comparison alone cannot say what flipped the sign. METR suspects familiarity with the repository and its size. It calls that evidence suggestive but uncertain. I have a hypothesis of my own, though nothing here proves it: the class of task may have changed the sign. Fresh and verifiable work differs from work embedded in a mature system with scattered context, where the experienced developer simply knows better. So before you count your leverage, name the class of task you are measuring.

How to build a fleet

A fleet of agents does not reduce to a count of subscriptions. What decides it is the split between tasks you release without looking and tasks you check before every use. The rest you do not hand over at all.

In practice my fleet looks simpler than the word suggests. A few parallel sessions, each with its own scope and its own rules file, none of them aware of the others. That is deliberate. The moment two agents have to agree with each other about a shared context, I am back inside Brooks's arithmetic, only paid in tokens and in my own time spent reconciling contradictory output. So I split the work along boundaries that are separable anyway: a separate repository, or a separate document.

The numerical footing comes from METR's measurements in Measuring AI Ability to Complete Long Software Tasks (arXiv:2503.14499, 2025). The metric is called the task horizon: the longest task a model finishes with fifty-percent reliability, measured in the time it takes a human expert. The horizon has doubled roughly every seven months since 2019. For a model from early 2025 it stood at around fifty minutes.

The number that actually drives the decision about autonomy is a different one. The horizon at eighty percent reliability is about five times shorter — for that same model we are talking about ten minutes or so. In a note on limitations from January 2026 the authors supply the rest. The error bars typically stretch by a factor of two in each direction, horizons differ by orders of magnitude between domains, and tasks that are critical for reliability and poorly verifiable demand success rates above 98 percent. Doubling the horizon does not double the degree of automation, because failures on longer tasks are more tangled and cost more human work to repair.

Autonomy, then, does not scale with the power of the model. It scales with the reliability the class of task demands — and that class is set by you, not by your vendor.

Out of this comes the delegation criterion that replaced every earlier heuristic I used. Reversibility times verifiability. The question is not whether the model can manage it, but what the rollback costs if it cannot, and whether I will even notice. Graduated autonomy and the mechanics of demoting an agent that has started to get things wrong I wrote out separately in agent demotions; here I leave the decision skeleton alone.

The criterion for taking a task back off an agent is shorter than the table. If verifying the output costs you more than doing the work yourself, take it back. Do that thing with your own hands. It is the same trap the experienced developers fell into in the METR study: they were given help with execution and paid for it, among other things, in time spent checking. The bill went unnoticed. The rule runs in the other direction too, and there it is more pleasant. Where verification is cheap and immediate, the fleet gives the most.

That leaves verification, the place where a one-person studio lies to itself most often. The operator is a poor sensor of his own speed; the thirty-nine-point gap at METR showed as much. He is a poor sensor of his own quality as well. Veracode, in its 2025 GenAI Code Security Report, put more than a hundred models through eighty programming tasks in four languages. The result: 45 percent of code samples introduced a vulnerability from the OWASP Top 10, the canon of the most common security defects in web applications. Java came out worst, failing in 72 percent of cases. Cross-site scripting — the injection of someone else's script into a page — was left unguarded in 86 percent of the relevant samples. This is a benchmark from a company that sells code scanners, so it has an interest in a result of that shape; the methodology is public, though, and the direction matches what I see in practice.

Hence the rule I do not negotiate with myself: I judge the output. I take no interest in whether the agent "sounded confident" or how many steps of reasoning it displayed. I take an interest in a green test, a diff I have read, a number I have checked, and a security scan that passed. Why measurement beats ceremony I took apart in governance without theatre, so the operational conclusion is enough here: a gate you cannot fail is not a gate.

My own rule is owed two caveats. First, verifying the output works only where the output takes a form that can be checked in finite time, and a large part of what people call strategy takes no such form. There the fleet is useless. Second, judging the output alone is enough only where an error can be undone after the fact. If during the work the agent can expose data or take an irreversible step, judging the output comes too late, so the row of the table applies in which the agent prepares and I execute.

Finally, the thing I never hand to an agent. That list I did not have to invent, because the legislator wrote it for high-risk systems. Article 14 of Regulation (EU) 2024/1689 on artificial intelligence requires such a system to be designed for oversight by natural persons. Those assigned that oversight must be able, as appropriate and proportionate, to understand the system and stay aware of a possible tendency to rely automatically on its output. To the same extent they must also be able to interpret that output correctly. To the same extent they must be able to decide not to use the system or to reverse its output, and also to stop it. The requirements for high-risk systems will apply from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), after a postponement in 2026. Not every agent is such a system. I therefore treat the provision as a pattern of reasoning and derive no obligation of my own from it. Oversight there is assigned to natural persons. No procedure and no second agent takes that role over.

The ceiling, concentration risk, and the falsification condition

Start with the distribution my claim does not describe. The US Census Bureau reported in May 2025 that in reference year 2022 there were 29.8 million businesses without paid employees in the United States, with combined receipts of 1.7 trillion dollars. That is an average of about 58 thousand dollars per firm per year, calculated from the unrounded data. In the Census Bureau's combined count of firms with and without employees for the same year there were 35.7 million firms and 51.7 trillion in receipts. Firms without paid employees are therefore about 83 percent of firms and produce about 3.3 percent of revenue.

In 2022 five in six American firms had no paid employees. Together they did one thirtieth of the turnover.

The one-person model scales in count, not in volume. In these tables the Census Bureau gives no median for receipts, but its size classes show that about 61 percent of such firms took in under 25 thousand dollars and about 38 percent under 10 thousand. Some 87 percent are sole proprietorships, and the rest are partnerships and corporations. A firm without paid employees is therefore not always one person. Census adds that the business need not be the owner's main income. The typical member of this group is not a product studio with a fleet of agents. This essay describes the upper tail of the distribution and has to say so outright, or it becomes a winner's story about himself.

The second ceiling comes from regulation. Regulation (EU) 2022/2554, known as DORA, has applied since 17 January 2025. Articles 28–29 oblige a financial entity to assess, before signing a contract for information and communication technology services, whether it reinforces concentration risk. For services supporting critical or important functions, the entity must also assess whether the provider can be easily replaced. Added to that come a register of all contracts concluded and, for such services, exit strategies. The regulation does not exclude a one-person provider. The assessment of substitutability applies to that provider too, though, and my interpretation, which the provision does not contain, goes further: a provider who is one person is an obvious risk factor in that assessment. In parts of the market continuity is the product, so being one person may decide the outcome of a procurement conversation.

Article 14 of the artificial intelligence regulation, which a moment ago handed me the list of things never delegated to an agent, cuts the other way here. It does so if the studio is a provider or deployer of a high-risk system. Duties of oversight (Arts. 14 and 26) and documentation (Art. 11, among others) are then a fixed cost. A fixed cost is regressive with respect to size: a corporation spreads it across a department, while a one-person studio pays it out of the same day it is supposed to make the product in. The more regulation enters my class of task, the narrower the band in which I hold an advantage grows.

The third objection is technical and concerns the fleet itself. Anthropic described in June 2025 how it built a multi-agent research system: an arrangement with a lead model and subagents beat a single agent by 90.2 percent on an internal evaluation. The bill for that is stated openly in the same text. Agents burn around four times the tokens of an ordinary conversation, and multi-agent systems around fifteen times. The authors also point to the class of task where parallelization does damage: anywhere all the agents need the same context, or the dependencies between them are dense, one agent with a long context beats five.

Brooks's arithmetic does not vanish in the move to agents. It comes back as an invoice for tokens.

The difference against an organization is real, but it has to be named precisely. In my case the coordination cost is monetary and settled the same day, because I watch it on the bill for the programming interface. In an organization it is temporal and political, and the accounts never see it. That is a difference of kind and of visibility, and coordinating with agents still costs something.

The hardest objection concerns my own head. A one-person decision loop is fast and has no defence against the error of a single person. In an organization, objection is at times the only quality gate that works, even when the motive behind it is political — bad intent can still catch a hole in the reasoning. Nobody objects at my place, because there is nobody to. I substitute three things for that objection, and I know of each one that it is weaker than a live opponent. A measurement gate returns a number independent of me. An agent launched purely in the role of opponent gets the finished material and is told to break it. An irreversible move I do not make on the day I thought of it. Anyone who claims that set is a full equivalent of a team is lying.

The last objection strikes at the genre of this text itself, and I cannot rebut it. Manifestos are written by the ones it worked out for. Had my studio folded last year, you would not be reading an essay about what dropping the internal layer of coordination buys, but one about why being a company of one is a trap. That second essay would have equally good sources, because the material for both claims lies in the same studies you have just read. Survivorship bias cannot be removed by better writing. It can be named, together with the condition by which you will recognize that the author was wrong.

And so I close the manifesto with a condition that lets me be wrong in a checkable way. The claim falls if, within twelve months, a team inside an enterprise programme delivers — in the same class of task, verifiable and reversible, with no institutional signature required — a result of comparable quality in comparable calendar time. It falls by a second route as well: if my studio loses because the leverage of agents demanded more verification than it saved in execution. That second clause is not decoration. It is the same kind of result METR measured on experienced developers in 2025, although METR now marks it as out of date; I have no grounds for assuming it passes me by.

Why I am writing this

I do not run a one-person studio because I have better models. I have the same ones any corporation with a budget has access to, and probably worse infrastructure around them. I run it because in the narrow band of tasks I can verify and undo, my decision loop lasts as long as my decision lasts, and nobody has to approve it along the way.

Outside that band I lose to resources, and I lose deservedly.

If you run a programme in a large organization, do not take from this essay the conclusion that your people are the problem. They are not. Count instead how many people must agree on your typical decision, and put that number into Brooks's formula as n: you get the number of pairs that can fall out of step. Then check one thing: does the agent you are rolling out give knowledge to the person who decides, or does it only produce material for the next review?

Sources

1. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley 1975 (anniversary edition 1995) — Brooks's law and the n(n−1)/2 arithmetic of pairwise coordination. An analytical model drawn from observation on OS/360, not a study with a sample.
2. Ronald H. Coase, The Nature of the Firm, Economica, N.S. 4(16), 1937, pp. 386–405 — transaction costs as the reason firms exist and as the marker of their boundary, together with the claim about the entrepreneur's diminishing efficiency. Nobel Prize 1991, in part for this text.
3. Nachiappan Nagappan, Brendan Murphy, Victor Basili, The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE '08 (also Microsoft Research TR-2008-11) — a model of eight organizational metrics predicting post-release failures of Windows Vista binaries. A case study of one product at one company; prediction without causal identification, and not a test of Brooks's law about late projects.
4. Nicholas Bloom, Luis Garicano, Raffaella Sadun, John Van Reenen, The Distinct Effects of Information Technology and Communication Technology on Firm Organization, Management Science 60(12), 2014, pp. 2859–2885 — the separation of information technology from communication technology and the opposing directions of their effect on decision autonomy. Econometrics on World Management Survey data, instrumented identification.
5. Oriana Bandiera, Andrea Prat, Stephen Hansen, Raffaella Sadun, CEO Behavior and Firm Performance, Journal of Political Economy 128(4), 2020, pp. 1325–1369 — time diaries of 1,114 CEOs across six countries, unsupervised classification, the "leaders" and "managers" types.
6. METR — two measurement papers together with the authors' own caveats. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Joel Becker, Nate Rush et al., arXiv:2507.09089, 2025; METR post): a randomized experiment, forecast −24%, self-report −20%, measurement +19% working time; in the note We are Changing our Developer Productivity Experiment Design of February 2026 the authors judged the data from the newer round an unreliable signal because of selection (some developers and tasks dropped out as they did not want to work without AI), and the 2025 post carries a notice that its results are out of date. Measuring AI Ability to Complete Long Software Tasks (arXiv:2503.14499, 2025) together with the January 2026 note on the limitations of the metric: the task horizon at 50% and 80% reliability, and the 98% threshold for tasks that are critical for reliability and poorly verifiable.
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023 — a standard task (an HTTP server in JavaScript, from a template repository with twelve tests) completed 55.8% faster by the Copilot group among those who completed it; 95 freelancers (35 completed the task), the Codex model. The tool maker's co-authorship recorded in the body of the essay.
8. US Census Bureau, Census Bureau Releases Demographic Characteristics of Nonemployer Business Owners, press release of 8 May 2025, reference year 2022 — 29.8 million businesses without paid employees and 1.7 trillion USD in receipts, and a combined count of 35.7 million firms with 51.7 trillion USD in receipts (Annual Business Survey and Nonemployer Statistics by Demographics). The average, the shares by legal form and by receipts size class are my own calculations on the data of Nonemployer Statistics 2022 (December 2024 release, file nonemp22us); definitions after the FAQ. Administrative data from tax filings, United States coverage; Census notes that the business need not be the owner's main source of income, and a threshold of 1,000 USD in receipts (1 USD in construction) helps define the population.
9. Regulation (EU) 2022/2554 of the European Parliament and of the Council (DORA), Arts. 28–29 — assessment of ICT concentration risk, the register of contracts and exit strategies; applicable since 17 January 2025.
10. Regulation (EU) 2024/1689 (the artificial intelligence act), Art. 14 — the requirements for human oversight of a high-risk system; in force since 1 August 2024. Regulation (EU) 2026/1744 (Digital Omnibus on AI) amended the dates of application (Art. 113): for high-risk systems from 2 December 2027 (Annex III) and 2 August 2028 (Annex I), see the consolidated version. Status as of 11 October 2026.
11. Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari (MIT Project NANDA), The GenAI Divide: State of AI in Business 2025, July 2025 (file v0.1, preliminary findings) — a report of a research initiative, not a peer-reviewed paper; interviews, a survey and a review of initiatives, with results largely self-reported; the appendix holds questionnaires, not data. The figures of 95% and 5% as worded on p. 3, and of 90% and 40% as worded in the prose on p. 8; the chart on p. 8 labels the 90% as employees.
12. Anthropic, How we built our multi-agent research system, engineering post, June 2025 — the 90.2% advantage of the multi-agent arrangement, the fifteenfold cost in tokens, the class of task unsuited to a fleet. The maker's internal evaluation: direction credible, magnitude not reproducible from outside.
13. Veracode, 2025 GenAI Code Security Report, October 2025 update — 45% of code samples carrying an OWASP Top 10 vulnerability, more than 100 models, 80 tasks. A benchmark from a maker of code scanners: methodology public, commercial interest in a result of that shape recorded.

Raport MIT Project NANDA z lipca 2025 dał światu liczbę 95 procent i zgubił po drodze zdanie o wiele ciekawsze. W ponad 90 procentach badanych firm pracownicy zgłaszali regularne używanie do pracy własnych narzędzi AI, choć oficjalną subskrypcję modelu językowego deklarowało tylko około 40 procent firm. Dostęp do tych samych modeli leży więc po obu stronach podziału na sukces i porażkę. Twierdzę, że przewaga jednoosobowego operatora z flotą agentów wyrasta z czegoś, czego nikt nie fakturuje: odpada u niego wewnętrzna warstwa uzgodnień między pracownikami, więc w wynik idzie większa część dźwigni niż w organizacji. Decyzja, która od tego zależy, jest twoja i niewygodna — czy zatrudnić następną osobę, czy kupić następny stopień autonomii dla agenta, którego już masz.

Liczba, która zmieniła jednostkę już w samym raporcie

Zespół MIT Project NANDA opublikował w lipcu 2025 raport The GenAI Divide: State of AI in Business 2025 (Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari). Podstawą był przegląd ponad 300 publicznie ujawnionych inicjatyw z AI. Do tego doszły wywiady z przedstawicielami 52 organizacji oraz 153 odpowiedzi ankietowe kadry kierowniczej, zebrane na czterech konferencjach branżowych; okres badania to styczeń–czerwiec 2025. Autorzy nazywają swoje ustalenia wstępnymi i zastrzegają, że sześciomiesięczny okres obserwacji mógł zaniżyć odsetek sukcesów wdrożeń długoterminowych. W jednym akapicie streszczenia raport pisze, że 95 procent organizacji nie ma zwrotu z AI. Pisze też, że tylko 5 procent zintegrowanych pilotaży przynosi korzyści liczone w milionach, a ogromna większość nie ma mierzalnego wpływu na rachunek wyników.

Pierwsze zdanie dotyczy organizacji, drugie pilotaży.

Różnica nie jest pedantyczna. Firma prowadząca dwadzieścia pilotaży, z których jeden zarabia, trafia jednocześnie do tych 5 procent i do reszty, więc drugie zdanie niewiele mówi o samej firmie. Dalej raport przypisuje liczbę 5 procent narzędziom enterprise oraz przedsiębiorstwom i nie podaje, z jakiej próby ją wyliczył. Zastrzega natomiast, że liczby są kierunkowo trafne i pochodzą z wywiadów indywidualnych, a nie z oficjalnego raportowania firm, oraz że wielkość prób zależy od kategorii. Ustalenia opierają się na wywiadach i odpowiedziach deklaratywnych, raport jest dokumentem inicjatywy i nie ukazał się jako recenzowany artykuł, a w aneksie są kwestionariusze, ale nie ma danych.

Nazwijmy ten mechanizm od razu: jednostka liczby zmienia się w jednym akapicie streszczenia, więc ten, kto ją cytuje, musi wybrać jedną z dwóch, a nikt po drodze nie kłamie.

W tym samym materiale stoi ustalenie, na którym opieram całą tezę. Autorzy piszą, że pracownicy z ponad 90 procent badanych firm zgłaszali regularne używanie osobistych narzędzi AI do pracy, i nazywają to szarą strefą AI. Proza mówi o firmach, a wykres na tej samej stronie odnosi te 90 procent do pracowników, czyli do innej jednostki, więc przyjmuję wersję firmową. Traktuję tę liczbę jako rząd wielkości, bo pochodzi z ankiety i wywiadów, nie z telemetrii. Rząd wielkości wystarczy. Jeśli w zdecydowanej większości badanych firm, także tych, których inicjatywy nie dowożą, ktoś sięga prywatnie po te same modele co ja, to dostęp do nich przestaje być zmienną wyjaśniającą cokolwiek. Nie dowodzi to, że ci pracownicy pracują dzięki temu lepiej. Raport twierdzi wprawdzie, że ta strefa często daje lepszy zwrot niż inicjatywy oficjalne, ale pomiaru nie pokazuje, a samo sięganie po narzędzie nie jest jeszcze wynikiem ani nawet zapowiedzią wyniku. Moim zdaniem bariera nie stoi po stronie dostępu.

Jest jeszcze trzecia obserwacja z tego raportu i jest najbardziej szydercza ze wszystkich. Raport pisze, że lepszy zwrot często dawała automatyzacja zaplecza, a jedne z najbardziej spektakularnych udokumentowanych oszczędności pochodzą z zastąpienia zewnętrznych usług i agencji. Tymczasem w hipotetycznym podziale budżetu, o który poproszono dyrektorów, sprzedaż i marketing brały około połowy, a w innym miejscu raportu około 70 procent. Wydatków nie zmierzono, więc to deklaracja o tym, dokąd poszłyby pieniądze, nie o tym, dokąd poszły. Wskazuje jednak w jedną stronę: sam raport wiąże budżetową przewagę frontu z tym, że jego wynik łatwiej przypisać i zobaczyć. Technologia nie rozstrzygnęła tu niczego. Deklarowany podział budżetu układał się według widoczności wyniku, a widoczność ustala ten, kto ten wynik zatwierdza.

Model: nakład na uzgodnienie rośnie kombinatorycznie

Frederick P. Brooks Jr. opisał ten rachunek w The Mythical Man-Month (Addison-Wesley, 1975), na podstawie własnej pracy przy systemie OS/360. Jeśli każdą część zadania trzeba osobno uzgodnić z każdą inną, nakład rośnie jak n(n−1)/2. Czterech ludzi to sześć kanałów. Dziesięciu to czterdzieści pięć. Pięćdziesięciu to tysiąc dwieście dwadzieścia pięć kanałów, przy czym nikt nie przydzielił nikomu doby dłuższej niż dwadzieścia cztery godziny. Stąd prawo Brooksa: dodanie ludzi do opóźnionego projektu programistycznego opóźnia go jeszcze bardziej.

Brooks dał model analityczny i obserwację z jednego przedsięwzięcia; badania na próbie nie przeprowadził.

Pokrewny związek między strukturą organizacyjną a jakością kodu zbadał Nachiappan Nagappan z Brendanem Murphym i Victorem Basilim w pracy The Influence of Organizational Structure on Software Quality (ICSE '08, Lipsk 2008). Autorzy wzięli dane z Windows Visty i sprawdzili, co przewiduje awaryjność pojedynczej binarki po wydaniu. Model z ośmiu metryk organizacyjnych osiągnął precyzję 86,2 procent i czułość 84,0 procent. Wśród tych metryk były liczba inżynierów, którzy dotknęli binarki i nadal pracują w firmie, liczba tych, którzy ją dotknęli i odeszli, głębokość własności kodu i liczba organizacji, z których każda wnosiła ponad 10 procent zmian. Wynik był wyższy niż w modelach zbudowanych na zmienności kodu, jego złożoności, pokryciu testami, zależnościach i liczbie błędów sprzed wydania.

Struktura organizacji przewidywała awaryjność lepiej niż metryki samego kodu. To studium przypadku jednego produktu jednej firmy i korelacja predykcyjna, nie eksperyment przyczynowy, a prawa Brooksa o opóźnianiu projektu ta praca nie bada. Autorzy sami piszą, że danych o tym związku było niewiele. Kierunek zgadza się z tezą Brooksa, że struktura organizacji wpływa na jakość.

Drugą ramę dał ekonomista. Ronald H. Coase w The Nature of the Firm („Economica”, 1937) zapytał, dlaczego firmy w ogóle istnieją, skoro rynek rzekomo alokuje zasoby sprawniej. Odpowiedź: korzystanie z mechanizmu cenowego kosztuje. Trzeba znaleźć kontrahenta, wynegocjować warunki, spisać umowę, wyegzekwować ją. Firma powstaje po to, żeby te transakcje przenieść do środka i zapłacić za nie mniej, a rośnie tak długo, aż koszt zorganizowania kolejnej transakcji w środku zrówna się z kosztem załatwienia jej na rynku.

Agenci obniżają jedną stronę tego równania, bo część uzgodnień między ludźmi przestaje być potrzebna. Firma jednej osoby może więc wziąć do środka pracę, która dotąd wymagała zatrudnienia, i to jest cały rachunek ekonomiczny, na którym stoi moje jednoosobowe studio produktowe z flotą agentów. Coase ma jednak drugą stronę, o której się w tekstach o AI milczy: opisał też malejącą sprawność przedsiębiorcy przy rosnącej liczbie transakcji. Jedna głowa ma przepustowość. Agent nie dokłada głowy, tylko ręce.

Brakujące ogniwo znalazłem u Nicholasa Blooma, Luisa Garicano, Raffaelli Sadun i Johna Van Reenena w artykule The Distinct Effects of Information Technology and Communication Technology on Firm Organization („Management Science” 60(12), 2014). Rozdzielili dwie rzeczy, które zwykle wrzuca się do jednego worka pod nazwą „cyfryzacja”. Technologia informacyjna daje wiedzę temu, kto jest na dole, i zwiększa jego autonomię decyzyjną. Technologia komunikacyjna tanio przesyła informację do góry i decyzję centralizuje.

To rozstrzyga spór o to, czy narzędzie samo skraca pętlę decyzyjną. Nie skraca. Skraca ją wtedy, gdy wiedza ląduje u tego, kto decyduje. U jednoosobowego operatora te dwie osoby są tą samą osobą z definicji, więc każde narzędzie działa u niego jako technologia informacyjna. W organizacji ten sam agent bardzo często pracuje jako technologia komunikacyjna: produkuje materiał na kolejne uzgodnienie, slajd na kolejny przegląd, uzasadnienie do kolejnego wniosku budżetowego.

Ostatni element układanki dołożyli Oriana Bandiera, Andrea Prat, Stephen Hansen i Raffaella Sadun w CEO Behavior and Firm Performance („Journal of Political Economy” 128(4), 2020). Zebrali dzienniki czasu 1114 prezesów w sześciu krajach i sklasyfikowali ich zachowania bez zakładania kategorii z góry. Wyszły dwa typy. Jedni siedzą na spotkaniach wielofunkcyjnych i wysokiego szczebla, drudzy na rozmowach jeden na jeden z funkcjami rdzeniowymi. Firmy pierwszego typu radzą sobie lepiej, tyle że efekt widać dopiero po trzech latach, a sami autorzy przypisują różnicę dopasowaniu stylu do firmy, nie wyższości jednego typu nad drugim.

Mnie interesuje coś, czego autorzy nie musieli podkreślać, bo dla nich było oczywiste. Materiałem pracy prezesa jest spotkanie. Nie z lenistwa. W organizacji uzgodnienie po prostu jest pracą, a najdroższa godzina w firmie idzie w to, żeby dwie inne godziny mogły ruszyć.

Mechanizm: czego agent nie robi i co za to zabiera

Weźmy dowolne zadanie, które w organizacji przechodzi przez trzy piony. Policzmy, co się z nim po drodze dzieje.

Ktoś musi zdefiniować zakres. Ktoś inny musi go zaakceptować, bo to on odpowiada za budżet. Trzecia osoba sprawdzi, czy zadanie nie narusza niczego, za co ona odpowiada. Czwarta zapyta, czemu nie zrobiono tego w jej zespole. Każda z tych osób wnosi do sprawy prawdziwą wiedzę i prawdziwy interes, i żadna nie jest złoczyńcą. Wszystkie razem produkują koszt, którego nikt nie księguje, bo koszt uzgodnienia nie ma pozycji w planie kont.

Teraz to samo zadanie u operatora z agentem. Agent nie negocjuje zakresu. Nie broni budżetu, bo nie ma budżetu do obrony. Nie ma kariery, którą mógłby przy tej okazji zabezpieczyć, nie ma pionu, którego interes reprezentuje, i nie musi wyglądać na zajętego w kwartale, w którym akurat nie ma czego dowozić. Dostaje polecenie i albo dowozi wynik, albo nie dowozi. Nie twierdzę przy tym, że uzgodnienia w organizacji są zbędne, bo spora ich część istnieje po to, żeby ktoś w porę powiedział „nie”, i tej funkcji agent nie pełni.

Praca, która w programie enterprise rozkłada się na uzgodnienia, u jednoosobowego operatora zostaje pracą.

W tym jednym zdaniu upatruję przyczyny dysproporcji widocznej w liczbach NANDA i nie potrzebuję do tego założenia, że w korporacjach pracują gorsi ludzie. Pracują tam zwykle lepsi. Mają lepsze dane, lepszą infrastrukturę i większe budżety na tokeny, niż ja kiedykolwiek będę miał. Mają też więcej ludzi, którzy muszą się ze sobą dogadać, zanim decyzja stanie się wynikiem, a liczba możliwych par rośnie jak n(n−1)/2.

Zmierzmy tę pętlę, bo bez liczby zostaje ładne zdanie. Decyzja o zmianie ceny w moim studiu wymaga sprawdzenia dwóch rzeczy: czy nowa cena pokrywa koszt obsługi i czy nie psuje zobowiązań wobec obecnych klientów. Godzina, czasem dwie. W organizacji ta sama decyzja przechodzi przez właściciela produktu, finanse, prawnika i komunikację, a żaden z nich nie pracuje nad nią w trybie ciągłym. Czas kalendarzowy liczy się wtedy w tygodniach, choć suma roboczogodzin bywa podobna do mojej. Nakład wychodzi porównywalny. Kalendarz nie wychodzi porównywalny wcale.

Uczciwość każe zaraz dopisać drugą stronę tego bilansu, bo jest równie mechaniczna. Firma nie utrzymuje tych kanałów z upodobania do spotkań. Utrzymuje je, bo dają rzeczy, których pojedyncza osoba nie kupi za żadne pieniądze. Kapitał, który pozwala przeżyć osiemnaście miesięcy bez przychodu. Dystrybucję, czyli gotową listę klientów, do których wystarczy zadzwonić. Zaufanie instytucjonalne, czyli to, że dział zakupów w banku w ogóle otworzy ofertę. I ciągłość: jeśli osoba prowadząca projekt trafi do szpitala, projekt idzie dalej.

Ta sama cecha, która zdejmuje z jednoosobowego studia wewnętrzną warstwę uzgodnień, odbiera mu wszystkie cztery. Nie da się mieć jednego bez drugiego, bo to jest ten sam parametr widziany z dwóch stron. Kto tego nie policzy przed, a nie po, sprzedaje sobie bajkę o wolności.

Dźwignia jest wąskopasmowa, a szerokość pasma da się zmierzyć

Obie liczby kładę na stół, także tę niewygodną.

Kontrolowany eksperyment opisali Sida Peng, Eirini Kalliamvakou, Peter Cihon i Mert Demirer (The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023). Zadaniem było napisanie serwera HTTP w JavaScripcie. Uczestnicy dostali szablon repozytorium z opisem zadania i szkieletem kodu, a ukończenie sprawdzał zestaw dwunastu testów. Wśród tych, którzy zadanie ukończyli, grupa z asystentem skończyła o 55,8 procent szybciej, a przedział ufności sięgał od 21 do 89 procent. Odnotujmy przy tym, że współautorami są pracownicy producenta narzędzia.

Teraz drugie badanie. Zespół METR pod kierunkiem Joela Beckera i Nate'a Rusha przeprowadził randomizowany eksperyment (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv:2507.09089, 2025). Losowanie szło na poziomie zadania: szesnastu doświadczonych deweloperów open source, 246 zadań w dojrzałych repozytoriach, w których mieli średnio pięć lat stażu. Przed badaniem uczestnicy prognozowali skrócenie czasu o 24 procent. Po badaniu oceniali, że pracowali o 20 procent szybciej.

Pomiar pokazał, że byli o 19 procent wolniejsi.

Rozstrzał między samooceną a pomiarem wyniósł trzydzieści dziewięć punktów procentowych. Przedział ufności dla tego spowolnienia sięgał od plus dwóch do plus trzydziestu dziewięciu procent, a próba liczyła szesnaście osób z jednej populacji, więc nie jest to wyrok na branżę. Jest to natomiast najlepiej udokumentowany przypadek, w którym praktycy mylili się co do własnej prędkości, pracując przy tym własnymi rękami.

Najuczciwszy ruch w tej całej historii wykonali sami autorzy. W lutym 2026 METR opublikował notatkę o zmianie projektu eksperymentu. Dane z nowszej rundy, rozpoczętej w sierpniu 2025, uznał za niewiarygodny sygnał, głównie dlatego, że coraz więcej deweloperów nie chciało brać udziału w badaniu bez AI. Napisał też, że deweloperzy przyspieszają dziś prawdopodobnie bardziej niż w 2025 roku. Surowe wyniki tej rundy to zmiana czasu pracy o minus 18 procent dla tych z pierwotnych deweloperów, którzy wzięli udział w nowszej rundzie, i o minus 4 procent dla nowo rekrutowanych. Minus oznacza tu krótszy czas, a przedziały w obu wypadkach przechodzą przez zero. Autorzy nazwali to bardzo słabym dowodem na to, o ile przyspieszenie wzrosło od 2025 roku. Do tego od 30 do 50 procent ankietowanych deweloperów przyznało, że nie zgłasza niektórych zadań, nie chcąc robić ich bez AI. Brakuje więc zadań o wysokim spodziewanym uzysku, a nota traktuje te szacunki jako prawdopodobne zaniżenie.

Oba badania różnią się niemal wszystkim naraz. W Copilocie z 2022 roku pracował model Codex, a 95 freelancerów z Upworka robiło jedno standardowe zadanie z gotowego szablonu, a ukończyło je 35. W badaniu METR z 2025 roku działał głównie Cursor Pro z modelami Claude 3.5 i 3.7 Sonnet, a szesnastu doświadczonych opiekunów dużych repozytoriów robiło 246 własnych zadań. Różnią się model, narzędzie, uczestnicy, zadanie, miara i rok, więc z samego zestawienia nie wynika, co odwróciło znak wyniku. METR podejrzewa tu doświadczenie w repozytorium i jego rozmiar. Sam jednak ocenia ten dowód jako sugestywny, ale niepewny. Mam własną hipotezę, choć nic tu jej nie dowodzi: znak mogła zmienić klasa zadania. Inaczej pracuje się nad zadaniem świeżym i weryfikowalnym, a inaczej nad osadzonym w dojrzałym systemie z rozproszonym kontekstem, gdzie doświadczony deweloper po prostu wie lepiej. Zanim więc policzysz swoją dźwignię, nazwij klasę zadania, którą mierzysz.

Jak zbudować flotę

Flota agentów nie sprowadza się do liczby subskrypcji. Rozstrzyga o niej podział zadań na te, które puszczasz bez patrzenia, i te, które sprawdzasz przed każdym użyciem. Reszty nie oddajesz wcale.

W praktyce flota wygląda u mnie prościej, niż sugeruje samo słowo. Kilka równoległych sesji, każda z własnym zakresem i własnym plikiem reguł, żadna nie wie o pozostałych. Tak jest celowo. W chwili, w której dwa agenty muszą się dogadać co do wspólnego kontekstu, wracam do rachunku Brooksa, tyle że płaconego w tokenach i w moim czasie na scalanie sprzecznych wyników. Dlatego dzielę pracę po granicach, które i tak są rozdzielne: osobne repozytorium albo osobny dokument.

Podstawę liczbową dają pomiary METR z pracy Measuring AI Ability to Complete Long Software Tasks (arXiv:2503.14499, 2025). Metryka nazywa się horyzontem zadaniowym: to najdłuższe zadanie, które model kończy z pięćdziesięcioprocentową skutecznością, mierzone czasem ludzkiego eksperta. Horyzont podwajał się mniej więcej co siedem miesięcy od 2019 roku. Dla modelu z początku 2025 wynosił około pięćdziesięciu minut.

Liczba, która naprawdę steruje decyzją o autonomii, jest jednak inna. Horyzont dla osiemdziesięciu procent skuteczności jest około pięciokrotnie krótszy — dla tego samego modelu mówimy o mniej więcej dziesięciu minutach. W nocie o ograniczeniach ze stycznia 2026 autorzy dopowiadają resztę. Słupki błędu rozciągają się typowo dwukrotnie w każdą stronę, horyzonty różnią się o rzędy wielkości między domenami, a zadania krytyczne dla niezawodności i słabo weryfikowalne wymagają skuteczności powyżej 98 procent. Podwojenie horyzontu nie podwaja stopnia automatyzacji, bo awarie dłuższych zadań są bardziej złożone i kosztują więcej ludzkiej pracy przy naprawie.

Autonomia nie skaluje się więc z mocą modelu. Skaluje się z niezawodnością, której wymaga klasa zadania — a tę wyznaczasz ty, nie dostawca.

Z tego wychodzi kryterium delegowania, które u mnie zastąpiło wszystkie wcześniejsze heurystyki. Odwracalność razy weryfikowalność. Pytanie brzmi nie „czy model da radę”, tylko „ile kosztuje cofnięcie, jeśli nie da, i czy w ogóle zauważę”. Stopniowaną autonomię i mechanikę degradowania agenta, który zaczął się mylić, rozpisałem osobno w degradacjach agentów; tutaj zostawiam sam szkielet decyzyjny.

Kryterium odebrania zadania agentowi jest krótsze od tabeli. Jeśli weryfikacja wyniku kosztuje cię więcej niż samodzielne wykonanie, odbierz mu je. Zrób tę rzecz własnymi rękami. To jest ta sama pułapka, w którą wpadli doświadczeni deweloperzy z badania METR: dostali pomoc przy wykonaniu i zapłacili za nią między innymi czasem przy sprawdzaniu. Rachunku nie zauważyli. Reguła działa też w drugą stronę i wtedy jest przyjemniejsza. Tam, gdzie weryfikacja jest tania i natychmiastowa, flota daje najwięcej.

Zostaje weryfikacja, czyli miejsce, gdzie jednoosobowe studio najczęściej sobie kłamie. Operator jest złym czujnikiem własnej prędkości; pokazał to rozstrzał trzydziestu dziewięciu punktów u METR. Jest też złym czujnikiem własnej jakości. Veracode w zestawieniu 2025 GenAI Code Security Report przepuścił ponad sto modeli przez osiemdziesiąt zadań programistycznych w czterech językach. Wynik: 45 procent próbek kodu wprowadziło podatność z listy OWASP Top 10, czyli z kanonu najczęstszych błędów bezpieczeństwa w aplikacjach internetowych. Java wypadła najgorzej, z porażką w 72 procentach przypadków. Podatność typu cross-site scripting, czyli wstrzyknięcie cudzego skryptu na stronę, została bez zabezpieczenia w 86 procentach odpowiednich próbek. To benchmark firmy, która sprzedaje skanery kodu, więc ma interes w takim wyniku — metodologia jest jednak jawna, a kierunek zgodny z tym, co widać w praktyce.

Stąd reguła, której u siebie nie negocjuję: oceniam wynik. Nie interesuje mnie, czy agent „wyglądał na pewnego” ani ile kroków rozumowania pokazał. Interesuje mnie zielony test, przeczytana zmiana w kodzie, sprawdzona liczba i skan bezpieczeństwa, który przeszedł. Dlaczego pomiar bije ceremonię, rozbierałem w governance bez teatru, więc tu wystarczy wniosek operacyjny: bramka, której nie da się oblać, nie jest bramką.

Zastrzeżenia należą się też mojej własnej regule. Po pierwsze, weryfikacja wyniku działa tylko tam, gdzie wynik ma postać sprawdzalną w skończonym czasie, a duża część pracy, którą ludzie nazywają strategią, takiej postaci nie ma. Tam flota jest bezużyteczna. Po drugie, ocena samego wyniku wystarcza tylko tam, gdzie błąd da się cofnąć po fakcie. Jeśli w trakcie pracy agent może ujawnić dane albo wykonać krok nieodwracalny, ocena wyniku przychodzi za późno, więc obowiązuje wiersz tabeli, w którym agent przygotowuje, a wykonuję ja.

Na koniec rzecz, której nie oddaję agentowi nigdy. Akurat tej listy nie musiałem wymyślać, bo prawodawca unijny spisał ją dla systemów wysokiego ryzyka. Artykuł 14 rozporządzenia (UE) 2024/1689 o sztucznej inteligencji wymaga, by taki system był zaprojektowany z myślą o nadzorze sprawowanym przez osoby fizyczne. Osoby wyznaczone do tego nadzoru mają, w stosownym i proporcjonalnym zakresie, móc zrozumieć system i pozostać świadome możliwej skłonności do automatycznego polegania na jego wyniku. W tym samym zakresie mają też umieć poprawnie zinterpretować ten wynik. W tym samym zakresie mają móc zdecydować o nieskorzystaniu z systemu albo o odwróceniu jego wyniku, a także go zatrzymać. Wymogi dla systemów wysokiego ryzyka będą stosowane od 2 grudnia 2027 (załącznik III) i od 2 sierpnia 2028 (załącznik I), po odroczeniu z 2026 roku. Nie każdy agent jest takim systemem. Traktuję więc ten przepis jako wzorzec rozumowania i nie wywodzę z niego własnego obowiązku. Nadzór jest tam przypisany osobom fizycznym. Żadna procedura ani drugi agent nie przejmą tej roli.

Sufit, ryzyko koncentracji i warunek falsyfikacji

Zacznijmy od rozkładu, którego moja teza nie opisuje. US Census Bureau podało w maju 2025, że w roku referencyjnym 2022 w Stanach Zjednoczonych działało 29,8 miliona firm bez płatnych pracowników, a ich łączne przychody wyniosły 1,7 biliona dolarów. To średnio około 58 tysięcy dolarów na firmę rocznie, licząc z niezaokrąglonych danych. W łącznym zestawieniu Census, obejmującym firmy z pracownikami i bez, za ten sam rok było 35,7 miliona firm i 51,7 biliona dolarów przychodów. Firmy bez płatnych pracowników to więc około 83 procent firm i około 3,3 procent przychodów.

W 2022 roku pięć na sześć amerykańskich firm nie miało płatnych pracowników. I razem robiły jedną trzydziestą obrotu.

Model jednoosobowy skaluje się w liczbie, nie w wolumenie. W tych zestawieniach Census nie podaje mediany przychodów, ale z jego klas wielkości wynika, że około 61 procent takich firm miało przychody poniżej 25 tysięcy dolarów, a około 38 procent poniżej 10 tysięcy. Około 87 procent to działalności indywidualne (sole proprietorships), a reszta to spółki osobowe i kapitałowe. Firma bez płatnych pracowników nie zawsze oznacza więc jedną osobę. Census zaznacza też, że nie musi to być główne źródło dochodu właściciela. Typowy przedstawiciel tej grupy nie jest studiem produktowym z flotą agentów. Ten esej opisuje górny ogon rozkładu i musi to powiedzieć wprost, bo inaczej jest opowieścią zwycięzcy o sobie samym.

Drugi sufit wynika z regulacji. Rozporządzenie (UE) 2022/2554, znane jako DORA, obowiązuje od 17 stycznia 2025. Artykuły 28–29 każą podmiotowi finansowemu ocenić przed podpisaniem umowy na usługi technologii informacyjno-komunikacyjnych, czy umowa wzmacnia ryzyko koncentracji, a przy usługach wspierających funkcje krytyczne lub ważne także czy dostawcę da się łatwo zastąpić. Do tego dochodzą rejestr wszystkich zawartych umów oraz, dla takich usług, strategie wyjścia. Rozporządzenie nie wyklucza dostawcy jednoosobowego. Ocena zastępowalności dotyczy jednak także jego, a moja interpretacja, której w przepisie nie ma, idzie dalej: dostawca będący jedną osobą jest dla tej oceny oczywistym czynnikiem ryzyka. Na części rynków ciągłość jest produktem, więc jednoosobowość może przesądzać o wyniku rozmowy o zakupie.

Artykuł 14 rozporządzenia o sztucznej inteligencji, który przed chwilą dał mi listę rzeczy nieoddawanych agentowi, tnie tu w drugą stronę, o ile studio dostarcza albo uruchamia system wysokiego ryzyka. Obowiązki nadzorcze (art. 14 i 26) i dokumentacyjne (między innymi art. 11) są wtedy kosztem stałym. Koszt stały jest regresywny wobec wielkości: korporacja rozkłada go na dział, a jednoosobowe studio płaci z tej samej doby, z której ma robić produkt. Im więcej regulacji wchodzi w moją klasę zadań, tym węższe robi się pasmo, w którym mam przewagę.

Trzeci zarzut jest techniczny i dotyczy samej floty. Anthropic opisał w czerwcu 2025, jak zbudował wieloagentowy system badawczy: układ z modelem prowadzącym i podagentami pobił pojedynczego agenta o 90,2 procent na wewnętrznej ewaluacji. Rachunek za to jest jawny w tym samym tekście. Agenci zużywają około czterokrotnie więcej tokenów niż zwykła rozmowa, a systemy wieloagentowe około piętnastokrotnie. Autorzy wskazują też klasę zadań, w której zrównoleglenie szkodzi: wszędzie tam, gdzie wszyscy agenci potrzebują tego samego kontekstu albo gdzie zależności między nimi są gęste, jeden agent z długim kontekstem bije pięciu.

Rachunek Brooksa nie znika przy przejściu na agentów. Wraca jako faktura za tokeny.

Różnica wobec organizacji jest realna, ale trzeba ją nazwać precyzyjnie. U mnie koszt uzgodnienia jest pieniężny i rozliczalny tego samego dnia, bo widzę go w rachunku za interfejs programistyczny. W organizacji jest czasowy i polityczny, a księgowość go nie widzi. To różnica rodzaju i widoczności, a uzgodnienie z agentami nadal kosztuje.

Najtrudniejszy zarzut dotyczy mojej głowy. Jednoosobowa pętla decyzyjna jest szybka i nieodporna na błąd pojedynczej osoby. W organizacji sprzeciw bywa jedyną działającą bramką jakości, i to nawet wtedy, gdy jest motywowany politycznie — zła intencja też potrafi wyłapać dziurę w rozumowaniu. U mnie nikt się nie sprzeciwi, bo nie ma komu. Zastępuję ten sprzeciw trzema rzeczami i wiem o każdej z nich, że jest słabsza od żywego oponenta. Bramka pomiarowa zwraca liczbę niezależną ode mnie. Agent uruchamiany wyłącznie w roli oponenta dostaje gotowy materiał i ma zadanie go rozbić. Ruchu nieodwracalnego nie wykonuję tego samego dnia, w którym go wymyśliłem. Kto twierdzi, że taki zestaw jest pełnym ekwiwalentem zespołu, kłamie.

Ostatni zarzut trafia w sam gatunek tego tekstu i nie umiem go zbić. Manifesty pisze ten, komu wyszło. Gdyby moje studio padło w zeszłym roku, nie czytałbyś eseju o tym, ile daje brak wewnętrznej warstwy uzgodnień, tylko o tym, dlaczego jednoosobowość jest pułapką. Ten drugi esej miałby równie dobre źródła, bo materiał na obie tezy leży w tych samych badaniach, które przed chwilą przeczytałeś. Błędu przeżywalności nie da się usunąć lepszym pisaniem. Można go nazwać i podać warunek, po którym poznasz, że autor się mylił.

I dlatego manifest kończę warunkiem, który pozwala mi się pomylić w sposób sprawdzalny. Teza upada, jeśli w ciągu dwunastu miesięcy zespół w programie enterprise dowiezie w tej samej klasie zadań — weryfikowalnych i odwracalnych, bez wymogu podpisu instytucji — wynik porównywalny jakościowo w porównywalnym czasie kalendarzowym. Upada też drugą drogą: jeśli moje studio przegra dlatego, że dźwignia agentów wymagała więcej weryfikacji, niż zaoszczędziła wykonania. Ten drugi człon nie jest ozdobą. To ten sam rodzaj wyniku, który METR zmierzył u doświadczonych deweloperów w 2025 roku, choć dziś METR oznacza go jako nieaktualny; nie mam powodu zakładać, że mnie omija.

Po co to piszę

Nie prowadzę studia jednoosobowego dlatego, że mam lepsze modele. Mam te same, do których dostęp ma każda korporacja z budżetem, a prawdopodobnie gorszą infrastrukturę wokół nich. Prowadzę je dlatego, że w wąskim paśmie zadań, które umiem zweryfikować i cofnąć, moja pętla decyzyjna trwa tyle, ile trwa moja decyzja, i nikt nie musi jej po drodze zatwierdzić.

Poza tym pasmem przegrywam z zasobami i przegrywam zasłużenie.

Jeśli prowadzisz program w dużej organizacji, nie kupuj z tego eseju wniosku, że twoi ludzie są problemem. Nie są. Policz zamiast tego, ilu ludzi musi się dogadać w twojej typowej decyzji, i wstaw tę liczbę jako n do wzoru Brooksa: wyjdzie liczba par, które mogą się rozjechać. Potem sprawdź jedno: czy agent, którego właśnie wdrażasz, daje wiedzę temu, kto decyduje, czy tylko produkuje materiał na kolejny przegląd?

Bibliografia

1. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley 1975 (wydanie rocznicowe 1995) — prawo Brooksa i rachunek n(n−1)/2 dla parami uzgadnianej komunikacji. Model analityczny z obserwacji przy OS/360, nie badanie z próbą.
2. Ronald H. Coase, The Nature of the Firm, „Economica”, N.S. 4(16), 1937, s. 386–405 — koszty transakcyjne jako powód istnienia firmy i wyznacznik jej granicy, wraz z tezą o malejącej sprawności przedsiębiorcy. Nagroda Nobla 1991 między innymi za ten tekst.
3. Nachiappan Nagappan, Brendan Murphy, Victor Basili, The Influence of Organizational Structure on Software Quality: An Empirical Case Study, ICSE '08 (także Microsoft Research TR-2008-11) — model z ośmiu metryk organizacyjnych przewidujący awaryjność binarek Windows Vista po wydaniu. Studium przypadku jednego produktu jednej firmy, predykcja bez identyfikacji przyczynowej, a nie test prawa Brooksa o opóźnianiu projektu.
4. Nicholas Bloom, Luis Garicano, Raffaella Sadun, John Van Reenen, The Distinct Effects of Information Technology and Communication Technology on Firm Organization, „Management Science” 60(12), 2014, s. 2859–2885 — rozdzielenie technologii informacyjnej od komunikacyjnej i przeciwne kierunki ich wpływu na autonomię decyzyjną. Ekonometria na danych World Management Survey, identyfikacja instrumentowana.
5. Oriana Bandiera, Andrea Prat, Stephen Hansen, Raffaella Sadun, CEO Behavior and Firm Performance, „Journal of Political Economy” 128(4), 2020, s. 1325–1369 — dzienniki czasu 1114 prezesów w sześciu krajach, klasyfikacja nienadzorowana, typy „leaders” i „managers”.
6. METR — dwie prace pomiarowe wraz z autorskimi zastrzeżeniami. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Joel Becker, Nate Rush i in., arXiv:2507.09089, 2025; wpis METR): randomizowany eksperyment, prognoza −24%, samoocena −20%, pomiar +19% czasu pracy; w nocie We are Changing our Developer Productivity Experiment Design z lutego 2026 autorzy uznali dane z nowszej rundy za niewiarygodny sygnał z powodu selekcji (część deweloperów i zadań wypadła, bo nie chciano pracować bez AI), a wpis z 2025 roku ma adnotację, że jego wyniki są nieaktualne. Measuring AI Ability to Complete Long Software Tasks (arXiv:2503.14499, 2025) wraz z notą o ograniczeniach metryki ze stycznia 2026: horyzont zadaniowy przy 50% i 80% skuteczności oraz próg 98% dla zadań krytycznych dla niezawodności i słabo weryfikowalnych.
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023 — standardowe zadanie (serwer HTTP w JavaScripcie, szablon repozytorium z dwunastoma testami) ukończone o 55,8% szybciej przez grupę z Copilotem wśród tych, którzy je ukończyli; 95 freelancerów (zadanie ukończyło 35), model Codex. Współautorstwo producenta narzędzia odnotowane w tekście eseju.
8. US Census Bureau, Census Bureau Releases Demographic Characteristics of Nonemployer Business Owners, komunikat z 8 maja 2025, rok referencyjny 2022 — 29,8 mln firm bez płatnych pracowników i 1,7 bln USD przychodów oraz łączne zestawienie 35,7 mln firm z 51,7 bln USD przychodów (Annual Business Survey i Nonemployer Statistics by Demographics). Średnia, udziały form prawnych i klas wielkości przychodów to moje obliczenia na danych Nonemployer Statistics 2022 (wydanie z grudnia 2024, plik nonemp22us); definicje wg FAQ. Dane administracyjne z zeznań podatkowych, zasięg Stany Zjednoczone; Census zaznacza, że działalność nie musi być głównym źródłem dochodu właściciela, a próg 1000 USD przychodów (w budownictwie 1 USD) współwyznacza populację.
9. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA), art. 28–29 — ocena ryzyka koncentracji ICT, rejestr umów i strategie wyjścia; stosowane od 17 stycznia 2025.
10. Rozporządzenie (UE) 2024/1689 (akt o sztucznej inteligencji), art. 14 — wymogi nadzoru człowieka nad systemem wysokiego ryzyka; w mocy od 1 sierpnia 2024. Rozporządzenie (UE) 2026/1744 (Digital Omnibus on AI) zmieniło terminy stosowania (art. 113): dla systemów wysokiego ryzyka od 2 grudnia 2027 (załącznik III) i od 2 sierpnia 2028 (załącznik I), zob. wersja skonsolidowana. Stan na 11 października 2026.
11. Aditya Challapally, Chris Pease, Ramesh Raskar, Pradyumna Chari (MIT Project NANDA), The GenAI Divide: State of AI in Business 2025, lipiec 2025 (plik v0.1, ustalenia wstępne) — raport inicjatywy badawczej, nie artykuł recenzowany; wywiady, ankieta i przegląd inicjatyw, wyniki w znacznej mierze samo-raportowane; w aneksie są kwestionariusze, nie dane. Liczby 95% i 5% wg sformułowań ze s. 3, a 90% i 40% wg prozy ze s. 8; wykres na s. 8 opisuje te 90% jako pracowników.
12. Anthropic, How we built our multi-agent research system, materiał inżynierski, czerwiec 2025 — przewaga 90,2% układu wieloagentowego, koszt piętnastokrotny w tokenach, klasa zadań nieodpowiednia dla floty. Ewaluacja wewnętrzna producenta, kierunek wiarygodny, wielkość nieodtwarzalna z zewnątrz.
13. Veracode, 2025 GenAI Code Security Report, aktualizacja z października 2025 — 45% próbek kodu z podatnością z OWASP Top 10, ponad 100 modeli, 80 zadań. Benchmark producenta skanerów kodu: metodologia jawna, interes komercyjny w takim wyniku odnotowany.