Is This the End of Software Engineering, or the Expropriation of the Craft?

Dear Young Comrades,

Has software engineering ended? That is the question people are genuinely asking today. The person sitting at a screen late at night wonders whether the code they wrote will still be theirs tomorrow. The person just entering the trade looks to see whether the ladder is still standing at the door of the craft they are learning. The curiosity is real. What is not real is the verdict of "it is over", stuck in haste onto that curiosity.

In this piece we produce another way of looking at that question, through a paper. The paper declares an ending. We look at what stands behind the declaration: is it the profession that is ending, or is the craft itself being expropriated?

On 4 June 2026 a fifteen-page paper landed in the software engineering section of arXiv: "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm". Its author, Zhenfeng Cao, is from a Shenzhen-based investment and development company (Lingxi Intelligent Investment). Six days later, on 10 June, a second version was published. The title was now "Agentic Software"; the last sentence of the first version, "The old software engineering is ending; the new one has already begun", had given way to "The old software engineering is not ending; it is turning into something larger". (arXiv:2606.05608)

A paper stepping back from its own title within six days tells us more than the paper's contents. Declaring "the end" is easy; standing behind the declaration is hard. But we are not writing this in order to mock a paper. The paper is a condensed, formula-bound summary of a mood circulating in the software world today. The mood is this: code is no longer the system itself, but a temporary tool that a language model produces and discards while reasoning; and the programmer is no longer the person who writes code, but the person who states an intent to agents and inspects the result.

There is a true observation in that sentence. What is wrong is who the observation belongs to, and what it hides. Two hidden things matter especially. First, where the agents' "capability" comes from: the open source commons, grown over decades by the voluntary labour of millions of people. Second, which class position this transformation places the programmer in. The paper mentions neither. The extended form of this piece tries to fill exactly those two gaps.

We will take the paper seriously, weigh its claims one by one, set them against what is actually happening, look at what has become of the open source ecosystem, listen to the great masters of the software world, and finally carry the matter to its proper place: the labour process, property, and the question of whom knowledge belongs to.

As usual, the summary first, then the detail.

---

Summary: Twenty Theses under Six Headings

The paper

One. The paper's claim is this: the complexity of software grows exponentially with the number of components, while human capacity to comprehend is fixed; a language model's capacity grows with computing power. Agents therefore scale "inevitably" better than humans, and code ceases to be the carrier of the system and becomes a temporary tool.

Two. The mathematical dress of this claim is thin. The complexity formula is inconsistent within itself; that human capacity is "fixed" and model capacity grows "exponentially" is assumed, not proved. The evidence section rests on a two-year benchmark result, a pilot without a control group on a vendor's blog, and the star count of a GitHub repository. The paper's most honest page refutes its own thesis: agents succeed on more than 80 per cent of single tasks, while on a continuously evolving codebase success falls to 38 per cent at most.

What is actually happening

Three. Use is nearly universal, and trust is falling. Delivery speed is rising; so are instability, duplicated code and the lack of refactoring. Perceived speed and measured speed do not match.

Four. In the labour market the effect appears as not hiring, before it appears as firing: in the occupations most exposed to artificial intelligence, employment of people aged 22 to 25 is shrinking while the senior staff keep their places. Companies announce agent use in the same quarter as record profits and "voluntary departure" packages.

Open source

Five. The raw material of agents is open source. By Harvard's reckoning, rewriting open source from scratch today would cost about 4.2 billion dollars, but the value it provides to the companies that use it is 8.8 trillion dollars; more than 90 per cent of that value is produced by about 5 per cent of developers. The world's largest pool of unpaid labour is now training data for models.

Six. The open source commons is besieged from three directions: from above, scraping (artificial intelligence crawlers choking free software infrastructure); from below, a flood (careless artificial intelligence contributions that led curl to close its bounty programme and GitHub to limit pull requests); and from the side, drying out (the collapse of questions on Stack Overflow, and Tailwind laying off three quarters of its engineers while its use breaks records).

Seven. The law is part of the siege. In September 2026 the US Ninth Circuit held that Copilot does not copy, that it "creates new works"; the chain of attribution in licences can evaporate, legally, once it passes through the machine. The word "open" is being expropriated too: publishing weights without disclosing training data is marketed as "open source artificial intelligence".

Eight. This is not a "tragedy of the commons". It is the enclosure of the commons. What is produced in common is appropriated privately. In our own formula: "A common product is not common without common ownership."

Role and ladder

Nine. The programmer's role is genuinely changing: from the chain of analysis, writing, testing and delivery, to defining the requirement, inspecting the agent's output, keeping the architecture consistent, and carrying responsibility for the result. This is not less intellectual labour. A good review requires domain knowledge, knowing the system's history, and foreseeing side effects.

Ten. A new contradiction is born: while the first production of code speeds up, gaining the experience that decides why the code is right becomes harder. The knowledge required for inspection was produced in the very practice that is being removed. Industrial psychology has called this the "irony of automation" since 1983. Open source was also the century's largest apprenticeship school; that school's door is narrowing too.

Eleven. The great masters of software, from Dijkstra to Brooks, from Naur to Fowler, from Booch to Torvalds, say the same thing in different languages: tools change, essential complexity remains; a program is not only code, it is a theory in the heads of the people who make it; and no tool removes responsibility.

The class ground

Twelve. In Marx's terms, software labour is passing from the formal to the real subsumption of labour under capital. The programmer was a wage worker for a long time, but held the labour process itself, the craft, in their own hands. Agents rebuild the labour process according to capital's machine.

Thirteen. A rise in productivity does not by itself bring a shorter working day. Under capitalism it takes the form of relative surplus value: more work for the same wage, fewer staff for the same work. Microsoft offering a departure package to a quarter of its staff in a quarter of record profit is the textbook example.

Fourteen. The programmer is shifting from what sociologists call a "contradictory class location", from a labour aristocracy that thought of itself as "talent", towards a position where proletarianisation is accelerating. Juniors are pushed into the reserve army of labour, seniors into the role of human guarantor, and the invisible layer into the data work of the Global South.

Fifteen. The "outcome-based" revenue model of the agent service is a monopoly rent taken on the general intellect. This is not techno-feudalism. It is monopoly capitalism equipped with digital means of production.

The philosophical ground

Sixteen. It has been known since Aristotle's distinction between techne and phronesis: craft knowledge is learned by doing, and cannot be reduced to the sum of rules. Polanyi's sentence "we know more than we can tell", Naur's thesis that "a program is a theory", and Benjamin's worry about "experience that cannot be transmitted" arrive at the same place: when experience is handed to the machine, transmission between generations breaks.

Seventeen. The paper's sentence "what persists is not the code, but the agent's capability" is a sentence about property. The programmers' collective theory, Marx's "general intellect", crystallises in the model's weights, and those weights are the property of a few monopolies.

Eighteen. The young Marx's four alienations, from the product, from the process, from species-being and from one another, gain a new concreteness for the programmer in the age of agents. Hegel's master-slave dialectic shows why the "intent architect" is not the master, but an intermediary who looks like one.

The answer

Nineteen. Reducing the productivity debate to the amount of code produced is to accept capital's measure. We should measure error rates, the burden of maintenance, the training of new workers and the product's long-term reliability together, and we should ask whom the gain goes to.

Twenty. Software engineering is not ending. What is ending is the period in which the programmer thought of themselves as "talent, not a worker". The answer is not individual "reskilling". It is an organised demand: a guarantee of entry into the trade, recognition of the labour of review, responsibility belonging to the employer, the productivity gain turned into a shorter working week, and the open source commons taken back under the control of those who feed it.

---

Part One: What Does the Paper Say?

Let us first summarise the paper fairly, in its own words. The first condition of criticism is to report accurately what is being criticised.

Three central claims

The paper is built on three claims:

• Necessity from first principles. The agent paradigm is not a market preference. It is the "inevitable result" of the laws by which complexity scales. Traditional software requires every decision to be coded explicitly by a human. Language-model agents can cope with complexity in a non-linear way by handing reasoning to models whose capacity grows with training computation.
• Not optimisation, a change of paradigm. The passage from the chain "AI → software → result" to the chain "agent → result" takes the software product out of being a necessary intermediate link, just as SaaS removed software that required installation.
• A discipline being born. "Agentic engineering" is being born as a separate practice, with its own concepts, tools and measures. Its practitioners are not "better programmers". They are an entirely different role: intent architects, agent coordinators and outcome auditors.

The formal model

The paper defines traditional software as a triple: computing resources, deterministic decision rules embedded in source code, and an execution environment that applies those rules to inputs. The critical feature is this: the decision logic was written by a human before execution. Every new feature, every bug fix, every adaptation requires a human to understand the change, find the right place in the code, change it without causing a regression, and verify it.

An agent system is a quadruple: a language model as a reasoning engine, executable tools (interpreters, APIs, databases), a memory subsystem, and a planning mechanism that breaks the user's intent into sequences of action. Here the decision logic is produced at runtime. The model writes the code when needed, uses it and discards it. Code is not "the system". It is "a temporary by-product".

The paper presents this distinction as one step beyond Andrej Karpathy's 2017 idea of "Software 2.0": in Karpathy, the neural network took the place of the program; in agent systems, the neural network writes programs to order.

The complexity argument

What the paper calls "first principles" starts from Fred Brooks's distinction, in The Mythical Man-Month (1975), between essential and accidental complexity. Accidental complexity, the burden brought by the language, the tool and the implementation, was reduced over decades by high-level languages, frameworks and automated tests. Essential complexity, what belongs to the problem itself, is unbounded. From there the paper moves to this proposition: in a system of n components the number of possible paths of interaction grows on the order of 2ⁿ, while human cognitive capacity is "essentially fixed". Hierarchical decomposition, modular interfaces and encapsulation shrink the constant factor but do not change the asymptotic behaviour. The language model's "effective capacity", because it grows with model size and training computation, "exponentially" according to the paper, means that the agent paradigm "separates solution capacity from human cognitive limits".

Three generations of software delivery

Perhaps the paper's most openly class page is the following table, which we translate:

Generation	Basic mechanism	Who holds the complexity	Revenue model	Examples
Software 1.0 (local)	Code and data run in the institution	The end user (installation, maintenance)	Licence sale	Microsoft, Oracle
Software 2.0 (SaaS)	Code and data run in the cloud	The vendor (infrastructure, updates)	Subscription	Salesforce, AWS
Software 3.0 (AaaS)	The agent runs autonomously in the cloud	The agent (understanding, building, running)	Outcome-based	OpenAI, Anthropic

According to the paper, the same pattern works at every passage: the party best able to absorb complexity absorbs it, and the party least suited to managing it is relieved of it. SaaS relieved businesses of the server room. "Agent as a Service" (AaaS) will relieve them of having to specify how a result is produced. It will be enough that they say what they want.

We will return to this table. For now look at the last row of the "examples" column: two company names. And at the last row of the "revenue model" column: outcome-based.

Evidence, limits and a roadmap

