Friction was load-bearing: nine years of git before Claude Code and eight months after

The trigger

On August 29 a post appeared on Hacker News: “Ask HN: How to break Claude Code addiction?”. The author is a professional developer who works remotely. By the end of the day he stops reading the code the agent writes and keeps going, “one more bit”, late into the night. This did not happen before. Two lines from the post are worth quoting as they are.

“I don't want to give up the chance of another little ‘hit’ from it.”

“Vibe coding doesn't feel as ‘hard’ as work, so I can just keep doing.”

The post got 16 points and 24 comments. That is not a trend, that is one person. But on the way to me it became a trend. My digest bot, which reads HN and posts a morning summary to Slack, turned it into “companies depending on a single tool” and suggested a blog post about vendor lock-in. The word “vendor” does not appear in the post. This is how a topic gets inflated: a personal observation becomes a corporate risk after three retellings.

The post is not alone, though. On HN this year: “How do you handle skill atrophy from using coding agents?” (June, 34 points), “I'm Done Using AI” (June; one commenter: “sitting in front of Claude prompting until 5am”), and three Show HN posts with skill-atrophy tests: Dev atrophy test, Atrophy, Chestnut. When a small industry of diagnostic tools appears around a symptom, the symptom is probably real.

I decided to check on myself. I have something none of the studies I found have: nine years of commit history without AI and eight months with Claude Code, on one person, with an exact start date.

My data

My first Claude Code session was on January 6, 2026. Before that I did not use AI for code at all: no autocomplete, no chat. Everything before that date was written by hand.

I went through all 23 repositories on my disk, took my commits and removed duplicates by hash. For each month I counted five things: commits per active day, median lines changed per commit, share of commits outside 09:00–19:00, share at night (22:00–06:00), share on weekends. The time is the author timestamp from the commit, in my own time zone. The nine-year column below is the average over 2017–2025; single years vary.

	2017–2025, nine years	2026, January–August
Commits per active day	3.8	17.1
Active days	~185 per year	211 in eight months
Median lines changed per commit	17	64
Commits outside 9–19	22%	36%
Commits at night	9%	19%
Commits on weekends	8%	17%

One caveat on the baseline: I am not only a developer — I also run the business, management fills the daytime, and coding often slides into the evening. In 2017 and 2018, when I was building a processing system for digital gift cards, 39–42% of commits fell outside 9–19. Against every year from 2019 to 2025, the 2026 shares are still higher across the board.

The break is visible to the month. December 2025: 3.2 commits per day. January: 8.8. February: 15.5. May: 21.6. August: 23.6. June was the peak in timing: 54% of commits outside working hours, 34% at night.

From the Claude Code side it looks like this. By late April: 637 sessions and 148 thousand messages. Prompts per day: 44 in February, 77 in March, 103 in April. From March through May I opened Claude Code on 89 days out of 92. In April, on 27 days out of 30 the last prompt came after 22:00. August, from the transcripts: 28 of the first 30 days, nine of them weekends; about four hours of active agent work per day (a lower bound); on 22 of those days the last activity was after 22:00.

Degree of delegation: 17–19 agent messages per one of mine. In July and August: 1,840 messages from me against 32,500 from the agent. My median response time to the agent is four minutes. The slow link in the loop is now me.

The metric Multitudes reports for the industry (a 19.6% rise in out-of-hours commits) looks like this for me: from a 22% average to 36%, in absolute terms from about 13 to about 160 commits a month.

Two caveats, without which these numbers are not honest. First: 2026 is full-time work on one product, HRPulsar. Before, a large part of my commits was client work between other things. Part of the growth is a change of mode, not of tool. Second: with an agent, commit granularity is different — there are simply more commits for the same work. But the median commit also got almost four times bigger, so the volume grew either way. By how much exactly, I cannot say.

And one result I did not expect. The HN author describes how in the evening he slides from engineering into vibe coding: he stops reading and only presses “continue”. I checked this on my own prompts. Median prompt length during the day is 51 characters, after 21:00 it is 44. The share of pure “ok / go on / do it” prompts is 3% during the day and 4% in the evening. Flat month to month. Hours went up, but the quality of my control over the agent does not drop in the evening. This does not mean there is no problem. It means that for me the problem is not a slot machine — the unpredictable reward that keeps you pulling the lever.

