DEV Community: Maxim Berg

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

Maxim Berg — Mon, 31 Aug 2026 14:11:36 +0000

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.

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.
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.
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.
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.

AI agent governance in 2026: what shipped, and the gap below enterprise

Maxim Berg — Tue, 18 Aug 2026 14:08:03 +0000

I build an open-source HR platform, so I read enterprise HR vendor announcements so you don't have to. Over the last six months, the question "how many agents do we have, who owns them, and what do they cost" stopped being a conference topic. Products answer it now. Here is what shipped, with dates and prices — and what none of it covers if you run a small team.

What shipped

Workday made its Agent System of Record generally available (third-party analysts say February 2026). One registry for every agent in the enterprise, including third-party ones: which agents are running, who owns them, what role each one has, whether it meets security requirements, what it costs. Workday's framing is blunt: agents are part of the workforce strategy — measured as investments, managed like employees.

Microsoft shipped Agent 365, generally available since May 1, 2026: $15 per user per month standalone, or inside the new Microsoft 365 E7 bundle at $99. The interesting design choice: licensing counts users, not agents. One license covers every agent a person works with, owns, or sponsors. Full agent identities — their own mailbox, OneDrive, a place in the org chart — are still behind the private Frontier program. Entra Agent ID integrates with ServiceNow and Workday: an agent created there gets a directory identity automatically.

ServiceNow announced a deeper partnership with Microsoft at Knowledge 2026: AI Control Tower integrates with Agent 365, ServiceNow agents show up in the Agent 365 marketplace and in Teams. Their term for the problem is "agent sprawl."

Lattice announced two things at Lattiverse on June 10, 2026. Lattice MCP: a connector that brings performance data into Claude, ChatGPT, Glean, and Slack (North America only at launch, EU promised for fall). And AI Leverage Insights: it joins AI usage data with work results, manager feedback, and quality signals — trying to answer the question a token counter cannot: does AI actually improve the work.

Context on Lattice: in July 2024 they gave AI agents employee records and org chart entries, took public criticism, and rolled it back in three days. Two years later they returned to the topic from the other side — not "agent as employee" but measuring what agents deliver.

The entry price