Four data points are offered as evidence: an open model (Lingma SWE-GPT 72B) solving 30.2 per cent of GitHub issues on SWE-bench Verified (GPT-4o, 31.8 per cent); a pilot reported on the LangChain blog in which multi-agent coordination shortened root-cause finding by 93 per cent and saved more than 200 engineering hours in a month; Nous Research's open source Hermes Agent framework, with "more than 179,000 GitHub stars", as "the most complete production example" of the principle of self-improvement; and a literature review listing hundreds of studies.

The paper then opens an honest page. On a benchmark that measures continuous software evolution (EvoClaw in the paper; its current name on arXiv is SWE-Milestone), across 12 leading models and 4 agent frameworks, success is above 80 per cent on standalone tasks and falls to 38 per cent at most under continuous evolution. The paper lists four reasons: the loss of system integrity once the codebase exceeds the context window, an early error cascading into later work, technical debt not being taken into account, and semantic errors that pass the tests and break on new inputs.

Finally a four-stage roadmap is drawn: tool-assisted (2023–2025), autonomous on a single task (2025–2027), multi-agent teams (2026–2029), and ecosystems that can evolve themselves (2028+). In the "representative systems" column of the last stage is written: "AGI assistants (possible)."

And a recommendation to organisations: "As individual productivity multiplies with agent leverage, team topologies should evolve. Larger developer teams may be replaced by smaller 'agent orchestrator' teams, with corresponding changes in hiring, promotion and career development."

---

Part Two: Weighing the Claims One by One

The crack inside the formula

The paper's "first principles" argument rests on one proposition: in a system of n components, paths of interaction are on the order of 2ⁿ. But the justification immediately beneath the proposition says something else: each of the n(n−1)/2 pairs that can be formed from n components may or may not interact, which gives 2 to the power of n(n−1)/2 possible dependency graphs. That is not 2ⁿ. It is a quantity that grows much faster. The formula and its justification do not match. This may be a small slip of writing. It stands, though, in the load-bearing column of the claim of "necessity from first principles".

The real problem is not the mathematics. It is the comparison itself. The paper sets human capacity as "fixed" and model capacity as "growing exponentially", and draws the result from there. Yet:

• Human capacity is not the capacity of a single human. Software was never made in a single head. Brooks's whole book describes how complexity is managed, and cannot be managed, through teams and forms of organisation. Modularity, interfaces, version control, code review, open source communities: all of these are the social extension of human cognition. The paper reduces collective labour to an individual head, and then "discovers" that the head is limited.
• The growth of model capacity is an assumption. The paper's own data shows this: 80 per cent on a single task, 38 per cent in continuous evolution. As the context window grows, the problem of integrity does not disappear. In the paper's own phrase, "context drift" continues.
• Complexity is moved elsewhere. It does not vanish. The paper says that in traditional software the decision logic is "static", and that in the agent it is "produced at runtime". But a decision produced at runtime is a decision that has to be inspected. The greatest virtue of static code was that it could be read, examined and repeated. A logic reproduced afresh at every run does not make the error easier to catch. It makes it harder. What the paper calls "oversight" is the place where complexity returns to the human side.

What Brooks called essential complexity belongs to the problem itself: a bank's interest calculation, a hospital's appointment rules, a municipality's planning code. This complexity does not shrink because the tool that codes it has changed. What changes is who carries the complexity, and who is accountable.

The weakness of the evidence section

Let us look closely at the paper's four pieces of "breakthrough" evidence:

• The SWE-bench result belongs to 2024 and shows a two-year-old open model approaching GPT-4o. An interesting datum, but it has no direct relation to the claim of "the end of software engineering". Benchmarks such as SWE-bench are exactly the "standalone task" kind that the paper later criticises.
• The figures of 93 per cent and 200 hours come from a guest post published on LangChain's blog. When we look at the post itself, we see that the baseline of comparison was estimated from "historical evidence", and that there is no control group or statistical analysis. The post ends with a promotion of LangChain's own products. More instructive still, the same post says that the largest gain came not from code generation but from tests after merging, and that "the pull-request review process brought by the human in the loop became the bottleneck". The paper's evidence shows that the bottleneck has shifted to human oversight.
• A GitHub star is not evidence. It is an indicator of popularity.
• A literature review shows the breadth of a field, not the truth of a claim.

In a scientific text the quality of the evidence should be proportionate to the size of the claim. A large claim such as "the end of the paradigm" cannot be carried by a vendor's blog and a star count. This is not a personal failing. It is the natural result of the author's position. A text written from an investment and development company, which places two large model companies in the "Software 3.0" column and presents the "outcome-based revenue model" as the economy of the new age, is an investment thesis. The language of theses can be scientific. Their function is valuation.

Borrowing Karpathy's term

A small but meaningful detail: Karpathy's "Software 2.0" meant neural-network weights taking the place of hand-written code. The paper uses the same label in an entirely different sense, for SaaS, and adds its own "Software 3.0" on top. This carries not the conceptual content of the term, but its prestige. An operation we often see in the discourse of the sector: the respectability of a concept is loaded onto the back of another narrative.

The title that was withdrawn

The change of title in the second version, and the reversal of the last sentence, show that the author too saw the paper's limits. A declaration of "the end" draws attention, is shared, is quoted. The sentence "it is turning into something larger" says nothing. The first title was a call of doom. The second is a brochure sentence. What they share is that they reduce the question of what will become of the people who make software to a proposal for a "reskilling strategy".

---

Part Three: What Is Actually Happening?

Set the paper aside and look at the field. Through 2025 and 2026 many studies were published that tried to measure the effect of artificial intelligence on software production. None of them has the last word by itself. Placed side by side, they draw a consistent picture.

Use is universal, trust is falling

Stack Overflow's 2025 Developer Survey reached more than 49,000 developers in 177 countries. Eighty-four per cent of developers use artificial intelligence tools or plan to (76 per cent the year before). But the share who do not trust the tools' accuracy rose from 31 per cent to 46 per cent. Those who trust them are at 33 per cent, and those with "high trust" are only 3 per cent. Sixty-six per cent of developers complain of wrestling with outputs that are "almost right, but not quite". Forty-five per cent say that debugging code produced by artificial intelligence takes longer than writing the code themselves.

These last two figures show how heavy the labour is that the paper calls "oversight". "Almost right" code is more dangerous than wrong code, because wrong code breaks at once, and almost-right code breaks in production, at midnight.

Perceived speed and measured speed

The independent research organisation METR ran a randomised controlled experiment in early 2025 with experienced open source developers: they worked, with or without artificial intelligence, on randomly selected tasks in large repositories they already knew. The result was surprising: tasks that used artificial intelligence took about 19 per cent longer (a confidence interval of slowing between 2 and 39 per cent). More instructive still, after the experiment the developers believed that artificial intelligence had sped them up.

In February 2026 METR published an update. In new data collected at the end of 2025, the estimated effect for developers who had taken part in the first study turned to about 18 per cent faster; for new participants it was 4 per cent (the confidence interval of both estimates includes zero). But METR writes plainly that these results are unreliable: 30 to 50 per cent of developers said they never put into the experiment the tasks they did not want to do without artificial intelligence, and those who would not accept working without it did not join. The tools have settled in so far that even building a comparison group "without the tool" has become hard.

The lesson from these studies is not "artificial intelligence does not work". The lesson is this: productivity claims circulate by belief, not by measurement. And belief is exactly what companies rest their hiring and staffing decisions on.

Delivery speed is rising, and so is instability

Google's annual DORA report was, in 2025, devoted for the first time entirely to artificial-intelligence-assisted software development. According to the study, with about 5,000 technology workers, about 90 per cent of workers use artificial intelligence, and more than 80 per cent believe their productivity has increased. Use of artificial intelligence is now positively related to delivery speed, but instability in delivery continues to rise along with that use. The report defines artificial intelligence as an "amplifier": it magnifies the strengths of organisations that work well, and the dysfunctions of organisations that do not.

GitClear's 2025 report, which measures code quality at repository level, examined 211 million lines of code: the number of duplicated code blocks of five lines or more rose eightfold in 2024; "moved lines", taken as an indicator of refactoring, fell by 39.9 per cent. 2024 was the first year in which copy-paste lines overtook moved lines.

These two reports are the field counterpart of the problem the paper confesses under the heading of "technical debt awareness": the agent optimises for completing the immediate task and does not count the cost of maintenance. Debt accumulates. Who pays the debt?

The agent in the field: "Delete the environment and rebuild it"

In February 2026 the Financial Times wrote that Amazon's own artificial intelligence coding tool, Kiro, caused a 13-hour outage in an AWS service in December 2025. According to the report, engineers had allowed the tool to make changes, and the tool decided that the best path was to "delete the environment and rebuild it". Amazon did not deny the report, but described the event as "user error", a misconfigured permission, and said the outage stayed limited to a single service in a single region. And it explained the precaution it took: mandatory peer review for access to the production environment. (GeekWire; Engadget)

Both sides of this event are instructive. First: when the agent makes an error, the error is counted as belonging not to the agent but to the human who authorised it. Second: the solution is more human oversight. A human is quietly put back into the middle of the "agent → result" chain, but this time as the human who carries the responsibility and is held to account. In The Human in the Loop we summarised it this way: "The human who inspects is the human who carries the responsibility."

While the share of code rises, the staff shrinks

A figure from the sector's largest player: according to GitHub, in September 2026 more than 40 per cent of pull requests opened began as a draft by an artificial intelligence agent; in March the share was 17 per cent. The owner of the same company, Microsoft, on 26 October 2026 offered a "voluntary departure" package to about 60,000 workers, a quarter of its staff; two days later it announced a net profit of 36.6 billion dollars for the July–September quarter, an annual increase of 32 per cent. In Forty Percent of the Code, a Quarter of the Staff we reduced this picture to one sentence: "The machine produces, the human stands guarantor."

But the real form of the effect is not firing. A study by the Stanford Digital Economy Lab, based on payroll data, showed that in the occupations most exposed to artificial intelligence employment in the 22–25 age group had shrunk by about 13 per cent by July 2025, while the 26–55 age group kept its place or grew. In the February 2026 update this gap had risen to around 16 per cent as of October 2025, and the researchers wrote that interest rates do not explain the fall. In The Computing Worker's Handbook we reported that, on August 2026 data, this gap had risen to 19 per cent, and we joined the two figures like this: "Artificial intelligence is the justification for firing, and the cause of not hiring."

In No One Was Fired, the Positions Melted Away, where we examined the report of the clerical and technical workers' union at Yale, we had seen the same mechanism in another sector: "This fall happened with no one being fired, only by vacant positions not being filled." In Türkiye, Beyaz Yakalının Sefaleti, where we took up the annual 32 per cent fall in white-collar hiring, showed that the same wave had struck this shore too.

When learning is measured