The script I used is public: github.com/maximberg/git-hours. Plain Python, no dependencies, runs on any repository in a minute. I am curious what it shows for other people.

What is measured and what is not

Discussions of “Claude addiction” mix four different claims. They have different evidence behind them and should be separated.

Hours go up

Many anecdotes, little controlled data. Axios in April collected stories of developers whose agents are “frying their brains”; Karpathy says there he has been in a state of “AI psychosis” since December, with the share of code he writes by hand down from 80% to zero. LeadDev coined the term “AI vampire”. The numbers:

• LeadDev Engineering Leadership Report 2026: 45% of engineers work more hours than a year ago (38% in the 2025 report). Among staff level and above: 53%, up from 28% a year earlier.
• Multitudes, 500+ developers: +27.2% merged PRs and +19.6% out-of-hours commits. The report does not claim causation.
• HBR, Ranganathan and Ye, February 2026: an eight-month ethnographic study inside a 200-person tech company. People worked at a faster pace, took on more tasks and stretched work into more hours of the day, often without being asked. Management did not push. More simply became doable.
• Anthropic announced weekly limits in July 2025 because some subscribers ran Claude Code around the clock. The company's estimate: under 5% of subscribers.

The mechanism — variable reward, like a slot machine — is plausible, and it is the most common explanation. But I found no controlled study of it for coding agents. Chalkidis and Søgaard note that addiction and deskilling are rarely addressed in the AI safety literature at all. That confirms the gap, not the effect.

Skill goes away

Here the evidence is the best.

• Anthropic, January 2026, a randomized experiment: 52 mostly junior developers learn an unfamiliar library. The AI group scored 50% on the test, the no-AI group 67% — a large effect (d = 0.74, p = 0.01). The biggest gap was on debugging questions. The speedup from AI was about two minutes and not statistically significant. An important detail: those who asked for explanations did better; those who delegated everything did worse.
• Liu, Christian and co-authors, 2026: 1,222 participants. After about ten minutes with AI, people give up faster without it and solve tasks worse on their own.
• Anthropic's internal report, December 2025: employees report that Claude is involved in 59% of their daily work. The report names the “paradox of supervision”: supervising Claude requires exactly the coding skills that atrophy when you delegate everything to it.

This is not a 2026 discovery. Bainbridge, “Ironies of Automation”, 1983: an operator who watches automation loses exactly the manual skill he was kept at the console for. Parasuraman and Manzey, 2010: automation complacency is not cured by experience; it is about attention, not knowledge.

A caveat: these studies measure understanding right after the task. What happens after a year, nobody knows.

Productivity: perception against measurement

• METR, July 2025: 16 experienced open-source maintainers, 246 real tasks. Measured by the clock, they worked 19% slower with AI. They themselves expected a 24% speedup before the experiment — and after it they still believed they had been 20% faster.
• METR, February 2026: the result is declared outdated, a speedup is “likely”. But the new data is unreliable: developers refused to take part if they might have to work without AI; the pay was cut from $150 to $50 an hour; some ran several agents in parallel, and task time stopped meaning anything.

I would single out this trajectory. In eight months the study went from “AI slows you down” to “we can no longer measure this, because people will not work without AI”. That is dependence, recorded methodologically.

• DORA 2025, about 5,000 respondents: AI adoption now raises delivery throughput but still lowers delivery stability. The report's summary: AI is an amplifier; the value comes from the practices around the tool, not from the tool.
• GitClear, 623 million changed lines from 2023 to 2026: two-week churn up 15%, copy-paste up 41%, code duplication up 81%, refactoring moves down 70% against 2022.
• Stack Overflow 2025, 49,000 respondents: 84% use AI or plan to (76% a year earlier), 51% of professional developers use it daily. 46% distrust the accuracy, 33% trust it, 3% trust it “highly”. In 2024 43% trusted and 31% distrusted, but that scale had a neutral option, so the year-over-year comparison is approximate. The top complaint, from 66%: “almost right, but not quite”; for 45%, debugging AI code takes more time.
• Vella and Blincoe, May 2026, 95 people over six months: 84% feel more productive, while the share reporting a worse developer experience in at least one dimension rose from 14% to 27%. Flow state got worse; the work shifts toward supervision.