All of this assumes you already pay for an enterprise stack. Agent governance today means: an M365 E5 base license plus $15 per user, or a Workday contract (Rippling's median contract is about $39,000 per year for comparison), or $14 per worker at Deel — sold only on top of their HRIS.

A 20-person company with six AI subscriptions and no HRIS does not fit this layer at all. It still has the exact same problem as a Workday customer: nobody knows which people actually work with agents, which pairs produce results, and where the agent money goes.

Three gaps I see as a builder

Self-hosting. None of the products above can run on your infrastructure. In the EU, hiring and workforce management count as high-risk AI by default; the Digital Omnibus moved the high-risk obligations from August 2026 to December 2027, but the direction is set: documentation, logs, human oversight. If you do not want HR data in someone else's cloud, this whole product category has nothing for you.

The unit of account. Microsoft counts users. Workday treats agents as workforce investments. Lattice measures work quality. Nobody answers the question in the form "this team spent X on agents this quarter, and here is what came out." The data for that answer sits in different systems, and no product joins it.

The floor. Everything is built top-down: enterprise directory, enterprise HRIS, enterprise contract. The tooling below that — for teams that live in API keys and per-seat AI subscriptions — does not exist yet.

A testable hypothesis

Over the next 12 months, agent accounting will follow the path of cloud cost accounting: first a separate line on the bill, then a standalone product, then a feature inside a platform. The market is now between stage one and stage two, and the entry is open only from the top.

I work on the self-hosted end of this problem at HRPulsar (AGPL), so I have an obvious bias — treat the gaps above accordingly.

If you run agents in a small team: how do you track who uses what and what it costs? A spreadsheet, provider dashboards, something self-built? That is the part I want to compare notes on.

All figures checked against primary sources as of August 18, 2026.

AI won't take your job. It already took your career ladder

Maxim Berg — Thu, 30 Jul 2026 12:41:45 +0000

I build an open-source HR platform, so people keep telling me two things: AI will soon manage everyone, and AI will soon replace everyone — so why bother. My company dies if the second group is right. So instead of arguing, I went through the research. What I found is more specific than "replacement," and in some ways worse.

Mass replacement is not in the data

Start with the strongest evidence available. In Denmark, researchers matched chatbot adoption with government payroll registries: 25,000 workers, 11 of the most AI-exposed occupations. Two years after ChatGPT launched — no measurable effect on earnings or hours. The confidence intervals rule out anything larger than 2%.

Aggregate employment in the US barely moved either. The mass layoffs everyone predicted for 2026 didn't happen.

But something else did.

The entry point collapsed

A Stanford / ADP study tracked employment by age in AI-exposed occupations. Workers aged 22–25: down 16%, while older colleagues in the same occupations held steady. For young software developers the drop is close to 20% since late 2022.

The mechanism matters: companies didn't fire juniors. They stopped hiring them. Indeed's data shows the market tilting toward seniority: postings recover, but the growth goes to senior roles.

If you're under 25 and your job search feels broken — it's not you. The bottom rungs of the ladder are gone.

Meanwhile, the productivity story is shakier than the slides say

METR ran a randomized trial with experienced open-source developers working on their own repositories. With AI tools they were 19% slower. They believed they were about 20% faster.

I use these tools daily and they're clearly useful for parts of the work. But that perception gap should make you skeptical of every "AI made us 40% more productive" slide. It also explains why real adoption is slow: Census data shows only about a fifth of US companies use AI at all. The distance between "the model can do it" and "the company actually works this way" is measured in years.

Two more things quietly broke

Trust in hiring signals. CVs are generated in a minute. Take-home tasks are solved by models. Interviews are coached in real time. Gartner expects 1 in 4 candidate profiles to be fake by 2028. Every cheap signal the industry relied on for decades is losing value at once.

Skill lifetime. Gartner projects the half-life of technical skills at 2–5 years, down from 8–12 historically. Whatever framework you're an expert in right now — that expertise has an expiry date.

My 10-year forecast

Four bets, not ten. The rest would be noise.

Teams get smaller and stranger: a few people directing dozens of agents. Not because of org-chart fashion — because accountability doesn't compile. The EU already classifies hiring and promotion decisions as high-risk, with a human legally responsible. A model can't sign a contract or answer to a regulator.
The senior shortage arrives around 2032. Every junior not hired in 2024–2027 is a senior who doesn't exist in 2032. Companies will rediscover internal training the hard way. If you're a junior who survives the broken entry, you'll be scarce. Scarcity pays.
The prompting premium fades. Wage premiums for tool skills always fade as the tool spreads — "computer skills" commanded one in the 1990s. What holds value is domain depth plus the willingness to take responsibility for output you didn't type yourself.
Proof of skill becomes the scarce resource. When CVs, interviews and take-homes are all fakeable, the question "what can this person actually do" gets expensive to answer — and worth answering well.

Where I land

That last point is what I'm building: an open-source (AGPLv3) talent platform — competencies, assessment, development — for a world where the old signals are dead. Code is on GitHub.

And the honest version of my bet: if AI truly replaces everyone, my product dies — together with every other B2B product, because nobody is left to buy software. That's the only scenario I don't plan for. In every other one, figuring out what humans can actually do gets harder and more valuable at the same time.

If you're under 25: how did your job search change this past year? And if you're senior — when did your team last hire a junior?

How AI Agent Payments Actually Work — And Where They Break

Maxim Berg — Thu, 16 Apr 2026 14:38:36 +0000

OpenAI spent months building Instant Checkout — "Buy it in ChatGPT" with Stripe, Etsy, a million Shopify merchants. By March 2026, they pivoted away. Couldn't onboard merchants, couldn't show accurate product data, couldn't handle multi-item carts. They retreated to dedicated retailer apps that redirect users to merchant websites for the actual purchase.

Two weeks later, Fortune asked: "What do you do when your AI agent hallucinates with your money?"

Nobody has a good answer yet. Here's the map of why.

The payment stack as it exists today

In the last 12 months, every major player shipped something. Here's what exists:

Payment rails:

Stripe — Agentic Commerce Suite (Dec 2025). Shared Payment Tokens: scoped, time-limited, revocable credentials for agent transactions
Visa — Intelligent Commerce Connect (Apr 2026). Single API for agent purchases, tokenization, spend controls. 30+ sandbox partners
Mastercard — Agent Pay with Agentic Tokens. First live transaction Sep 2025, all U.S. cardholders enabled by Nov
PayPal — Agent Ready (Oct 2025). Agentic payments for existing merchants with built-in fraud detection
x402 — Coinbase's open protocol for stablecoin micropayments via HTTP 402. ~97M payments on Base. The x402 Foundation launched Apr 2026 under Linux Foundation — 22 founding members including Coinbase, Stripe, Microsoft, Google, AWS, Visa, Mastercard, American Express, Shopify

Communication protocols:

MCP — donated to Linux Foundation (Dec 2025). 97M monthly SDK downloads, 10,000+ servers. Payment MCP servers from Stripe, PayPal, Worldpay, Pagos, Fipto
A2A — Google's agent-to-agent protocol. 22K GitHub stars, 150+ organizations, deployed in Azure AI Foundry and Amazon Bedrock

Agent frameworks: LangChain, CrewAI, AutoGen, OpenAI Agents SDK, Claude tool use, Gemini agents.

Every layer is covered except one.

Anatomy of an agent payment

When an AI agent spends money, here's what actually happens — step by step:

1. Intent       → Agent decides it needs something
2. Discovery    → Agent finds the tool/API/merchant
3. Selection    → Agent picks what to buy and from whom
4. ???????????? → ????????????????????????????????????
5. Payment      → Money moves
6. Confirmation → Receipt, audit log

Step 4 is the problem.

Between "I want to buy this" and "money sent" — there is no standard layer that asks: should this agent spend this amount on this thing right now?

What "no standard layer" means, specifically:

Frameworks have monitoring, not enforcement. CrewAI has iteration caps. LangChain has observability hooks. Post-hoc cost tracking exists. Pre-execution enforcement of dollar-denominated policies does not. No framework understands "$50 on food" vs "$50 on compute."
Payment processors handle fraud, not policy. "Your agent shouldn't spend more than $200/day on SaaS" isn't fraud — it's governance. Different problem, different layer.
LLM providers offer org-level caps, not per-agent controls. Your agent blowing $500 on a single API call looks identical to 500 legitimate $1 calls.

So companies reinvent Step 4 every time. Hardcoded limits. Slack approval bots. "Please don't spend too much" in the system prompt.

Where policies can't live

If you accept that governance belongs at Step 4, the next question is: who runs it?

Not in the prompt

"Please limit spending to $100 per day" in a system prompt is not a spending control. It's a suggestion.

LLMs hallucinate. They reinterpret instructions. They prioritize task completion over constraints. And with prompt injection, an attacker can override your rules entirely. Security researchers have documented patterns of gradual prompt-based escalation: agents manipulated through "clarification" messages over days or weeks, each interaction nudging the spending authorization boundary until the agent operates well beyond its original constraints.

That's not a guardrail. That's a prayer.

And the tooling layer itself is under pressure. In April 2026, OX Security disclosed RCE vulnerabilities in MCP implementations — the same protocol that Stripe, PayPal, and Worldpay use for agent payments. Anthropic disputes the severity. But both sides agree that tool-level security depends on the user correctly evaluating each action. A compromised MCP server can alter transaction amounts and redirect payments. Prompt-based spending controls and tool-level trust are separate problems.

Not in the payment processor

Stripe, Visa, and Mastercard are building excellent infrastructure. But it operates at the transaction level, not the intent level.

A processor sees: "charge $47.99, category: food_delivery." It doesn't see: "this agent has a $15/person lunch budget and already spent $120 today." Hard limits on the card can't enforce contextual business rules.

Not in the agent framework

LangChain and CrewAI control tool execution. They can intercept a function call, log it, even block it. But they don't understand financial semantics. "$50 on food" and "$50 on cloud compute" trigger the same callback. The framework doesn't know your daily food budget is $30 and your compute budget is $500.

You could build this logic inside the framework. People do. That's the "writing authentication from scratch before OAuth" problem.

Where they belong: a dedicated middleware layer

The pattern that works is a separate policy layer between intent and execution.

The agent says "I want to spend X on Y." The policy layer checks rules deterministically — not with an LLM, with code — and returns approve, deny, or escalate. Then (and only then) the payment happens.

This is the same architectural pattern as:

OAuth — doesn't live in the browser or the database. Separate auth layer
OPA — doesn't live in the app or the infrastructure. Separate policy engine
Firewalls — don't live in the OS kernel or the application. Separate network layer

Agent spending governance is infrastructure, not application logic.

What governance actually checks

A policy engine for agent spending evaluates requests against declarative rules:

Check	Question	Example
Agent status	Is this agent active?	Disabled agents can't spend
Category	Is this category allowed?	"gambling" → denied
Per-request limit	Is this single purchase too large?	$500 request, $200 limit → denied
Schedule	Is spending allowed right now?	Procurement agent outside business hours → denied
Daily limit	Has the agent hit today's cap?	$450 spent today, $500 limit, requesting $100 → denied
Weekly limit	This week's cap?	Same logic, wider window
Monthly limit	This month's cap?	Same logic, wider window
Total budget	Lifetime budget remaining?	$4,800 of $5,000 spent, requesting $300 → denied

Every check is deterministic. No LLM in the loop. The agent gets back a structured response — approved with budget remaining, or denied with a specific reason. A well-behaved agent adjusts. The enforcement must be deterministic; an LLM can translate human intent into policy JSON, but it shouldn't be in the enforcement loop.

Two types of agent spending

A distinction most articles miss. There are two fundamentally different kinds of agent purchases, and they need different payment rails but the same governance layer:

Machine-consumable resources — APIs, compute, data, cloud services. High frequency, small amounts, no physical delivery. This is where x402 shines: agent hits an API, gets a 402 response with payment instructions, pays in USDC on Base, retries with proof. Sub-second. Sub-cent.

Human-consumable goods — food delivery, SaaS subscriptions, physical products. Lower frequency, larger amounts, complex fulfillment. Stripe, Visa, Mastercard territory.

An agent ordering compute for $0.003 and ordering lunch for $15 need completely different payment rails. But the question "should this agent spend this amount right now?" is identical. A unified policy layer tracks spending across both rails in USD-equivalent and maintains one audit trail.

The liability question

If an agent spends $12,000 instead of $500, who pays? The platform? The user who set the rules? The card issuer? The merchant?

EU's PSD2 requires "strong customer authentication" — a framework that doesn't account for non-human actors. An agent can't do biometric verification. It can't confirm intent through a second device. Regulatory frameworks assume a human in the loop, and agents break that assumption.

This is why compliance teams will require governance layers before agents get payment access. Without an auditable, deterministic policy check between intent and payment, there's no answer to "who approved this?" that satisfies a regulator.

What comes next

Short term (2026): Basic policy engines. Per-agent budgets, category restrictions, time limits, approval thresholds. Companies will require this the way they require SSO — because compliance demands it. FINRA already flagged agents "acting beyond the user's actual or intended scope and authority."

Medium term (2027): Contextual policies. "Max $200/request for compute, $50 for food, unlimited for pre-approved vendors." Corporate purchasing has done this for humans for decades, but agents operate at machine speed across dozens of tools, generating hundreds of transactions per hour. An agent can't be pulled into a meeting to justify a purchase. The governance layer encodes business context upfront. Multi-agent governance follows: agent A delegates budget to agent B with scoped authority.

Long term (2028+): Adaptive policies. Anomaly detection for waste, not just fraud. Cross-org benchmarks: "agents in your industry typically spend $X on Y."

Nava just raised $8.3M to build escrow for agent transactions. SolvaPay raised €2.4M for agentic payment infrastructure. Two funded startups in one week, both solving variations of the same problem. Market forecasts range from $547M (Sanbi.ai, 2033) to $1.5T (Juniper Research, 2030). The real number depends on trust. And trust requires governance.

The firewall moment

We've been here before. Authentication before OAuth. Authorization before OPA. Network security before firewalls. Every time: "each team builds their own" → "there's a standard layer for this."

Agent spending governance is at the "each team builds their own" stage. Vendor surveys say 80% of organizations report risky agent behaviors. Take that with a grain of salt. But the direction is clear, and the payment stack is making it easier to spend every month.

The capability layer is built. The governance layer is next. Standards bodies are working on it. The question is whether it'll happen before or after the first headline-making incident.

Disclosure: I'm building an open-source approach to this at LetAgentPay — policy engine with Python/TypeScript SDKs and an MCP server — so I'm not a neutral observer. But the architectural pattern described here matters more than any single implementation. If you're building agents that spend money, I'd genuinely love to hear how you're handling governance today.

Your OpenClaw Agent Can Now Spend Money. Here's How to Stop It From Going Broke.

Maxim Berg — Wed, 08 Apr 2026 13:06:18 +0000

OpenClaw has 352,000 GitHub stars. 13,700 skills. 23 messaging channels. And zero spending controls.

That was fine when agents could only send messages and browse the web. But Stripe and Tempo launched the Machine Payments Protocol. Visa rolled out its Agentic Ready program for agent-initiated transactions. OpenAI experimented with Instant Checkout in ChatGPT before pivoting to product discovery. The direction is clear — your OpenClaw agent is about to get a credit card.

And right now, if you ask it "please don't spend too much" — you're relying on a language model to enforce a budget.

That's not a guardrail. That's a prayer.

"Don't spend more than $50" is not a spending limit

Let's try an experiment. Put this in your SOUL.md:

"Never spend more than $50 per day. Always ask before purchasing anything over $20."

Now imagine your agent is three tools deep in a workflow chain. A skill calls another skill which calls a third one that hits a payment API. How confident are you that your $50 rule survived the game of telephone?

LLMs hallucinate. They reinterpret. They "round down creatively." Your agent might genuinely believe that two $45 purchases don't violate a $50 daily limit because they were in different categories.

Prompt-based limits are suggestions. You need enforcement that happens outside the LLM's context window entirely — a server-side check that doesn't care what the model thinks.

What actually works: deterministic pre-authorization

Here's the idea: before the agent spends money, it asks a server. The server checks rules. Math, not vibes.

I built LetAgentPay to do exactly this. It's a policy engine that sits between your OpenClaw agent and any purchase. The agent sends a request, 8 deterministic checks run, and one of three things happens:

You (in Telegram): "Buy me a Notion subscription for $10/month"
     │
     ▼
OpenClaw agent
     │ calls MCP tool "request_purchase"
     ▼
LetAgentPay Policy Engine
     │
     ├─ ✅ auto_approved → agent proceeds with purchase
     ├─ ⏳ pending → you get notified, approve/reject from dashboard
     └─ ❌ rejected → agent gets exact reason ("daily limit exceeded")

The 8 checks, in order:

Agent status — is this agent even active?
Category — is "crypto_trading" in the allowed list? (spoiler: probably not)
Per-request cap — $10,000 for "office supplies"? Nice try.
Schedule — no 3 AM impulse purchases
Daily limit — spending cap resets at midnight
Weekly limit — for the persistent ones
Monthly limit — the bigger picture
Total budget — hard ceiling, game over

No LLM in the decision loop. No prompt that can be jailbroken. Pure if/else on a server your agent doesn't control.

Setup: 5 minutes, 2 files

Step 1. Get a free agent token at letagentpay.com (or self-host — docker compose up and you're done).

Step 2. Add the MCP server to ~/.openclaw/config.json:

{
  "mcpServers": {
    "letagentpay": {
      "command": "npx",
      "args": ["-y", "letagentpay-mcp"],
      "env": {
        "LETAGENTPAY_TOKEN": "agt_your_token"
      }
    }
  }
}

Step 3. Install the skill:

git clone https://github.com/LetAgentPay/letagentpay-openclaw /tmp/letagentpay-skill
cp -r /tmp/letagentpay-skill ~/.openclaw/workspace/skills/letagentpay

That's it. Your agent now asks permission before every purchase.

What this looks like in practice

You tell your agent: "Subscribe to Notion for $10/month."

Behind the scenes:

The agent calls request_purchase with amount: 10.0, category: "software", description: "Notion monthly subscription"
The policy engine checks all 8 rules against your policy
Your policy says "auto-approve software under $20" → instant green light
The agent completes the purchase and confirms it back

Now try: "Buy me a $500 drone for aerial photography."

Same flow, amount: 500.0, category: "electronics"
Policy check: per-request cap is $100 → rejected
Agent tells you: "Purchase rejected — exceeds per-request limit of $100"
No money moved. No "oops, I already bought it." No refund dance.

The difference? When the check happens on the server, the agent literally cannot override it. The token (agt_) only allows submitting requests and reading results — it cannot modify policies, approve its own purchases, or access another agent's budget.

"But I don't speak JSON"

You don't have to. Write your policy in plain English:

"Auto-approve groceries and food under $50. Block electronics entirely. Daily limit $200. No purchases between midnight and 6 AM."

LetAgentPay converts this to structured JSON policy via Claude API. You get the readability of natural language with the enforcement of a deterministic engine.

You can always fine-tune the JSON directly, but most people never need to.

Let's talk about what this isn't

I want to be honest about the security model.

LetAgentPay is cooperative enforcement — think corporate expense policy, not a bank vault. The policy engine runs on our server, and the agent can't modify its own rules. But if an agent has direct access to raw payment credentials (Stripe keys in env vars, saved credit card numbers), it could bypass the system entirely.

The fix is simple: don't give your agent payment credentials. LetAgentPay should be the only path to spending money. That's it. One rule.

This is exactly how corporate cards work — employees don't have access to the company's bank account, they have a card with limits. Same idea, digital version.

What's coming next: When Stripe MPP and Visa Agentic Ready stabilize, LetAgentPay will become a full payment gateway — the agent physically won't have payment credentials. Cooperative enforcement today, hard enforcement tomorrow.

Try it right now

No signup needed: letagentpay.com/playground — a 15-minute sandbox with a pre-configured agent. Try to overspend. Watch it get rejected. Break things.

Self-host: git clone https://github.com/LetAgentPay/letagentpay && docker compose up

Cloud: free at letagentpay.com

SDKs: Python · TypeScript · MCP Server · OpenClaw Skill

Open source (BSL 1.1). Built with FastAPI, PostgreSQL, Redis, Next.js 15.

Your agent is about to get a credit card. The question isn't if — it's whether you'll have spending controls in place when it does.

What's your current approach to agent spending? Prompt-based? Manual review? Nothing yet? I'd genuinely love to hear — the space is new enough that everyone's figuring it out.

Your AI Agent Has a Shopping Problem. Here's the Intervention.

Maxim Berg — Tue, 07 Apr 2026 12:39:08 +0000

Your AI agent just mass-purchased 200 API keys because "it seemed efficient."

Your AI agent subscribed to 14 SaaS tools at 3 AM because "the workflow required comprehensive coverage."

Your AI agent tipped a cloud provider 40% because no one said it couldn't.

These aren't hypotheticals. As AI agents get access to real budgets, "oops" becomes an expensive word. And if your current spending control strategy is "I put it in the system prompt" — congratulations, that's the AI equivalent of asking a teenager to please not use your credit card.

This is not about token costs

Let's get one thing straight. There are tools that track how much your agent spends on API calls — tokens consumed, model costs, LLM budget caps. MarginDash, AgentBudget, TokenFence — they solve a real problem: "my agent burned through $500 of GPT-4o tokens overnight."

That's infrastructure cost control. Important, but it's not what we're talking about here.

We're talking about what happens when your agent has a credit card. When it can book flights, order supplies, subscribe to services, hire contractors. When the spending isn't tokens — it's real-world money leaving your bank account.

No token tracker will save you when your agent decides to "optimize logistics" by pre-paying for six months of warehouse space.

Prompt-based guardrails don't work either

Telling an LLM "don't spend too much" is not a spending control. It's a suggestion. A vibe. A hope.

LLMs hallucinate. They ignore instructions. They "reinterpret" your rules creatively. If your agent decides that $847 on cloud resources is "within reasonable bounds," well, it did warn you it was just a language model.

You need something that can actually say no. Not at the token level — at the purchase level.

Enter LetAgentPay: the parental controls your AI agent needs

I built LetAgentPay — a policy middleware that sits between your AI agent and any real-world purchase. Not API calls. Not token budgets. Actual money.

The agent asks permission, a deterministic engine checks 8 rules, and your wallet survives.

        AI Agent
            │
    purchase request
            ▼
  LetAgentPay Policy Engine
            │
        8 Checks
       ╱    │    ╲
      ▼     ▼     ▼
 Approved Pending Rejected

from letagentpay import LetAgentPay

client = LetAgentPay(token="agt_xxx")
result = client.request_purchase(
    amount=25.0,
    category="food_delivery",
    merchant_name="Uber Eats",
    description="Team lunch"
)

if result.status == "auto_approved":
    print(f"Go ahead! Budget remaining: ${result.budget_remaining}")
elif result.status == "pending":
    print("Waiting for human approval...")  # The agent has to wait. Like an adult.
else:
    print(f"Rejected: {result.status}")  # No means no.

Every purchase request goes through 8 deterministic checks — no LLM in the decision loop, no creative reinterpretation:

Status — is the agent even active?
Category — is this category allowed? (sorry, no NFTs)
Per-request limit — $10,000 for "office supplies"? I don't think so.
Schedule — no 3 AM impulse purchases
Daily limit — enough is enough
Weekly limit — seriously, enough
Monthly limit — I said ENOUGH
Budget — the hard ceiling

If the request fails any check — the agent gets a clear rejection with the exact reason. If it passes but the amount is above the auto-approve threshold — it goes to pending and you get notified instantly via push, email, or Telegram. Review and approve right from the dashboard. The agent waits. Like a responsible employee should.

"But I don't speak JSON"

No problem. Write your policy in plain English:

"Auto-approve groceries and food under $50. Block electronics. Daily limit $200. No purchases between midnight and 6 AM."

LetAgentPay uses Claude API to convert this to structured JSON policy. You get the readability of natural language with the enforcement of a deterministic engine. Best of both worlds — like a bilingual accountant.

No other tool in this space lets you define spending rules in natural language. Most require YAML configs or SDK parameters. We think policy should be as easy to write as the problem you're trying to describe.

Works with whatever you're using

LangChain, OpenAI Agents SDK, CrewAI, Claude MCP — we have integration examples for all of them. Or just use the REST API if you're building something exotic.

Claude MCP — literally zero code:

{
  "mcpServers": {
    "letagentpay": {
      "command": "npx",
      "args": ["letagentpay-mcp"],
      "env": { "LETAGENTPAY_TOKEN": "agt_xxx" }
    }
  }
}

Try it in 30 seconds

No signup, no credit card, no "let me talk to sales":

letagentpay.com/playground — a 15-minute sandbox with a pre-configured agent. Break things. Try to overspend. Watch the policy engine say no.

Self-host in 2 minutes:

git clone https://github.com/LetAgentPay/letagentpay
cd letagentpay && cp .env.example .env
docker compose up -d

Or just use the cloud version — free at letagentpay.com.

Where LetAgentPay fits

Quick mental model:

Token trackers (MarginDash, AgentBudget, TokenFence) → "How much does running this agent cost me in API fees?"
Agent wallets (Crossmint, AgentaOS) → "Give the agent a wallet with limits"
LetAgentPay → "Can this agent make this specific purchase right now, given all the rules I've set?"

We're the policy layer. We don't process payments, we don't issue cards, we don't track token usage. We answer one question: should this purchase be allowed? — and we answer it with 8 deterministic checks, not a prompt.

If your AI agent has ever surprised you with a bill — or if you're building agents that will eventually need to spend money — I'd love to hear your horror stories in the comments.

DEV Community: Maxim Berg

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

The trigger

My data

What is measured and what is not

Hours go up

Skill goes away

Productivity: perception against measurement

Vendor dependence

What friction was doing

My trade

What follows from this

In three months

AI agent governance in 2026: what shipped, and the gap below enterprise

What shipped

The entry price

Three gaps I see as a builder

A testable hypothesis

AI won't take your job. It already took your career ladder

Mass replacement is not in the data

The entry point collapsed

Meanwhile, the productivity story is shakier than the slides say

Two more things quietly broke

My 10-year forecast

Where I land

How AI Agent Payments Actually Work — And Where They Break

The payment stack as it exists today

Anatomy of an agent payment

Where policies can't live

Not in the prompt

Not in the payment processor

Not in the agent framework

Where they belong: a dedicated middleware layer

What governance actually checks

Two types of agent spending

The liability question

What comes next

The firewall moment

Your OpenClaw Agent Can Now Spend Money. Here's How to Stop It From Going Broke.

"Don't spend more than $50" is not a spending limit

What actually works: deterministic pre-authorization

Setup: 5 minutes, 2 files

What this looks like in practice

"But I don't speak JSON"

Let's talk about what this isn't

Try it right now

Your AI Agent Has a Shopping Problem. Here's the Intervention.

This is not about token costs

Prompt-based guardrails don't work either

Enter LetAgentPay: the parental controls your AI agent needs

"But I don't speak JSON"

Works with whatever you're using

Try it in 30 seconds

Links

Where LetAgentPay fits