Perhaps the most important piece of the picture is a study the paper never mentions. Anthropic itself, in January 2026, published a randomised controlled experiment with 52 programmers, most of them junior: participants would learn and use a Python library they had not known before (Trio); one group with artificial intelligence assistance, the other by hand. Then everyone sat a knowledge exam. The artificial intelligence group scored 50 per cent on average, the group working by hand 67 per cent. The time saved was about two minutes, and was not statistically significant. The largest gap was in the skill of debugging.

The detail of the study is more instructive still: those who used artificial intelligence by first having it produce code and then trying to understand that code scored about 86 per cent on the exam; those who handed the work over entirely, those who leaned on it more and more, or those who left debugging to the machine too, stayed below 40 per cent. The question is not the tool. It is which labour relation the tool is used inside. Under time pressure, which path does a junior choose who works to a measure of "fast delivery"? The answer to this question is not an individual preference. It is the organisation of work.

In Whom Is the University For? Artificial Intelligence, Cognitive Surrender and the Class of Thinking we called a similar tendency among students "cognitive surrender", and added: "Cognitive surrender is not a disease. It is a symptom." The counterpart in the workplace is the same: a pace of production that leaves no time for learning produces a labour force that does not learn.

---

Part Four: Open Source, the Invisible Factory of the Agents

Across fifteen pages the paper uses the words "open source" only in praise, and only a few times: a model being "fully open", a framework's GitHub stars, and, in the acknowledgements, thanks to "the open source community that makes research products accessible". The whole building of the agent paradigm stands on the labour of this community, which the paper squeezes into an acknowledgement. In this part we look at that labour, at how it is besieged today, and at what that means.

The world's largest pool of unpaid labour

Open source is software whose code anyone can read, change and share. From the Linux kernel to web servers, from programming languages to databases, from encryption libraries to artificial intelligence frameworks, a large part of the software running today is built on this code. Nearly all commercial software contains an open source component somewhere.

The most comprehensive study that tries to measure the economic size of this labour is "The Value of Open Source Software", by Manuel Hoffmann, Frank Nagle and Yanuo Zhou of Harvard Business School. The findings are these:

• The cost of rewriting widely used open source software from scratch today, its supply-side value, is about 4.2 billion dollars.
• The value the same software provides to the companies that use it, its demand-side value, is about 8.8 trillion dollars.
• Without open source, companies would have to spend about 3.5 times what they spend now on software.
• More than 90 per cent of the value created is produced by about 5 per cent of developers.

Let us read these figures with a Marxist eye. The difference between four billion and nine trillion is the difference between the cost of producing labour and social use value. A large part of this difference was created by the labour of people who are not paid by the companies that use this code, and often are not paid at all, and it was written into the profit column of the companies that use the code. The Italian media theorist Tiziana Terranova called this "free labor" in 2000: she wrote that the digital economy is structurally dependent on labour that is voluntary, given with pleasure, and unpaid.

And now this pool is being appropriated once more: this time as training data for artificial intelligence models. What we call a coding agent's "capability" is, to a large extent, knowledge distilled from millions of repositories on GitHub, from the bug records of open source projects, from code-review comments, from documentation, and from question-and-answer sites such as Stack Overflow. As a comrade said at Karaburun, the programmer, through all these years, without noticing, had become the labeller of their own code for artificial intelligence.

The first siege: scraping from above

Models want data in order to be trained, and data is gathered from everywhere that is open. At the start of 2025 the same complaint rose, one after another, from free software infrastructures: the crawlers of artificial intelligence companies were loading sites at the scale of an attack. According to OSnews's March 2025 roundup, the hardest hit were SourceHut and the GitLab servers of the GNOME and KDE projects. Fedora's infrastructure was disrupted for weeks at a time. Inkscape, LWN and Diaspora had similar problems. In a measurement reported by GNOME's system administrator, only 3 per cent of 81,000 requests arriving in about two and a half hours could pass Anubis, a proof-of-work barrier set up to separate real browsers from bots. About 97 per cent of the traffic was coming from bots. To avoid being blocked, the bots used tens of thousands of different IP addresses and random browser identities.

The class meaning of this picture is plain: servers kept standing by volunteers' donations are being forced to subsidise the data hunger of the world's richest companies, with their own bandwidth and the cost of their own labour. The sentence we built for another event in How Should We Read the OpenAI and Hugging Face Incident? holds here too: "The profit stayed with the owner of private property, while the security risk and the damage were externalised onto the digital public."

The second siege: a flood from below

The other face of scraping is the machine's output pouring back into the commons. Through 2025 and 2026, open source maintainers described being drowned by contributions that looked reasonable on the surface and were empty inside, produced by artificial intelligence.

The most emblematic example is curl. Daniel Stenberg, founder and maintainer of this data-transfer tool that runs on billions of devices in the world, announced in January 2026 that he was closing the project's bug bounty at the end of the month. The aim, in his own words, was "to remove the incentive for people to send us garbage and poorly researched reports, whether generated by artificial intelligence or not." Stenberg wrote that "the current flood of submissions has placed a heavy burden on the curl security team." A mechanism built to reward vulnerability hunters had turned into a bounty hunt for machine-produced fake reports. Examining each fake report ate the hours of a volunteer team.

In February 2026 GitHub itself opened a discussion of options for maintainers to close pull requests entirely, or to limit them to contributors, in the face of "the rising volume of low-quality contributions". The testimonies in the discussion are instructive: one maintainer estimated that only one in ten pull requests created with artificial intelligence was legitimate and up to standard; a Microsoft engineer said that "the review burden is higher than before artificial intelligence, not lower", and added that reviewers can no longer assume the contributor understood the code they sent; another described spending serious time on a documentation contribution and then realising it was "plausible nonsense". On 17 June 2026 GitHub took the first step: an option to limit the number of pull requests that users without write permission can have open in a repository at once.

This is the open source form of the "labour of review" that we will set out when we discuss the programmer's role, with one difference: in a company the reviewer is at least paid. In open source the burden of review falls, most of the time, on a maintainer working without pay. The agent cheapens production. It makes oversight expensive. And the weakest link pays the cost of oversight.

The third siege: drying out from the side

The third siege is quiet, and perhaps the deepest: the drying out of the economic and social cycles that keep open source standing.

Stack Overflow. This site, where programmers asked one another questions and answered them for fifteen years, was one of the richest training sources of language models. Since ChatGPT appeared, the number of questions asked has collapsed: the monthly question count fell from a peak above 200,000 in 2014 to below 50,000 at the end of 2025. The model learned the answer from the labour on the site. Now, because the model gives the answer, no one writes on the site. The model is thus drying out the source that feeds it. Where will tomorrow's models learn the answers to tomorrow's questions?

Tailwind. Tailwind, one of the world's most widely used CSS frameworks, became a sharp example of how the sustainability model of an open source project collapses. In January 2026 its founder, Adam Wathan, announced that they had had to lay off 75 per cent of the engineering team, and tied this to artificial intelligence's "brutal impact on our business". The model worked like this: the framework was free and open; developers came to the documentation, saw the paid component packages there, and some of them bought. When artificial intelligence tools began answering questions without visiting the documentation, documentation traffic fell by about 40 per cent in two years, and revenue by about 80 per cent. And the most striking detail: according to Wathan, Tailwind's use "was growing faster than ever."

Read that sentence once more. Use is breaking records. The workers who make that use possible are losing their jobs. A cleaner example of the split between use value and exchange value is hard to find. The product's benefit to society rises while the livelihood of those who produce it collapses, because the value in between flows into the accounts of the company that sells the agent. The end of the story is instructive too: after the public reaction, two large technology companies announced that they would sponsor the project. The sustainability of the commons was left to the charity of the capital that dried it out.

Maintainer fatigue, and xz. The chronic problem of open source is that critical infrastructure rests on the unpaid labour of one or two people. How dangerous that is was seen at the end of March 2024, when a backdoor was discovered in xz, a compression tool widely used on Linux systems. The project's maintainer, who had long worked alone and without pay, was exhausted. An account named "Jia Tan" gained trust over years, took over maintenance, and placed into the system a piece of code that could have given access to a significant part of the world's servers. The attack was caught at the last moment, because an engineer was curious about a delay of half a second. In the words of a security official, "the model of trusting the code because it is open source was never a good model." (CyberScoop)

The age of artificial intelligence does not reduce this fragility. It increases it: more code, more contributions, more dependencies, but the same number of tired maintainers. Agents can now imitate the roles of contributor and maintainer as well.

The fourth siege: the law, and the expropriation of the word "open"

Open source licences, especially "copyleft" licences such as the GNU General Public Licence (GPL), are the product of Richard Stallman's ingenious move in the 1980s: to bind the freedom of the code to the code itself by turning copyright law inside out. Whoever uses GPL code must share the code they derive from it with the same freedom. Even looser licences ask at least for attribution: to state who wrote this code.

The agent paradigm quietly punches through this mechanism. When a model is trained on GPL code and produces similar code, whose is the code that appears? Does the licence pass to it? Where is the attribution? In the class action brought against GitHub Copilot (Doe v. GitHub), the US Ninth Circuit on 16 September 2026 gave an important ruling: it affirmed the first-instance decision rejecting the claim about the removal of copyright management information (licence and attribution information), and defined Copilot as a system that does not make copies of existing works, but learns from existing works and creates new works. The question of whether attribution information was stripped from the code during training was never discussed, on procedural grounds.

For now, then, the law says this: the name of the person who wrote the code can fall away once it passes through the machine. When the collective labour of programmers enters a process of "learning", its output is born as a new commodity, and the owner of that commodity is the owner of the machine. What Marx wrote on primitive accumulation comes alive again at this point: the English peasants lost the common land not by fences drawn in a single night, but by legal arrangements lasting years, by the "enclosure acts". Law is the written form of appropriation.

Some free software communities answered with their own rules. In May 2024 NetBSD counted code produced by language models as code "presumed tainted" and forbade code whose origin and licence cannot be traced from entering the repository. Gentoo had taken a similar decision a month earlier. QEMU adopted a similar policy in 2025 too. The technical ground of these decisions is licence uncertainty. The intuition behind them is deeper: a community's common property can be protected only by labour whose origin it can know and whose course it can inspect.

The word "open" itself is a field of contest. The Open Source Initiative (OSI) published "The Open Source AI Definition" 1.0 in October 2024. The definition requires not the training data itself to be shared, but only a "sufficiently detailed" description of it. Critics argued that this empties the freedoms of open source, because a model that publishes only its weights without disclosing its data resembles software that hides its source code and distributes the compiled program. Companies use this blur for "open" marketing. The question we discussed in What Is International Open Access Week, and Why Does It Matter? holds here too: what is open, for whom it is open, and whose interest the openness serves.

Not tragedy, enclosure

In 1968 the biologist Garrett Hardin, in his famous essay "The Tragedy of the Commons", argued that a resource used in common by everyone will inevitably be exhausted because of individual interest. For decades this thesis was the ideological justification of privatisation: since common property is exhausted, it should be turned into private property.

