AI Is a Tool, Not an Excuse

My view on AI sits somewhere between Linus Torvalds and the statement taken by Codeberg’s community and Drew DeVault. That is a fairly wide range.

On one hand, AI coding tools can be extremely useful when the person using them knows what they are doing. On the other side, the technology is tied to job pressure, environmental damage, higher infrastructure costs, low-quality contributions, and a growing lack of trust between people working together online.

Those two views do not contradict each other. AI is a tool, but that does not settle who should use it or who should pay for it. In my opinion, calling AI a tool should not become an excuse for users to stop thinking or for companies to push their costs onto everyone else.

We have been through automation before

Manufacturing is an obvious comparison. Mechanization increased how much factories could produce and changed what human workers did. From a distance, history can make this look simple: people made things by hand, machines arrived, and society became more productive.

It was not that clean. Mechanization disrupted more than engineering. It changed textiles, agriculture, mining, transport, and the lives of the people whose work depended on them. Workers did not quietly accept every change either. The Luddites are still remembered because some workers resisted machinery that threatened their livelihoods and bargaining power. A Smithsonian history of the movement notes that many were skilled machine operators who objected to manufacturers using machinery to avoid established labour practices, not to technology in itself. Industrialization also brought pollution, dangerous working conditions, and new opportunities for owners to value output above workers.

I do not feel that machinery itself was a mistake, but I do feel that its trade-offs were not distributed evenly. The owner buying a machine could gain more than the worker whose job changed or disappeared. Society could benefit while particular people paid the price.

AI follows a familiar pattern, but the scale and speed are different. A factory machine usually automates a particular physical process. A generative AI system can be sold to developers, artists, writers, support teams, marketing teams, project managers, and many others through the same interface. Businesses do not need to rebuild a factory before trying it. They can add a subscription, change their expectations, and ask fewer employees to produce more work.

The International Labour Organization’s 2025 index estimates that one in four workers is in an occupation with some exposure to generative AI. It also says job transformation is more likely than outright replacement because most occupations still contain tasks requiring human input. Exposure is not the same as losing a job, but it shows how widely the pressure can spread.

That wider reach also gives the costs… well, a wider reach too. Mistakes can be generated faster, and poor work can be submitted to more communities. The infrastructure does not become free just because the prompt box is convenient. The International Energy Agency reports that data centres used about 1.5% of global electricity in 2024 and expects their demand to more than double by 2030, with AI as the largest driver of that growth. Its longer-term forecasts cover a wide range, so these are projections rather than a precise bill for AI alone. In the United States, the Department of Energy estimates that data centres could rise from 4.4% of national electricity use in 2023 to between 6.7% and 12% in 2028.

How I use AI as a coding tool

For me personally, I use AI extensively for implementation, but I do not ask it to decide what I am building.

I design the technology stack, choose the tools and libraries, decide how the problem should be solved, define the goals, and work out the requirements. The AI then helps code that design. Afterward, I review every change, run the automated checks, and test the behaviour manually.

I am not handing a vague idea to a machine and accepting whatever appears. I own the design, must be able to maintain the result, and verify the implementation. If it breaks, it is still my problem. “The AI wrote it” is not an acceptable answer to a user, colleague, or another maintainer.

This is close to the useful side of AI that Torvalds describes. He uses LLMs to prototype ideas in toy projects, even when the generated code is not usable as the final result. At the Linux kernel level, his standard is much higher. A machine-generated bug report should not simply be thrown over the fence for someone else to investigate. The person using the tool must take part, verify the problem, and help produce a real fix.

AI can make a skilled person faster, but speed does not replace judgement. It does not carry responsibility for a bad release or stay behind to support the code after the prompt has ended.

Where the costs go

AI tools plainly work. The stronger criticism is that the people receiving the benefit often do not pay the full cost.

Drew DeVault gives a direct example from SourceHut. He describes spending large parts of his working weeks defending the service from aggressive LLM crawlers. Those crawlers hit expensive pages, spread their requests across many addresses, and create outages for ordinary users. An AI company gets data. SourceHut pays for the traffic, mitigation work, interrupted priorities, and frustrated users.

Codeberg describes similar pressure on its own infrastructure. Its position goes further than crawler abuse. The organization argues that AI-heavy projects can consume storage, CI, and release resources far beyond the community supporting them. It also points to the review burden created by low-effort generated contributions and the mistrust that follows when maintainers can no longer tell whether a contributor understands what they submitted.

That concern is not limited to Codeberg. Curl maintainer Daniel Stenberg reported that roughly 20% of the project’s security submissions in the first part of 2025 were AI-generated junk, while only about 5% of all submissions were genuine vulnerabilities. Those figures describe curl rather than every open-source project, but they put a measurable review cost behind the broader complaint.

I have seen parts of that social cost myself. Workplaces can treat AI as a reason to expect the same output from fewer people. People can lose skills when they accept code they cannot explain. Communities become more suspicious when a polished contribution might be the start of a real collaboration or might be generated work that its submitter cannot maintain.

The 2025 Stack Overflow Developer Survey found the same tension at a larger scale. Among its respondents, 46% distrusted the accuracy of AI output while 33% trusted it. Twenty percent said they had become less confident in their own problem-solving, and 16% said it was hard to understand how or why generated code worked. It is a self-selected survey, not proof that AI causes skill loss, but it is enough to take the concern seriously.

This is where “AI is just a tool” becomes an incomplete defence. If my use of a tool saves me ten minutes but creates an hour of unpaid review for someone else, I have not made the work more efficient. I have transferred the work.

Self-checkout machines offer a smaller everyday version of the same issue. I do find self-checkout useful. But the usual implementation removes an employee, turns part of the job over to the customer, and watches that customer through cameras as if they are guilty until the system is satisfied. The convenience is real, but so are the transferred labour and surveillance. We should be able to acknowledge both without pretending the technology must be entirely good or entirely bad.

Assistance is not the same as abdication

I therefore draw a line between AI-assisted development and straight-up vibe coding.

The dividing line is not the percentage of characters typed by a human. It is whether a human owns the decisions, understands the result, verifies the work, and is prepared to maintain it. A project can contain a great deal of generated code and still have serious human oversight. A smaller patch can be irresponsible if its author submits it without understanding or testing it.

Communities are also entitled to draw stricter lines. A maintainer may decide that generated contributions create more work than they save. A nonprofit forge may decide that autonomous projects consume resources without building the human collaboration it exists to support. Their refusal is not a failure to understand the technology. It is a decision about what costs they are willing to accept.

My own rules are straightforward:

• I decide the requirements and design instead of outsourcing those decisions blindly.
• I review generated code, run the available checks, and test the behaviour.
• I do not submit generated bugs, patches, or explanations that I have not verified myself.
• I do not assume another person or community owes me the labour needed to clean up my output.
• I respect that some projects and communities do not want AI-generated work at all. (Also why I mainly use GitLab over CodeBerg or SourceHut lol).

AI coding tools are useful to me. I am not interested in denying that usefulness to make a cleaner political argument. But usefulness is not innocence. The more powerful and widespread a tool becomes, the more responsibility its users and providers have to account for the costs around it.

Use the tool if you can own the result. Verify what it gives you. Maintain what you publish. And do not make everyone else pay for your convenience.