Vendor dependence

This is the claim my digest bot invented when it retold the HN post. The risk is real but ordinary. In August Claude was down on the 16th, the 17th and the 24th. Limits change unilaterally. This is the standard risk of any SaaS. It deserves a paragraph, not an article.

What friction was doing

All four claims have one explanation, and it is not dopamine. Writing code by hand did three jobs nobody designed.

It limited the working day. Typing code is physically tiring, and tiredness stopped you before willpower did. HBR describes intensification without pressure: nobody demanded it, people simply worked more. Nobody needed to demand it before; friction used to stop you.

It forced you to plan before coding. You could not “try it and see” in a minute, so you had to think first. One HN commenter puts it precisely: “Before AI you had to evaluate an idea, plan its implementation, judge if it is worth it or even doable. Now you just prompt and see.” Planning was not a virtue, it was a necessity.

It forced you to understand. You cannot write code without understanding it. You can accept code without understanding it. Anthropic's debugging result and the paradox of supervision are exactly about this.

The METR paradox is explained the same way. Effort was the indicator of work: if it is hard, you are working. The agent removed the effort, the indicator stayed, and now it lies. 19% slower feels like 20% faster.

The word “addiction” is imprecise here. The tool did not hook anyone. It removed a limiter that was holding the structure up, and nobody noticed it was a limiter.

My trade

I had the general picture before these numbers. And I continue in the same mode, because this is a deliberate trade for a specific phase.

What I buy. I build HRPulsar alone. Since the first tagged release in mid-April: 104 releases; the current version is 1.21.0. The product has 569 API endpoints, 24 domain modules, 142 migrations, about 240 thousand lines of Python and TypeScript (not counting tests), 4,594 backend tests and 74 e2e specs. Open source, an enterprise edition, a white-label instance at the first customer. Without the agent this would not exist. Not “would be slower” — would not exist.

What I pay. Hours: 36% of commits outside the working day; through spring, hardly a day without a session. Manual skill: I do not know whether I would pass that “atrophy test” from HN today. A year ago I would have.

Where the line is. Not in the tool, in the process. I hold it with a few rules written into the agent's instructions.

1. The agent does not release and does not push to the main branch. Release, sync to the public repository and deploy happen only on my explicit command, every time.
2. Understanding every line is replaced by tests and guards. The billing coverage test fails if a new function is not declared. The translation parity test fails if a key is added to only one language. The sync script refuses to publish if the tree contains enterprise code. I do not read every diff. I read what failed.
3. Before review the agent goes through a checklist and marks the items in the ticket. An epic is closed only after a run on an empty tenant, without demo data.
4. Everything I could lose by switching vendors is my code, not my tool. Open core, a standard stack, no dependence on a specific model in the architecture.

Which risks I accept. Supervision: where there is no test, I check worse than a year ago. Hours: for this phase, with one measurable commitment below. Code quality by GitClear's metrics I have not measured, and that is a gap I need to close.

What I do not do: give universal advice. My mode works because I have no team that has to read my code and no employer who will notice that I work at night. The HN author has both.

What follows from this

Measure your git. The share of out-of-hours commits before and after is one script run. Feelings mislead in both directions: METR's developers felt 20% faster while being 19% slower; I expected my evening prompts to degrade, and they do not.

Separate the four problems. Hours, skill, productivity and vendor need different fixes, but get discussed as one.

For skill there is a measured recipe. In Anthropic's experiment the best results came from those who asked the AI to explain, not only to do. That is a change in how you use it, not in how much.

For hours, the tool will not set the boundary. HBR showed that intensification happens without pressure from above, so stopping it from above will not work either, unless the person wants to stop. The HN author asked Claude to remind him when the working day was over. Claude forgot. Anthropic introduced limits when users started to overload its servers, not when they started staying up at night. That is a product gap, and so far it belongs to nobody.

In three months

I will publish the same metrics for September–November in December: out-of-hours commits, share at night, prompt length in the evening. If the trade stops being deliberate, the numbers will show it before my feelings do.