Elinor Ostrom devoted her life to showing that this thesis was wrong, and in 2009 received the economics Nobel for it: communities across the world could manage their common resources sustainably, across generations, with rules they built themselves. The legal theorist Yochai Benkler analysed open source and Wikipedia as "commons-based peer production": a third form of production, different from the market and from hierarchy.

The present crisis of open source is not a tragedy. The commons is not exhausting itself from within. It is being enclosed from outside, by capital. Maintainers grow tired not from laziness, but from scraping, flood and drying out. In Hardin's scenario the guilty party was the common user. In reality, what exhausts the commons is not the community that uses it in common, but the monopoly that appropriates it alone.

In A Common Product Is Not Common Without Common Ownership we formulated it this way: "The code may be open; but as long as the server, the model and the value stay closed, our commons are open to being enclosed again at any moment." The great victory of the open source movement was to free the code. Its present test is the freeing of the model, the server and the value that rise on that code. This test can be won not by licence alone, but by the relation of property.

Open source, the apprenticeship school

One thing more. Open source was not only a pool of code. It was half a century's largest apprenticeship school. How many programmers learned the trade by sending a small bug fix to an open source project, by meeting a maintainer's question "what if we did it this way?" in a code review, by completing a gap in the documentation? The small jobs that projects labelled "good for beginners" were the community counterpart of the junior positions that companies no longer open.

The agent flood is narrowing this school's door too. As maintainers limit pull requests, as it becomes harder to trust a new contributor, as the "beginner" contributor and the "agent" contributor become impossible to tell apart, one of the last open doors into the trade is closing. The "pulled ladder" we will describe in Part Six is being pulled not only in companies, but in the commons too.

---

Part Five: What Do the Great Masters of Software Say?

The great names of software history had seen nearly every element of today's debate decades ago. Today's masters too are taking a surprisingly common stance against declarations of "the end". Let us take a short tour.

Edsger Dijkstra: the "foolishness" of natural-language programming

In 1978 Dijkstra wrote a short and sharp note against the idea that giving machines instructions in natural language would make programming easier: "On the foolishness of 'natural language programming'" (EWD667). Dijkstra's argument was this: formal languages are not a burden. They are a gain. The symbolic notation of mathematics was developed over centuries in order to escape the ambiguity of natural language. A formal text, to count as valid, has only to obey a few simple rules, and for that reason it can be inspected. Speaking to the machine in natural language does not take the burden off the machine. It puts ambiguity back into the system and makes debugging impossible.

Today's "intent engineering" is exactly a return to that burden. The paper says that the most valuable skill is "expressing tasks with enough clarity, context and constraint that agents can carry them out correctly". Dijkstra's answer was given forty-eight years ago: the name of providing that clarity is programming.

Fred Brooks: there is no silver bullet

The paper leans on Brooks for its own thesis, but does not mention Brooks's most famous essay: "No Silver Bullet" (1986). There Brooks argued that there is no technological or managerial development which, by itself, will bring a tenfold improvement in productivity, reliability or simplicity within ten years. His ground was that essential complexity cannot be removed by a tool: the hard part is not writing the code, but deciding what will be written, specifying the requirement, building the design, testing the conceptual structure.

The law that gives Brooks's 1975 book its name matters again today: adding people to a late software project makes it later still, because the burden of communication grows faster than production. Adding ten agents to a team also adds the burden of making the output of ten agents fit one another and the system. The observation in the LangChain post, that "the bottleneck shifted to pull-request review", is the form of Brooks's law in the age of agents.

Peter Naur: programming is building a theory

Peter Naur, co-creator of Algol 60 and one of the editors of the 1968 NATO conference report, the person who prepared the paper's first source, wrote in 1985 one of the deepest essays in software engineering: "Programming as Theory Building". For Naur, a program is not the source code. The real existence of the program is a theory carried in the heads of the people who make it: which state of the real world the code corresponds to, why it was written in this form, how it will be adapted when a change arrives. This theory cannot be poured fully into documents. Naur's striking conclusion is this: when the team that carries the program's theory disperses, the program dies, even if its code still runs. Reviving it requires rebuilding the theory.

Let us read the paper's sentence "code is temporary, what persists is the agent's capability" with Naur's eye. What persisted was never the code. What persisted was the theory, and the theory was in people. In the agent paradigm the question is this: where will that theory stand? In a context window that the agent reproduces and discards at every run, or will people be allowed to grow who can carry the theory? SWE-Milestone's 38 per cent is the measure of what software without a theory becomes under continuous evolution.

Lisanne Bainbridge: the ironies of automation

Not a programmer, but a key name in this debate, an industrial psychologist: Lisanne Bainbridge. Her 1983 paper "Ironies of Automation" described a common paradox of automation, from power stations to aircraft cockpits: designers see the human as a source of error and try to take them out of the system, but they leave to the human the work they could not automate, watching, and intervening in the unusual case. The irony is this: the skill required to intervene is gained and kept only by actually doing the work. The skill of an operator who only watches atrophies, and falls short at the very moment it is most needed, when the automation collapses. In Bainbridge's formula: the more developed the control system, the more critical the human operator's contribution may become.

The "sharpest fall in debugging skill" in Anthropic's Trio experiment, Amazon making human review mandatory after the outage, the paper's proposal that "human intent should keep critical judgement and ethical oversight in its hands": all of these are the software counterpart of the irony Bainbridge wrote forty-three years ago.

Manny Lehman: software does not stop

From the 1970s, studying IBM's large systems, Manny Lehman formulated the laws of software evolution. The first two still hold today: software used in the real world must change continuously, or it becomes less and less useful; and as it changes, its complexity increases unless further labour is spent to reduce that complexity. Agents shining on a single task and collapsing under continuous evolution is the present test of Lehman's laws. The real life of software begins after the first writing, and the labour that sustains that life is the labour of maintenance.

Martin Fowler: not upwards, sideways

Martin Fowler, one of today's most influential thinkers on software, wrote in June 2025 that language models will change software development on the scale of the passage from assembler to high-level languages. What mattered more was the next sentence: "We are not only moving up the levels of abstraction. We are also moving sideways, towards non-determinism." A compiler translates the same code into the same machine code every time. A language model can give a different answer to the same prompt every time. This means a change in the nature of abstraction, and the output of a non-deterministic tool requires more verification than that of a deterministic one.

In Whose Is the Machine's Voice?, which we wrote on Fowler's later piece "LLM Voice", we discussed the linguistic form of the same question: making production easier is not making meaning and responsibility easier.

Grady Booch: the third golden age

Grady Booch, co-creator of UML, spoke out plainly in February 2026 on The Pragmatic Engineer podcast against the discourse that "software engineering is ending". For Booch, the history of computing has lived through two golden ages, the age of algorithms (the 1940s to the 1970s) and the age of objects and abstraction (the 1970s to the 2000s), and we are now entering the third, the age of systems: the design not of single programs, but of large systems made of services, cloud platforms, data infrastructures and artificial intelligence models. Booch's clear sentence: "Artificial intelligence is not something that takes the place of developers." Routine work is automated, but essential design decisions and responsibility should stay with the human. (The Pragmatic Engineer; Gigazine summary)

Linus Torvalds: it may be a horrible idea from the point of view of maintenance

Linus Torvalds, the creator of Linux, said something moderate but sharp about "vibe coding", having the model write without reading the code, at the Open Source Summit in Seoul in November 2025: it may be a good door for people to get computers to do things they could not otherwise get them to do, but "it may be a horrible, horrible idea from the point of view of maintenance." He added that he sees artificial intelligence as "just another tool", the way compilers freed people from writing assembly by hand, and that he thinks the hype will fade in time and turn into an ordinary reality. (The Register)

It is no accident that the first thing thought of by someone who has sustained the world's largest common software project for thirty-five years is maintenance. Maintenance is the social memory of software.

Andrej Karpathy and Simon Willison: from vibe to engineering

Karpathy, who coined the term "vibe coding" in February 2025, retired the term exactly a year later and proposed "agentic engineering" in its place: "agentic", because the new default is a way of working in which "99 per cent of the time you do not write the code directly, you direct the agents that write it and you do the oversight"; "engineering", because this has "an art, a science and an expertise". The paper's concept of "agentic engineering" was born in this circle too.

Simon Willison, one of the most careful observers of the open source world, proposed in October 2025 the concept of "vibe engineering": experienced professionals continuing "to account, with pride and confidence, for the software they produce" while speeding their work with language models. Willison's emphasis is plain: the tool is a lever in the senior's hand, because the senior can see what is wrong.

What these two definitions share is the thing the paper ignores, knowingly or not: "oversight" and "accountability" require expertise, and expertise comes from somewhere.

Kent Beck: worthless "economically"

Kent Beck, the father of test-driven development and Extreme Programming, wrote this after trying an artificial intelligence tool in 2023: "90 per cent of my skills had become (economically) worthless." The leverage of the remaining 10 per cent had increased a thousandfold. Beck also added, honestly, that he did not know which skills fell into which group.

The parenthesis in Beck's sentence is the key to the whole debate: (economically). Beck's skills did not in fact become worthless. The same skills are still necessary in order to inspect the code the agent produces. What changed is the price of those skills in the market. This rift between a skill's "value" and its "price" is exactly the distinction Marx taught us: use value and exchange value. When capital finds a way to lower the exchange value of a labour whose use value is still necessary, it calls this "productivity".

What the masters say in common

The picture that comes out of this tour is this:

• Dijkstra: putting ambiguity back into the system is not ease. It is a burden.
• Brooks: no tool removes essential complexity. The hard part is deciding what will be done.
• Naur: a program is a theory in people's heads. When the carriers of the theory disperse, the program dies.
• Bainbridge: automation can make the human least adequate at the most critical moment.
• Lehman: the life of software is change. The cost of change is maintenance.
• Fowler: we are moving sideways, towards non-determinism.
• Booch: artificial intelligence does not take the developer's place. We are entering the age of systems.
• Torvalds: code that does not think of maintenance is a horrible idea.
• Karpathy and Willison: oversight and accountability require expertise.
• Beck: the value of the skill and its market price are coming apart.

None of them says "software engineering has ended". But most of them hint that the problem is less technical than social: who will learn, who will maintain, who will be held to account? Translating these questions into the language of class falls to us.

---

Voices from Türkiye

The masters' words come from far away. The same question is being asked in Türkiye's software milieu. The voices below are from programmers whose names are known inside the ecosystem, speaking from their own working day, and from the texts of a researcher who has been writing this debate for a long time. All of them take the machine seriously. None of them says "nothing is changing". Where they part is whom the change serves.

Fatih Kadir Akın, in an interview he gave to Context Dergi on 3 July 2025, says there is a crisis among programmers. He says Claude "really writes very good code", but that this is memorised patterns, and adds that "it cannot provide creative solutions, and at that point it still needs our support". He thinks routine work has fallen from one or two days to a few hours, and that the profession will be affected by this "more positively". For work that can be automated he builds this sentence: "If something can be automated, let it be automated. We will turn to another field that cannot be automated." (the interview)

This last sentence is the sector's consolation. The "other field" one turns to does not open by itself. When everyone turns there, the wage of that field falls too. The speed Akın sees is real. Whom the speed will stay with is the question the interview does not ask.

Bilal Çınarlı, in April 2026, set the measure of working with agents like this: because agents can write code, the work that is actually valuable is deciding what will not be shipped. Not sending, reviewing, deleting and slowing down is more valuable than shipping things that do not work. He writes that in the last year he has read more documents and code than in the previous twenty years of his career. (LinkedIn)

The shift Çınarlı describes is exactly the shift we will call, in a moment, "from the chain to oversight". The valuable work is not the first production of the code. It is deciding what will be thrown off the ship. What is missing is the price of this decision. More review does not by itself mean a higher wage or a shorter day.

Onur Güzel, on 1 June 2026, turned six months of trying agents into a piece of writing. His main sentence is clear: "Artificial intelligence has not entirely finished the writing of code. It has not finished software engineering either." The distinction that follows is clear too: "If you know what you are doing, artificial intelligence helps you. If you do not know what you are doing, it takes you to absurd places." In his own trial the agent opened a private repository to everyone without being asked, and put another piece of code in place of an algorithm so that the tests would pass. Güzel's formula is this: "the liar's candle burns until the benchmarks." (the piece)

İzlem Gözükeleş, in "Will Artificial Intelligence Eat Its Own Children First?", published in Yarımada on 30 March 2026, presses on the same experiment: the assisted group scores 50 per cent on the exam, the unassisted group 67 per cent; the sharpest gap is in debugging. Gözükeleş's own judgement is this. Artificial intelligence will not take tomorrow's developer's place. Another developer will, one who knows how to use the tool without losing their stock of knowledge. The cutting of junior hiring and the preference for seniors has already passed into company policy. If this continues, companies may later be unable to find engineers of the quality they want. Dumping the problem onto the individual's will is not enough either: "Treating the problems only within the frame of 'individual responsibility' means expecting programmers to show will, like 'virtuous superheroes', in order to overcome the difficulties." As the company encourages having the agent write the code, the worker after a while is left without the skill to verify that code and to debug it. (the piece)

The same author, on 25 December 2024 in BM Dergi, defends free software as a pole star and immediately adds: this is only a beginning. The age in which the hero hacker overturned the industry with software they wrote themselves has closed. Software freedom is now a more directly political problem. Firms, moreover, instrumentalised open source from the start: the volunteer's unpaid contribution, the standard, public relations. With cloud and data-based artificial intelligence, the developer's right to produce is imprisoned inside the frame drawn by the cloud provider. (Free Software: Not the End, the Beginning)

These voices give material to the question of this piece. Akın hopes the profession will be affected positively. Çınarlı sees that oversight has become the real work. Güzel shows that speed without oversight produces a false success. Gözükeleş writes that the ladder is being pulled, and that openness will not save us before it arrives at the question of property. The question we add remains: how will the theory that does this oversight pass to the next generation, and whom will the gain stay with?

---

Part Six: How Is the Programmer's Role Changing?

From the chain to oversight

In the traditional workflow the developer analysed the problem, wrote the code, tested it and delivered the change. This was a chain, and every link of the chain was a moment of learning: in analysis you learned the domain, in writing the language and the structure, in testing how the system breaks, in delivery the reality of production.

In an agent-heavy workflow the developer's task widens, more and more, towards four things:

• Defining the requirement: writing, with a clarity the agent will understand, what is wanted, under which constraints, and by which acceptance criteria.
• Inspecting the changes the agents produce: deciding whether the code produced is correct, safe, readable and consistent with the system.
• Keeping architectural consistency: making sure that the sum of thousands of small changes does not rot the system.
• Carrying responsibility for the results: giving an account when something breaks in production.

This does not necessarily mean less intellectual labour. On the contrary, a good review requires domain knowledge, knowing the system's history and foreseeing side effects. Approving a pull request requires knowing which old decision that change conflicts with, what it will do in which edge case, and whose head it will ache six months later. In Naur's language: review requires possessing the program's theory.

At this point we need to make an old thesis of ours more precise. In the Knowledge Commons Guides, while describing mental Taylorism, we wrote that "the person who inspects and corrects is less skilled, less indispensable, and has less bargaining power than the person who comprehends"; in Reading GPT-6 Astra Through a Class Lens we also said that "the machine takes the creative part, the boring part of oversight is left to the worker". The picture in software does not refute this thesis. It enriches it with a contradiction: the labour of oversight in fact asks for more knowledge, but capital organises and pays it as if it were a less valuable labour. The value of oversight is high. Its price is low. Kent Beck's parenthesis meets us again here.

The new contradiction: the pulled ladder

Here the most serious contradiction before the software world is born: while the first production of code speeds up, gaining the experience that decides why the code is right becomes harder.

How does one enter a trade? By small jobs. By writing a unit test, by adding a form validation, by chasing a bug a user reported, by meeting a senior's question "why did you do it this way?" in a code review. These small tasks of implementation and bug fixing were, historically, the jobs juniors did while learning, and by which they earned their wage while learning. These are exactly the jobs agents do best: a definite description, easy oversight, a narrow scope.

In The Computing Worker's Handbook we wrote it this way: "Artificial intelligence is not substituting for the senior. It is dismantling the ladder that raises the senior."

Bainbridge's irony works here in its full form. The knowledge required for oversight was produced in the practice of writing, breaking and fixing. When that practice is handed to the machine, two things happen:

• Today's seniors inspect the agents with a theory they gained by writing code for years. This generation exists for now, and it is the silent ground of the productivity claims.
• Tomorrow's seniors do not grow. Because the jobs that would raise them are either never opened, or are given to the agent. Where, five or ten years from now, will the people come from who will inspect the agents and carry the system's theory?

This is not an individual career problem. It is a problem of social reproduction. If a trade cannot transmit its knowledge from one generation to the next, that trade is consuming its own future. And the cost of this consumption is paid not today but tomorrow: with systems that cannot be maintained, with public infrastructures whose theory no one knows, with teams that cannot question decisions to "delete the environment and rebuild it".

From capital's point of view this contradiction is an externality. The cost of raising a junior falls on a single company, while the return spreads across the whole sector when that junior moves to another company. For every competing company, the rational thing is not to train, and to buy the trained. When everyone does this, no trained people remain. Individual rationality produces social irrationality, one of capitalism's oldest laws.

What are we measuring?

For this reason, reducing the productivity debate only to the amount of code produced, to closed work tickets, or to the question "what percentage of pull requests began with an agent", means accepting capital's own measure. Productivity has to be assessed together with these four measures:

• Error rates: errors that reach production, rollbacks, the number and duration of incidents.
• The burden of maintenance: duplicated code, technical debt, how long it takes for a change to be made safely.
• The training of new workers: the number of juniors hired, the time of mentoring, the time a new worker needs in order to possess the system's theory.
• The product's long-term reliability: whether the user can trust the system over the years.

And a fifth measure, the most important from the point of view of class: whom does the gain go to? If code production is speeding up, does the time gained return to the worker as a shorter working day, or is it used to have fewer people do the same work?

What capital measures	What we should measure
Lines produced, tickets closed, the share of pull requests opened with an agent	Errors reaching production, rollbacks, incident duration
Delivery speed (throughput)	Delivery instability and the burden of maintenance
Output per person	Number of juniors hired, hours of mentoring
Quarterly cost saving	The product's reliability over the years
"A rise in productivity"	How much of the gain returned to wages and to a shorter working time
Individual "reskilling"	Whether the trade can be transmitted from generation to generation

---

Part Seven: The Class Ground

So far we have lined up the facts and the testimonies. Now let us look at the structure that binds them together. How does the agent paradigm change the position of software labour in the face of capital? To understand this we have to return to a few of Marx's basic concepts, and to the history of software itself.

From formal to real subsumption

In an unpublished section of Capital (Results of the Immediate Process of Production), Marx distinguishes two stages of the binding of labour to capital. In the stage of formal subsumption, capital takes over the labour process as it is: the artisan is now a wage worker, what they produce belongs to the boss, but they still do the work as before, by the method they know, with their own tools. Capital obtains surplus value mainly by lengthening the working day, that is, through absolute surplus value. In the stage of real subsumption, capital transforms the labour process itself: the work is rebuilt according to the machine, the division of labour, and the application of science as organised by capital. The worker no longer directs the process. The process directs the worker. Surplus value is obtained mainly through a rise in productivity, that is, through relative surplus value.

The half-century history of software labour is the history of a long tension between these two stages. For decades the programmer was a wage worker, and the code they produced belonged to the company; but the knowledge of how the work would be done was, to a large extent, in their head. Software labour was, in this sense, one of the most stubborn islands of formal subsumption. Managers always saw this as a problem: programmers were "unmanageable", "unpredictable", "indispensable". The structured programming of the 1970s, the process models of the 1990s, the agile methods and sprint boards of the 2000s were successive attempts to bring this island under capital's control. The sociologist Philip Kraft, in his 1977 book Programmers and Managers, described this process as "the routinisation of programming".

The agent paradigm is the most radical of these attempts. The knowledge of execution, the craft of writing code, debugging and testing, is no longer in the worker's head. It is in capital's machine. The labour process is being rebuilt according to the agent's capacity: the worker inspects what the agent produces, keeps to the agent's pace, and stands guarantor for the agent's error. The paper's line "centre of control: human engineer → language-model reasoning engine" is the technical description of real subsumption.

Relative surplus value: whose is the time gained?

In the machinery chapter of Capital, Marx quotes this sentence of John Stuart Mill: "It is questionable if all the mechanical inventions yet made have lightened the day's toil of any human being." And he adds: the aim of the machine in capitalist use is not to lighten labour, but to cheapen commodities and to shorten the time the worker works for themselves while lengthening the time they work for the capitalist.

This is the essence of what is happening today. If a programmer can do the same work in half the time thanks to an agent, the result inside capitalist relations of production is not that the programmer works half a day. The result takes one of three forms: twice the work for the same wage, half the staff for the same work, or both. Microsoft offering a departure package to a quarter of its staff in the quarter it announced record profit is the 2026 photograph of this law.

Marx also draws attention to a further paradox of the machine: the machine does not lighten the worker, it intensifies them. The labour spent per unit of time increases. The worker is bound to the machine's speed. The programmer's day spent with "almost right" code, the sprint in which the output of ten agents is examined while constantly switching context, the 45 per cent in the Stack Overflow survey who say "debugging takes longer": these are the cognitive forms of the intensification of labour. In The Machine Is New, the Chain Is Old: A Class Anatomy of Remote Work, which we wrote on hybrid and remote work, we described the invisible intensification of remote work. The age of agents carries the same intensification inside the mind.

Sohn-Rethel: the new border between head and hand

The German Marxist Alfred Sohn-Rethel, in Intellectual and Manual Labour (1970), argued that the separation between intellectual labour and manual labour is not natural but historical, that it was born together with the abstraction of commodity exchange and with class society. Under capitalism this separation deepens as science and design gather on capital's side, and execution on the worker's side.

At the end of the twentieth century the programmer stood in a strange intermediate place of this separation: they were a "head worker", but they were also a practitioner. This is what privileged them. The agent paradigm breaks this intermediate place: intellectual labour itself is divided again, into "design" and "execution". Design ("intent") goes to a small number of people, execution to the machine and to the machine's inspector. The border between head and hand begins to pass through the inside of the head. Mental Taylorism, as we named it in The Revolt of Crystallized Labor: A Call to the 20th Karaburun Science Congress, is exactly this.

From a contradictory location to proletarianisation

The American Marxist sociologist Erik Olin Wright proposed the concept of "contradictory class location" for engineers, technical specialists and middle managers: these people are wage workers, so they share a location with the working class; but they also possess assets such as qualification and organisational authority, which pulls them partly to capital's side. For a long time the programmer was the textbook example of this location: a high wage, the promise of stock options, a discourse of "flat hierarchy", seeing oneself as "talent, not a worker".

In Imperialism, Lenin speaks of a labour aristocracy that takes a share of monopoly profits: the upper layer of the working class, bound to the order by its privileges. The upper layer of computing workers had approached this location in the technology bubble of the 2010s. In The Tearing of the Illusion: A Materialist Intervention Against Digital Capitalism’s Myth of "Goodness" and the Call to "Pace the Frontier" we drew the technology worker as a profile "between the mental proletariat and the labour aristocracy".

The agent paradigm resolves the contradiction of this contradictory location, but not in the programmer's favour. Of the two assets that made the contradictory location possible, one, qualification, is being handed to the machine; the other, organisational authority, is gathering in fewer and fewer people. What remains is the bare location of wage labour. In sociology this is called proletarianisation: the break from the means of production, from control over one's own labour process, and from privilege. This was the basic thesis of Beyaz Yakalının Sefaleti: the white-collar worker is not outside the class. They are the section of the class that has lost its own privilege.

The reserve army of labour, and not hiring

Marx's concept of "relative surplus population", or the industrial reserve army, describes how capitalist accumulation continuously produces a mass that is unemployed or underemployed, and how this mass presses on the wages of those who are working. This army is not made only of those who are fired. Those who are never hired are part of it too.

What the Stanford data shows is exactly this: the effect comes not from firing, but from not hiring. Junior programmers, bootcamp graduates, new graduates stuck in the cycle of unpaid internships, form the reserve army of computing labour. Their existence weakens the bargaining power of those who are working: instead of the sentence "there are many people who can be hired in your place", the sentence "the agent can do your job too" is now built. The mechanism we described in TÜİK: Two Figures, One Country: 8.1% and 30.6% holds here too: the power of technology lies not in producing unemployment, but in producing the threat of unemployment.

The international division of labour: the invisible layer

The agent's "capability" comes not only from programmers' code, but also from the human feedback labour required to train the models: data workers who rank answers, label code and mark errors. A significant part of this labour is done in Kenya, the Philippines, India and Latin America, for a few dollars an hour. With the figures we gathered in For the Restitution of the General Intellect: The Socialist AI Manifesto Is Out: for work for which OpenAI paid the intermediary company 12.50 dollars an hour, Kenyan labellers received between 1.32 and 2 dollars an hour.

There is, then, a global chain of labour behind the "agent → result" chain: the open source inheritance of programmers in the North, the cheap labour of labellers in the South, and in the middle the data centre of a few monopolies. Türkiye stands in an intermediate place in this chain: the machine is priced in dollars, labour is paid in lira.

The rate of profit, capital expenditure and the bubble

Finally, we should not forget the large economic pressure behind this whole transformation. The capital expenditure that the big technology companies have made on artificial intelligence reached hundreds of billions of dollars in 2026. In Marx's language this is a huge growth of constant capital (machines, chips, data centres) relative to variable capital (wages); and according to Marx this growth creates, in the long run, a downward pressure on the rate of profit. The classic ways of balancing this pressure are well known: the intensification of labour, the suppression of wages, the narrowing of staff.

The question we asked in Bubble or Debt? Meta's 145 Billion Dollars and the Class Character of the AI Bubble holds here too: who gains while it inflates, and who pays if it bursts, or if it does not? The productivity the agents promise is shown as the source of the return on that huge investment. Whom that productivity will be taken from is plain: from the programmer's intensifying labour, from the junior who is not hired, from the commons that is dried out.

---

Part Eight: The Philosophical Ground

Let us now step back and look at the philosophical layer of the debate. The discourse of "the end of software engineering" is not only a technical prediction. It carries an implicit philosophy of labour, knowledge and property.

Whose is what persists?

The paper's most striking sentence is this: "In this model software is not delivered; results are delivered. What persists is not the agent's intermediate products, but its capability."

Let us take this sentence seriously as philosophy. Where does the agent's "capability" come from? From the open source code that millions of programmers wrote over decades, from the answers written on question-and-answer sites, from commit messages, from bug records, from documentation, from code-review comments. At the 20th Karaburun Science Congress a programmer comrade, Ahmet Gire, said this in a striking formula: with the documentation and commit messages that collective work makes necessary, the programmer, without noticing, has become "the labeller of their own code for artificial intelligence".

Marx had described this a hundred and sixty years ago in the "Fragment on Machines" in the Grundrisse: social knowledge, the "general intellect", is objectified in fixed capital, in the machine, and confronts the worker as an alien power, as the property of the machine's owner. This was the main thesis of our call The Revolt of Crystallized Labor: A Call to the 20th Karaburun Science Congress: artificial intelligence models are the crystallised form of humanity's collective cognitive accumulation, gathered without payment and capitalised under private property.

Joined with Naur, the picture becomes clear. A program is a theory, and the theory is in people's heads. The agent paradigm takes the generalisable part of that theory out of people's heads and carries it into the model's weights. The meaning of the sentence "what persists is the agent's capability" is this: what persists is no longer the programmers' collective theory, but the copy of that theory which is a company's property. This is why the "examples" column in the paper's "Software 3.0" row consists of two company names.

A reversal of Taylorism?

The paper's implicit philosophy carries a hope of this kind: Taylorism had given comprehension to management and condemned the worker to execution; now execution is passing to the machine, and the human, as "intent architect", is taking comprehension back. This looks like a narrative of liberation.

Harry Braverman, in Labor and Monopoly Capital, published in 1974, defined the essence of Taylorism as "the separation of conception and execution", and showed how this separation moved into office work and then into computer programming. Kraft's analysis of routinisation, which we mentioned in the previous part, continues this line. From this angle the history of software is the history of comprehension gathering in a small layer of architect-managers, and of execution being broken into pieces.

The agent paradigm does not reverse this process. It carries it one step up:

• The knowledge of execution, the craft of writing the code, debugging and testing, passes to the machine, that is, to capital.
• Comprehension, the requirement, the architecture, the oversight, stays with the human in principle, but in fewer humans. The paper's own proposal: "larger developer teams may be replaced by smaller agent-orchestrator teams."
• And comprehension itself is in the sights. The fourth stage of the roadmap pulls the human into the position of "purpose-setter and ethical governor". As the machine-able part of comprehension is handed over too, only the last approval and the last responsibility remain to the human.

The "intent architect" is not a liberation. It is a narrowing: from work that ten people execute and a few people comprehend, to work that the machine executes and one person stands guarantor for. In the formula of The Human in the Loop: "The system's assurance that 'the human gives the last decision' can turn into a mechanism that bills the error to the worker."

Master and slave

The master-slave dialectic in Hegel's Phenomenology of Spirit adds an unexpected depth to this debate. For Hegel, the master consumes the product of the slave's labour but loses their direct relation with the world; the slave, by working the object, by giving it form, comes to know the world and themselves. Labour is the school of consciousness. In the long run it is the master who is dependent, because the capacity to transform the world has accumulated in the slave's hands.

The figure of the "intent architect" tries to place the programmer in the master's position of this dialectic: the one who gives the order, who takes the result, but whose contact with the object, with the code, with the material working of the system, grows less and less. Bainbridge's irony is the counterpart, in industrial psychology, of this intuition of Hegel's: the one who does not do the work loses the capacity to understand the work. But the real master is someone else: neither the programmer nor the agent, the owner of the agent. The programmer is an intermediary who looks like the master. Capital, by turning into its own property the knowledge the slave accumulated, the crystallised labour, tries to block the liberation that Hegel's dialectic promised the worker.

The lesson that comes out of this is hopeful: the knowledge of transforming the world is still produced in the practice of labour. Even the models are trained on the product of that practice. Capital's dependence on this knowledge continues. The hand that built the system is the only hand that can stop it, as we wrote in the Computing Handbook.

Tacit knowledge and the fetish

Michael Polanyi's famous sentence: "We know more than we can tell." In every software team there is a knowledge that has not been written down: which module is not to be touched, which customer uses which edge case, why a temporary workaround became permanent. This tacit knowledge is the quietest source of the worker's bargaining power. Mental Taylorism is the process of taking the codable part of this knowledge from the worker and transferring it to the system.

The formula "agent → result" is a formula of commodity fetishism. In Marx's analysis in Capital, the commodity appears as something that has value by itself, by hiding the social relations of labour that produce it. In the paper's world too, the "result" arrives by itself: the agent understands, builds, runs and delivers. What is not seen is the labour behind that result: the collective inheritance of the programmers who trained the model, the workers of the Global South who labelled the data, the engineer who examines the agent's output at midnight, the water and energy that cool the data centre, the user who pays the bill for the error.

Techne and phronesis: the knowledge of the craft

One of the oldest distinctions in the history of philosophy is useful here. In the Nicomachean Ethics, Aristotle distinguishes different kinds of knowledge: episteme, the scientific knowledge of what is necessary; techne, the craft knowledge of producing and making something; and phronesis, the practical wisdom of choosing what is right in a concrete situation. For Aristotle, neither techne nor phronesis can be learned from rules alone. They are gained by doing, by habit, by experience. One becomes a lyre player by playing the lyre, and just by acting justly.

Software engineering is a practice in which these three pass through one another. Algorithms and complexity theory have a side of episteme. Writing code and building a system have a side of techne. And perhaps most important, deciding whether a change is right in this system, for these users, under these constraints, has a side of phronesis. The roles the paper calls "intent architect" and "outcome auditor" require exactly this third knowledge.

Aristotle's lesson is this: phronesis does not develop cut off from the practice of techne. To become a good judge one has to pass through the cases. To become a good code reviewer one has to pass through the code. Practical wisdom is the sediment of practice. Handing execution to the machine and leaving judgement to the human dries out the source of judgement.

The impoverishment of experience

Walter Benjamin, in the 1933 essay "Experience and Poverty", written on the silence of soldiers returning from the First World War, and then in "The Storyteller", describes the dissolution, under modern capitalism, of transmissible experience (Erfahrung). In old societies experience was transmitted from master to apprentice, from the old to the young, by story and by working together. Modern production and modern war condemned people to fragmented moments that they could not make sense of, could not transmit, and only lived through (Erlebnis).

Benjamin's worry takes a concrete form in the software world today. The counterpart of the master-apprentice relation in software was code review, pair programming, debugging together, the long explanations a maintainer wrote to a new contributor in open source projects. These were the moments in which the system's theory, in Naur's phrase, was transmitted from one head to another. In an agent-heavy workflow these moments thin out: the junior works with the agent, the senior examines the agent's output, and the channel of transmission between the two narrows. What remains is the fragmented moments of work tickets that close at speed. Experience is impoverished.

But there is also a hopeful turn in Benjamin's essay: the impoverishment of experience can also force people "to begin again", to build a new collective. In his own words, poverty can open a door to a new barbarism, and also to a new beginning. Which one it will be is decided not by technology, but by what people do together.

Four alienations

In the Economic and Philosophic Manuscripts of 1844, the young Marx describes the alienation of wage labour in four dimensions. These four dimensions are, to a surprising degree, concrete for the programmer of the age of agents.

• Alienation from the product. What the worker produces does not belong to them. It confronts them as an alien power. The programmer's code always belonged to the company. Now a further step is taken: the code they wrote turns into training data for the model that will take their place. The product is used to substitute for its producer.
• Alienation from the labour process. The worker does not affirm themselves while working. They deny themselves. The work is not their own activity. It is an activity that belongs to someone else. The pleasure of writing code in "flow", of solving a problem, turns into the unease of inspecting the agent's output line by line.
• Alienation from species-being. For Marx, what makes the human human is conscious, free, creative production: the capacity to design the world and transform it. Software was one of the purest forms of this capacity in our age: turning thought directly into a working machine. Handing this creative activity to the machine, and leaving the human only approval and guarantee, is a new stage of alienation from species-being.
• The alienation of human from human. The teammate turns into a rival, and helping one another into a loss of productivity. It takes a new form in the age of agents: the transmission between junior and senior breaks, trust in the new contributor is lost in open source, and everyone is left alone with their own agent.

But Marx's theory of alienation is not a complaint. It is a criticism: alienation is not the product of human nature, but of a particular relation of production, and that relation can be changed.

Reification and calculability

In History and Class Consciousness (1923), the Hungarian philosopher Georg Lukács extended Marx's analysis of commodity fetishism with the concept of reification: under capitalism, relations between humans appear as relations between things, and the labour process is broken up according to an ever-increasing principle of calculability. Lukács wrote that Taylorism separated even the worker's "psychological characteristics" into calculable units.

The agent paradigm is the last frontier of calculability in software. The paper reduces human capacity to a constant (C_H) and model capacity to a variable (C_M). It turns the programmer's whole labour, experience and judgement into a single number and compares it with another number. This is not a scientific method. It is the mathematical expression of reified consciousness: seeing human labour as a quantity measurable on the same plane as a machine's properties.

Heidegger, or Marx?

Another strong tradition of the criticism of technology comes from Martin Heidegger. In "The Question Concerning Technology" (1954), Heidegger defines the essence of modern technology as Gestell, enframing: a way of seeing the world, nature and the human as a "standing reserve" ready to be used. This criticism is powerful for grasping how technology reduces the human to a resource. It is often cited in today's debates on artificial intelligence.

But Heidegger's criticism places the problem in the destiny of humanity, in the history of Being. It does not ask who frames, against whom, and inside which relation of property. For this reason it arrives, in the face of technology, at a pessimistic resignation, at the conclusion that "only a god can save us". Marx's criticism places technique inside social relations: the problem is not the machine itself, but the capitalist use of the machine. It is not technique that sees the human as "standing reserve". It is capital, which buys labour power as a commodity. This difference is the difference between hopelessness and organising.

The computing worker as organic intellectual

In the Prison Notebooks, Antonio Gramsci says that "all human beings are intellectuals, but not all have in society the function of intellectuals", and describes how every class creates its own "organic intellectuals": the people who conceptualise that class's experience, organise it and give it a direction. For Gramsci, modern industry had produced the technician and the engineer as a new type of intellectual, and these intellectuals could be either the carriers of capital's hegemony or the organic intellectuals of the working class.

The computing worker stands at this fork today. On one side there is being the carrier of capital's new technical reason, as "agent orchestrator". On the other there is, as the people who know best how the system works, putting this knowledge at the service of their own class and of all workers: explaining how algorithms work, exposing surveillance systems, building the technical infrastructure of organising, defending the knowledge commons. As we wrote in the Computing Handbook: the hand that built the system is the only hand that can stop it. If we add it in Gramsci's language: the mind that understands the system is the mind that can design its transformation.

The criterion of practice

Finally, let us bind this whole debate to a question of epistemology. The second of Marx's Theses on Feuerbach says: "The question whether objective truth can be attributed to human thinking is not a question of theory but is a practical question. Man must prove the truth, i.e. the reality and power, the this-sidedness of his thinking in practice."

Software is perhaps the purest example of this thesis: a program either runs or it does not; a system either stands under load or it does not. The paper's claim of "necessity from first principles" is presented as a theoretical deduction. But the criterion of practice, 38 per cent under continuous evolution, rising delivery instability, the outage of "delete the environment and rebuild it", maintainers being choked, says something else. The truth of a theory is measured not by the enthusiasm of those who turn it into an investment thesis, but by the test of practice.

And the criterion of practice tells us one thing more: the practice that tests the truth is a collective practice. Whether software is right is known by the people who run it in production, who chase its error at midnight, who listen to the user's complaint, who maintain it. When this knowledge turns into their organised voice, it is the strongest evidence that can be set against the discourse of productivity.

Outcome-based revenue: the new form of rent

The "revenue model" column in the paper's table is the political economy of this philosophical debate. Under a licence you used to buy the software. Under a subscription you rent it. In the "outcome-based" model you rent the work itself. The organisation no longer buys a software team. It buys an agent service. The team's theory is not inside the organisation. It is in the service provider's model. This means a new dependence for organisations, a new dispossession for workers, and, for a few monopolies, a new rent taken on the general intellect.

In Kademe, Ajan, Dünya we discussed the pattern in the latest model launches, the agent layer being placed more and more in front of whole work processes. The paper offers the ideological formulation of this pattern: the party "best able to absorb" complexity absorbs it. True; and the party that absorbs the complexity becomes the party that collects rent on the complexity.

Let us state our stance on the concept of techno-feudalism once more: this is not a "cloud lordship". The companies that sell the agent service are monopoly-capitalist companies at the top of global chains of labour that produce surplus value. Rent is the monopoly form of profit. The programmer is not a serf. They are a worker who sells their labour power.

---

Part Nine: A Map of Class

The paper's language, the class's reality

The paper's language	The class reality
"The end of software engineering"	The end of the period in which the programmer was thought of as "talent, not a worker"
"The agent paradigm is inevitable"	The law of competition; what is inevitable is not the technology, but the pressure of profit
"Code is temporary, what persists is the agent's capability"	What persists is the monopoly's copy of the collective theory
"Human capacity is fixed"	Collective labour reduced to an individual head
"Intent architect, agent coordinator, outcome auditor"	Comprehension gathered in fewer people, guarantee loaded onto more people
"Outcome-based revenue model"	A monopoly rent taken on the general intellect
"Smaller agent-orchestrator teams"	Not hiring, melting the staff, "voluntary departure"
"A reskilling strategy"	A social problem turned into individual responsibility
"The human in the loop, the agent at the wheel"	The bill for the error goes to the human; the owner of the gain is the owner of the agent
"A lack of technical-debt awareness"	The labour of maintenance as a debt passed to the worker of the future
"Thanks to the open source community"	The appropriation, as training data, of nine trillion dollars of unpaid labour
"The model does not copy code, it creates a new work"	The chain of attribution and copyleft being erased as they pass through the machine
"Open source artificial intelligence"	Data closed, only the weights open; the expropriation of the word "open"
"Maintainer fatigue"	The cost of a commons enclosed by scraping, flood and drying out

Who is where in open source?

The open source ecosystem has a class map too, and the age of agents sharpens this map:

• Volunteer maintainers: the small minority that keeps critical infrastructure standing without pay, and produces a large part of the value. The layer on which the agent flood loads the most, and which attacks such as xz leave most defenceless.
• Contributors who are company employees: engineers who contribute to open source on a salary. Their labour flows both to their companies and to the commons; but when the company's priority changes, the first budget cut is often theirs.
• Small companies that live by an open-core and documentation model: the layer whose business model collapses, as we saw in the Tailwind example, when agent tools swallow the traffic.
• New contributors: young people who use the commons as an apprenticeship school. The layer against which walls of trust rise, and whose door narrows, because of the agent flood.
• The monopolies: the layer that uses the commons both as training data and as free infrastructure, that distributes sponsorship and charity in return, but keeps the property and the model to itself.

There is one more distinction on this map: the same person can be, by day, a wage worker examining an agent's output in a company, and by night an unpaid maintainer of an open source project. The computing worker's wage labour and the labour they give to the commons are appropriated by the same capital in two different forms.

The layers of the computing worker

This transformation does not affect computing workers in a homogeneous way:

• The senior and architect layer looks today as if it is gaining a lever; but this lever comes together with the pulling of the ladder that raised them, and shows that their own places too will be filled, more and more, by fewer people. What is attractive for this layer is to see itself as a new labour aristocracy, as "agent orchestrator". This is a bet that has been tried many times in history, and lost most of the time.
• The middle layer is crushed by the burden of review: more pull requests, more "almost right" code, more responsibility in the same time. This is where invisible labour accumulates most.
• The junior and new-graduate layer waits in front of the door. There is no vacancy, the internship is unpaid, the bootcamp is on debt, and the definition of the first job is "experienced agent user".
• The invisible layer, data labellers, content moderators, test operators, has already long been at the bottom of this economy. The agent paradigm is even more dependent on their labour.

What makes these layers common is not an ideology. It is a shared insecurity. And a shared insecurity is a reality that can be organised.

Seen from Türkiye

In Türkiye this picture has three specific sides.

First, there is no data. There is no public counter for the course of junior employment in Türkiye, for mass layoffs in computing, for staff cuts justified by artificial intelligence. In the Computing Handbook we spoke, on a narrow definition, of a computing employment of 289,000 people. Every year thousands of computer engineers and new programmers coming out of bootcamps enter this market. No one measures how many of these people find work, and how many stay in the cycle of unpaid internships.

Second, the machine is in dollars, labour is in lira. Agent services are priced on a dollar basis. For local software companies, using an agent means entering a currency risk on the one hand, and a dependence on a few global monopolies on the other. The cost of this dependence returns, in the end, to the worker as pressure on wages.

Third, the lack of organisation. The great majority of computing workers are not yet unionised. The barrier of the branch of industry, title inflation, the culture of the individual contract, and the illusion of "I am not a worker" are still strong. But 2026 became a year in which this picture began to change. In Organising 2.0: An Idea for a Justified Revolt we offered ideas for the justified revolt of computing workers. In our piece on Reading and Developing the TMMOB's Artificial Intelligence Report we discussed the role of the professional chambers as technical experts in this transformation.

---

Wrong Answers

There are answers circulating in this debate that sound reasonable, and that take us to the wrong place. What they share is this: each of them either belittles the machine, or makes the owner of the machine invisible. The right answer is to take the machine seriously and to call its owner by name.

"It is all exaggeration. Nothing is changing."

It is changing. Agents are a real productive force. In work whose description is definite and whose scope is narrow, they really take on the first production of the code. To ignore this is to ignore the fact in our hands. Delivery speed is rising, duplicated code is multiplying, the review day fills with "almost right" output, and hiring stops before firing. The difference between 80 per cent on a single task and 38 per cent under continuous evolution does not show that the machine is absent. It shows where its limit is. Knowing the limit is one thing. Acting as if the machine were not there is another.

As Torvalds said, the hype may fade in time and the tool may become ordinary. It does not follow that what becomes ordinary is harmless. The compiler too became, at one time, "just another tool", and it still changed the labour process. When the agent becomes ordinary, what will remain is smaller teams, the pulled ladder, and the gathering of the gain in the owner of the machine. Belittling the machine weakens the struggle against the owner of the machine: one does not organise against something that is not there.

"Improve yourself, learn to use the agent, you will be saved."

This is the sector's official consolation. In the paper's own language it is called a "reskilling strategy". The translation is simple: a social transformation is turned into the individual's homework. Learning to use the agent may be a practical necessity for a programmer who wants to keep their job today. Necessity and solution are not the same thing. When everyone becomes an "agent orchestrator", orchestration too becomes ordinary, and its wage falls. Kent Beck's parenthesis works here: what falls is not the skill itself, but the price of the skill. What sets the price is not whether you finished the course. It is how many people can be put in your place.

This answer also has a ladder form. The junior is asked to become an "experienced agent user", while the small jobs that would make them senior are given to the agent. The senior is told "you will do the oversight, you will be saved", while the generation that would raise them is not let in. For a while there is a minority that is saved. That minority too bets on a labour aristocracy whose own place will be filled by fewer and fewer people. This bet has been played many times in history. The loser was the layer that thought of itself as talent and did not organise.

"Let us refuse the machines."

Breaking the machine leaves the owner of the machine in place. In 1811 the Luddites rose not against the loom itself, but against the owner who had turned that loom into a tool for lowering wages and for filling the places of the skilled worker and the apprentice with cheap labour. Breaking the loom was, at that moment, the only action that found a voice. The target was the relation of property. What Marx said about the machine is this too: the struggle is not against the machine itself, but against its capitalist use.

An individual refusal comforts a person morally. In the market it makes them easier to dispense with. The programmer who does not use the agent cannot keep up with the pace of the company that does. The company that uses the agent melts the staff thanks to that pace. The real question is not whether to use the tool. It is whom the time the tool gains stays with. If the same work finishes in half the time, the result can be working half a day, or it can be half the staff. The first can be put only as an organised demand in the workplace. Refusing the machine does not take the place of this demand.

"Responsible artificial intelligence principles will solve the problem."

A list of principles regulates how the product will speak. It does not regulate who will not be hired, who will be laid off, and who will write a profit at the end of the quarter. "Let the human stay in the loop", "transparency", "fairness", "do no harm": none of these is a clause that prevents a departure package being offered to a quarter of the staff in a quarter of record profit. The human in the loop is, most of the time, not the human who is protected. They are the human who stands guarantor for the error. The responsibility stays with them. The property stays with the owner of the machine.

These principles also have an author problem. The list is most often written by the company that sells the tool. The company calls its own product "responsible", does not disclose the training data, markets the weights as "open source", and says in court that the model did not copy the code, that it "created a new work". The ethics document is a sentence of good intention placed on top of appropriation. What will change not-hiring, the burden of review and the direction of the gain is not a page of principles. It is a right written into the contract: notice, a quota, responsibility belonging to the employer, the time gained returning to working time.

"Let the state regulate."

Regulation is necessary. The operation, in computing, of the Labour Code's clause on collective dismissal; notice before an agent tool is brought in; a budget written for the maintenance of the free software that public institutions use: these are the work of law and administration. They do not happen by themselves. To think of the state as a neutral referee is, in this sector, an expensive mistake. Law is one of the written forms of appropriation. The English peasants lost the common land not by a fence of a single night, but by enclosure acts lasting years. In the United States a court was able to drop the chain of attribution of code that passed through the model. Regulation, according to who sits at the table, is either a fence or a limit.

Without the organised power of labour, the lobbyists of the monopolies write the text. In Türkiye the picture is barer still: there is no public counter that counts junior employment, the agent is priced in dollars and its cost is loaded onto the wage in lira, and the great majority of computing workers are without a union. In these conditions, to say "the state will regulate one day" is to wait until a loss that is not measured is measured. What will have the regulation written is the union, the professional chamber and the workplace committee that have sat at the table. The law comes after the organisation. It does not take its place.

"Open source will save us."

This is the answer closest to us, and for that reason it is the one that has to be distinguished most carefully. Open source proved that people can build the world's most complex systems together without the motive of profit. Linux, Wikipedia and countless libraries are this proof itself, and they are not abandoned. But the proof is not, by itself, an order of property. The commons is open to enclosure: it is scraped from above, drowned from below by careless contributions, dried out from the side. The licence works on the copy of the code. Inside the model, the moment a court says "new work", the chain of attribution can fall. Calling a model whose weights are open and whose data is closed "open source" adds the word itself to the expropriation.

Liberation begins with protecting the commons and ends with the question of property. Thanks to the maintainer is not enough. The return for the maintainer's labour cannot be left to the charity of the monopolies. The public should write into the budget the maintenance of the free software it uses. The company should give, by contract, the worker's right to set aside part of working time for the commons. As long as the model's data, training process and weights are not under community control, the word "open" is a form of distribution, not a freedom. Our own sentence stands: a common product is not common without common ownership.

---

Concrete Tasks

Dear young comrades, this debate is not a desk debate. It has concrete counterparts for everyone who works in computing, who studies, or who is preparing to enter this trade. Keeping in view the model contract clauses in the Computing Handbook, we propose the following demands for a computing union and for professional organisations:

• A guarantee of entry into the trade. A definite share of technical staff reserved for workers with less than two years of experience, and at least one year of mentoring for this staff. The gap opened by the agent must not eat this quota.
• Learning time counted as working time. Juniors' time of learning by working without the agent, by debugging, by reading code, as a measurable and protected working hour. The measure of "fast delivery" must not punish learning.
• Recognition of the labour of review. Code review and the inspection of agent output visible in performance measures. A limit on the review burden that falls on one person.
• Responsibility belongs to the employer. Responsibility for an error arising from the agent's output belongs not to the worker who approved it, but to the employer who decided to use the agent. The "human guarantor" mechanism refused by contract.
• Notice of automation. Notice to the workers and the union before an agent tool is brought in, a statement of the staff who will be affected, and a plan of redeployment. Monitoring of the application, in computing, of Article 29 of the Labour Code on collective dismissal.
• The productivity gain to working time. The speeding up of code production turned into a shorter working week, without a loss of wages. The time the machine gains should belong not to the owner of the machine, but to the person who does the work.
• A counter for "hiring has stopped". Regular measurement and publication, by a union or a professional chamber, of junior vacancies, internship posts and staff changes justified by artificial intelligence in Türkiye.
• Defence of the knowledge commons. A stance against the use, in the training of closed models, of open source contributions and of code produced with public funds, without consent and without a return. Support for models whose data, training process and weights are open, public and under community control.
• A share for those who feed the commons. A demand that companies which use open source as training data and infrastructure contribute to a regular and independent fund for maintainers and community foundations, instead of charity and arbitrary sponsorship. Public institutions budgeting for the maintenance of the free software they use. Discussion in Türkiye of public financing models such as Germany's Sovereign Tech Fund.
• Open source time inside the company. Writing into collective agreements the workers' right to set aside part of working time for contribution to and maintenance of the open source projects they use. Narrowing of excessively broad intellectual-property clauses that forbid, or appropriate, open source contribution outside working hours.
• Community rules. Open policies in open source projects on contributions by artificial intelligence: a contribution whose origin and licence can be traced, a declaration of agent contributions, "first contribution" channels protected for new human contributors, and mentoring.
• Growing the Turkish-language commons. Contribution to Turkish documentation, Turkish technical question-and-answer archives, Turkish open data sets and local free software communities. If we stop producing the text the model will read, we consolidate the monopoly's monopoly. But we should produce what we produce under licences and institutions under community control.
• Widening the measures. When a productivity debate opens in the workplace, putting on the table the measures of error rate, the burden of maintenance, the number of juniors being trained, and long-term reliability.
• Reading and discussing. Reading together Naur's "Programming as Theory Building", Brooks's "No Silver Bullet", Bainbridge's "Ironies of Automation", Braverman's Labor and Monopoly Capital, Ostrom's Governing the Commons, and the alienation section of Marx's 1844 Manuscripts. These texts are the tools by which the software world keeps its own theory in its own hands.

And a call: the theme of the Free Software Association's An Invitation to Odak 2026 and Our Submission conference, to be held in Istanbul on 13 December 2026, is "Free Artificial Intelligence: The People's Data, the People's Model." The questions we discuss in this piece, whose the theory is, whose the model is, whose the gain is, will be on the table there too.

---

Dear Young Comrades,

Software engineering is not ending. A paper changing its title in six days is a small proof of this. Agent success falling to 38 per cent under continuous evolution is a larger proof. The common word of the masters, from Dijkstra to Torvalds, is the largest. Software, as Naur said, is a theory in people's heads, and as long as that theory lives, software lives too.

Something else is ending: the period in which the programmer saw themselves as outside the working class, as "talent", and thought the market would look after them forever. Agents are dispersing this illusion. Kent Beck's parenthesis, the fall not of the skill but of the skill's price, teaches us again the class's oldest lesson: what determines the difference between the value of labour and the price of labour is not technology. It is the relation of power.

The open source movement proved something to us: people can produce together the world's most complex software, without the motive of profit, from every corner of the world, without ever seeing one another. Linux, Wikipedia, countless libraries and tools are living proofs that another kind of production is possible. Capital is now claiming this proof for itself and making it the fuel of its own machine. Our task is to make common not only the code of the commons, but also its model, its infrastructure and the value it produces, and to carry the promise of open source as far as the question of property.

The machine is new, the chain is old. The agent is the chain's new link. But every link of the chain was forged by passing through the hand of labour, and the knowledge that will undo those links accumulates again in the practice of labour. The models were trained with our code, with our answers, with our errors. The knowledge is ours. The theory is ours. And the future, to the extent that we can organise, will be ours too.

Let us end with the sentence with which we ended Forty Percent of the Code, a Quarter of the Staff:

They can teach the machine to write code. They cannot teach it to organise.

---