DEV Community: arun rajkumar

I Got Obsessed With Killing Scrum. So I Built a World Out of 12 AI Agents.

arun rajkumar — Sun, 12 Jul 2026 16:09:21 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built Bodhiorchard — an open-source platform that replaces Scrum, Jira, and the team wiki with 12 specialised AI agents and a living 3D world you can actually walk around in.

I call the methodology Agent-Driven Development (ADD). Instead of story points, planning poker, and a graveyard of stale Confluence pages, the work lives in one place: a BUD (Business Understanding Document) — a single, vector-indexed source of truth that carries a feature from a Slack conversation all the way to production.

The agents handle the busywork I never wanted humans doing: triage, design drafts, tech plans, standups, test plans, estimation, retros. Your repos show up as trees in an orchard. Features are branches. The whole team walks around as avatars — WASD to move, emotes, houses you upgrade with points you only earn when something actually ships to prod and stays healthy.

The scoreboard is the part I'm proudest of: it rewards quality, not output. Ship a BUD to production: +1. A bug escapes to prod: -1. It scores the things AI is bad at and humans are good at.

Honest status: the platform, the BUD lifecycle, the code-dependency graph, skill profiling, and the 3D world are all live. The fully autonomous execution loop is still being built — today it's agents-assisted, human-in-the-loop. I'd rather undersell it than lie to you.

Demo

Live site + walkthroughs: https://bodhiorchard.ai
Teaser — inside the virtual world: https://www.youtube.com/watch?v=OxoqBI7BNxU

Two views ship today: GARDEN (the orchard) and GRAPH (a cross-repo dependency graph with Bus Factor, Threats, and BUD-stage lenses). Two Slack bots sit on top — one triages new requests and kills duplicates before they become tickets; the other answers plain-English questions like "are we on track for go-live?" straight from the live BUD.

Code

Open source, Apache 2.0, self-hosted — it runs on a Mac mini.

mickyarun / bodhiorchard

Bodhiorchard is the open-source, self-hosted alternative to Jira and Linear for AI-native software teams. Specialised agents draft every spec, forecast cycle times, and reason over your real repositories, commits, and pull requests — replacing story points, standups, and stale tickets so engineers can focus on building.

Bodhiorchard™

Ship software, not Scrum ceremonies.

The open-source, self-hosted alternative to Jira & Scrum — AI agents run the process end-to-end, developers earn XP for what actually ships, and your data never leaves your machine.

Website · Quick Start · Why Bodhiorchard · The Twelve Agents · Docs · FAQ

▶ Watch the demo — a Slack message becomes a scoped, estimated BUD. No sprints, no story points, no standups.

Bodhiorchard replaces sprint, scrum, and Jira ceremony with Agent-Driven Development (ADD) — twelve specialised AI agents handle the busywork (triage, specs, estimates, test plans, retrospectives) while humans keep the decisions that matter, and developers earn XP for the work that actually reaches production. It's a self-hosted Jira alternative for the full lifecycle: intake → spec → design → development → testing → deploy → retrospective. The data plane stays on your hardware; inference runs through your choice of agent CLI…

View on GitHub

How I Built It

This is a solo project. Nights and weekends, on my own, because I couldn't leave it alone.

The stack: FastAPI + Python 3.12 on the backend, Vue 3 + PlayCanvas for the 3D world, Postgres + pgvector for the BUD memory, and Redis underneath. Inference runs through Claude Code today, with Ollama and OpenAI on the roadmap so you can bring your own model.

The hard part wasn't the agents. It was the ontology — deciding that a BUD, not a ticket, is the atom of work, and that everything (estimates, design, tests, the retro's estimated-vs-actual drift table) hangs off that one object. Once that clicked, the agents became small. Each one reads BUD context over a local MCP server and writes back only in the three creative phases where a human is still driving.

The 3D layer looks like the toy. It's actually the point. A dependency graph as a spreadsheet is a chore. A dependency graph as an orchard you can lose an afternoon in — that's the thing that made me want to open it every day.

The Passion Angle

I've spent years watching good engineers spend half their week on Jira instead of building. That quietly made me angry. This is the project I built to get that time back — mine first, then anyone else's who wants it.

"Build well. Then go outside." That's the whole idea.

Bodhi means awakening. An orchard is a grove you tend on purpose. The name is the pitch.

If you've ever felt sprints were broken and wanted to do something about it instead of just complaining in retro — clone it, break it, tell me where I'm wrong. That feedback is the only prize I'm actually chasing.

Are We in an AI Bubble? We've Built This Exact One Twice Before.

arun rajkumar — Thu, 09 Jul 2026 13:37:41 +0000

Railroads and dark fiber ran this exact playbook. Both times the technology won and the builders died. Here is why the AI build-out looks identical, and why your RAM got more expensive because of it.

I build on this stuff for a living. My company runs on cloud infrastructure. We pay for AI tokens every month. And a few weeks ago I looked at a quote to add memory to a machine and did a double take. The price had nearly doubled in a year.

That RAM quote is where this story starts. Because the reason memory got expensive is the same reason people keep asking if AI is a bubble. And to answer that honestly, you cannot just look at AI. You have to look at the two times we did almost exactly this before.

The pattern is older than the internet

Infrastructure bubbles all rhyme. Someone spots a genuinely world-changing technology. Money floods in. And then comes the move that defines every one of these episodes: companies build capacity far ahead of real demand, betting that demand will show up to fill it.

Sometimes it does. Usually it does not, at least not on the schedule the spending assumed. The gap between capacity built and capacity used is where the money dies.

We have run this experiment twice at national scale. First with railroads. Then with fiber. We are now running it a third time, with data centers.

Railroads: the original overbuild

Britain went first. During the Railway Mania of the 1840s, Parliament passed 263 acts in the single year of 1846 to set up new railway companies, for routes totalling around 9,500 miles. A lot of that track was planned on the assumption that traffic would arrive later. Much of it never earned back what it cost.

America did it bigger. Between 1866 and 1873, roughly 35,000 miles of new track were laid across the country, a lot of it financed on optimism and shaky debt. Then the bill came due. In the Panic of 1873, 89 of the country’s 364 railroads went bankrupt, and around 18,000 businesses failed in two years.

We did not even learn from it. Twenty years later, the Panic of 1893 hit for the same reason: too much railroad, financed too loosely. By mid-1894 a quarter of all US railroads had failed, more than 40,000 miles of them.

The technology was real. Railroads did reshape the world. But being right about the technology did not save the people who overbuilt it.

Fiber: capacity nobody could use

Fast forward a century. During the late-1990s telecom boom, companies laid more than 80 million miles of fiber optic cable across the US. The pitch was a number WorldCom kept repeating: internet traffic was doubling every 100 days. It was not. Real traffic was roughly doubling once a year, which is fast, but nowhere near the story the spending was built on.

So what happened to all that glass? Barely any of it got used. By some estimates less than 5% of the fiber laid in the boom was ever lit. Even four years after the bubble burst, 85% to 95% of it was still sitting dark. The industry literally invented a name for capacity built and never used: dark fiber.

The companies that laid it mostly did not survive to enjoy it. Global Crossing raised billions to wire the planet, then filed for bankruptcy in January 2002 with $12.4 billion of debt and thousands of miles of unused cable, after its chairman had quietly sold more than $700 million of his own stock. 360networks completed a $900 million IPO and was bankrupt about fourteen months later. WorldCom went down in July 2002 as the largest bankruptcy in US history at the time, $107 billion in assets, held up by roughly $11 billion of accounting fraud. Corning, which made the actual glass, fell from nearly $100 a share in 2000 to about $1 in 2002. All in, telecom stocks lost more than $2 trillion in value.

And the purest version of the madness was next door, in dot-coms. Pets.com went public in February 2000 having booked $619,000 of revenue while spending $11.8 million on advertising. It sold products for about a third of what it paid for them. It went from IPO to switching off the lights in 268 days, its stock from $11 to 19 cents, roughly $300 million burned. It is a punchline now. At the time it was a stock people lined up to buy.

Same shape as the railroads. Real technology. Genuine future. Ruinous timing.

AI: same script, much bigger budget

Now look at what is happening today.

The five biggest US cloud and AI players, Microsoft, Alphabet, Amazon, Meta and Oracle, have signalled combined capital spending of roughly $660 to $690 billion for 2026, close to double what they spent in 2025. Across the largest data center operators globally, the spend is heading toward $750 billion in a single year, and about three quarters of that, roughly $450 billion, is tied directly to AI: the chips, the servers, the buildings.

Each of these data centers costs billions. They are being built now, at full speed, for demand that is expected later. That is the tell. It is the railroad move and the fiber move, in concrete and silicon.

So here is the fair question. Is the money actually coming in to justify it?

Look at the two names everyone points to. OpenAI is running at roughly a $24 billion revenue rate as of early 2026, and still projecting a $14 billion loss for the year, with no profit expected before 2029 or 2030, while preparing to ask investors to value it above a trillion dollars. Anthropic has grown fast too, to around a $30 billion annual run rate.

Add up the frontier labs and you are somewhere in the range of $50 to $60 billion of annual revenue. Set that against roughly $450 billion of AI infrastructure spending in a single year. The revenue is real and growing quickly. It is also nowhere near what the build-out needs to break even.

And the demand everyone is counting on, enterprise adoption, is not showing up on schedule. An MIT report last year, looking at 300 deployments and 150-plus executive interviews, found that despite $30 to $40 billion of enterprise spending on generative AI, about 95% of organisations were seeing no measurable return. Only 5% were getting real value. Everyone is building for the enterprise wave. The enterprise wave, so far, is mostly stalled pilots.

This is why your laptop got more expensive

Here is the part that reaches people who never touch a data center.

Three companies, Samsung, SK Hynix and Micron, make over 95% of the world’s DRAM, the memory in your laptop and your phone. AI accelerators need a special, more expensive kind of memory called HBM, and it is far more profitable to make. So those three quietly shifted capacity toward HBM for the AI build-out and away from the ordinary memory the rest of us buy.

The result is a squeeze. Data centers now consume an estimated 70% of the memory chips produced worldwide. Prices have jumped hard. Samsung pushed a 32GB DDR5 module from about $149 to $239, a 60% jump. Contract prices for DDR5 have more than doubled. Samsung and SK Hynix are warning the shortage runs into 2027 and beyond, with customers reserving supply years ahead.

That is the bubble touching your wallet. You did not buy an AI product. But the AI build-out bid up the memory in the device in your pocket, and you are paying for it anyway.

So who actually won last time?

This is the twist worth sitting with.

When the fiber bubble burst, all that dark fiber did not vanish. It got sold off cheap. And the companies that scooped it up were not the ones that laid it. Google, Amazon and Facebook bought or leased that surplus capacity for a fraction of what it cost to build, and used it as the backbone for search, cloud and video. The infrastructure outlived the companies that funded it, and the winners were the ones who showed up after the crash with cash and a use for it.

That is the honest hopeful side. Demand for fiber did eventually catch up. It just took more than a decade, and it arrived long after the original investors were wiped out. The glut was real. The future was also real. Both things were true.

But this time the index is not made of Pets.coms

Here is the fairest objection to all of this, and it is a strong one.

The companies driving today’s build-out are nothing like Global Crossing or Pets.com. The fiber and dot-com bubbles floated on businesses with thin profits, sometimes almost no revenue, that needed a constant drip of fresh capital just to breathe. When the capital stopped, they were gone in months.

The names leading the AI spend are the opposite. Microsoft, Alphabet, Amazon, Meta, Nvidia and Apple are some of the most profitable companies that have ever existed. The so-called Magnificent Seven throw off something like 70% of the entire economic profit of the S&P 500. They are funding most of this build-out from the cash their existing businesses already generate, not from speculators who can vanish overnight. Cisco traded at 200 times earnings in 2000 on a far shakier story than any of these carry now.

So no, Google is not going to evaporate the way 360networks did. These giants can be wrong about AI for years and still be standing. That is a real difference, and it matters.

But look closely at what that argument actually says. It says the incumbents survive. It does not say the spending pays off. A profitable company can pour hundreds of billions into capacity that demand never fills, take the writedown, and walk away intact. The build is still an overbuild. The money is still gone. It just does not take the company down with it.

And the speculative layer has not disappeared. It has moved. Instead of Pets.com, this cycle has AI pure-plays and neocloud GPU landlords raising on the promise of the future, some of them buying chips with debt against contracts that only hold if the boom holds. If there is a Global Crossing hiding in this story, it is probably not Google. It is one of the names you only started hearing two years ago.

So, are we in a bubble?

Put it plainly. On the evidence, yes. Capacity is being built years ahead of the revenue and the adoption that would justify it, increasingly on debt, on a demand story that has not yet arrived. That is the exact pattern that broke railroads and telecom.

But a bubble does not mean everyone dies. The last two times, the technology was real and the future did arrive. It just arrived for different people than the ones who paid for it, on a slower clock than the spending assumed. The builders ate the loss. The infrastructure, and the payoff, went to whoever was still standing afterward with cash and a use for it.

The technology is not the bubble. The technology is probably the most important thing many of us will build on in our careers. The bubble is the belief that demand will arrive exactly when the spending needs it to. And “this time it is actually useful” is the line every bubble tells, right before it proves that being right and being early are two separate ways to go broke.

So no, I am not betting against AI. I am building on it. But when I sign off on that doubled memory quote, I remember how the last two of these ended.

Railroads were real. The people who overbuilt them went bankrupt, and someone else ran the trains. Fiber was real. Corning went from $100 to $1, and Google bought the cable for scrap. Both times, the future showed up exactly as promised. It just showed up for different people than the ones who paid for it.

That is the part nobody spending $450 billion this year wants to hear. The winners of the AI era may not be the names on today’s invoices. They may be whoever is standing there with cash and a use for it after the correction, buying the future at the price of scrap.

Twice is a coincidence. We are about to find out if three is a pattern.

Your Types Lie the Moment They Cross a Network Hop

arun rajkumar — Tue, 07 Jul 2026 12:47:04 +0000

A TypeScript type is a promise. And like any promise, it only holds while someone is around to keep it.

That someone is the compiler. It watches your code, checks every shape, and yells the second something does not line up. It is very good at its job. But it has one hard limit nobody tells you about on day one. It stops at the edge of your process.

The moment your data leaves the building, the compiler is gone. Over the network. Off a queue. Out of a webhook. Back from the database. Your type is still sitting there in the code, looking confident. But now it is just a sticky note that says "trust me." Nothing is checking it anymore.

I learned this the annoying way.

The bug that had no bug

We had two services talking to each other. One sent a payment amount. The other received it. Both sides shared the same type:

interface PaymentEvent {
  amount: number;
  currency: string;
}

Clean. Typed on both ends. The compiler was happy everywhere I looked.

Then one day the numbers in a report were slightly off. Not crashing-off. Just wrong enough to notice. No error. No stack trace. Nothing red anywhere.

Took us a while to find it. The sending service had started putting amount out as a string. "1000" instead of 1000. Somewhere upstream a value got serialized, went through a queue, and the quotes crept in.

On the receiving side, TypeScript still believed amount was a number. Because we told it so. It never looks at the wire. So "1000" * 100 did something silly, and the type sat there the whole time swearing everything was fine.

The type did not lie on purpose. It just was not there when it mattered.

Where your types are actually guessing

Here is the thing that clicked for me. Inside one process, types are real. The compiler saw the value get made and it saw it get used. It has the whole story.

But the second data crosses a boundary, your type is a guess. A hopeful one. These are the spots where it is guessing:

Anything you JSON.parse
A response from another service or a third-party API
A message off a queue or an event bus
A webhook you did not send
A row from the database
process.env (every one of those is a string, even the ones you treat as numbers)

In all of those, you hand TypeScript a blob of data and say "this is a PaymentEvent, take my word for it." And it does. That is the whole problem. It takes your word.

The fix is boring, and that is why it works

You stop trusting the label and you check the actual shape at the door. Every time data comes in from outside, you parse it before you use it.

We use Zod for this. You write the shape once as a schema. You get two things back from it: a real runtime check, and the type.

import { z } from "zod";

const PaymentEvent = z.object({
  amount: z.number(),
  currency: z.string(),
});

type PaymentEvent = z.infer<typeof PaymentEvent>;

Then at the boundary:

const event = PaymentEvent.parse(incoming);

If amount shows up as "1000", this throws right there, at the door, with a clear message. Not three services later in a wrong report. The bad data never gets in.

And look at the last line of the schema. The type comes from the check. You do not write the type by hand and hope the data matches it. The check is the source of truth, and the type just follows along. They cannot drift apart, because they are the same thing.

The rule we live by now

Trust types inside your own process. That is what they are for, and they are great at it.

The moment data comes from somewhere else, treat the type as a wish until you have checked it. Parse at every boundary. Build the type from the parser, not the other way round.

A type tells you what you meant. A parse tells you what you got. On a payments system, the gap between those two is real money.

So next time a value crosses a wire and lands in a nice typed variable, ask one question: who actually checked this? If the answer is "the compiler," the compiler already went home.

We're Still Designing for Eyes. The Thing Reading Our Apps Now Doesn't Have Any.

arun rajkumar — Fri, 03 Jul 2026 07:50:41 +0000

I spent about an hour of WWDC watching Apple tell developers to make their apps more beautiful.

Liquid Glass everywhere. A new transparency slider. Refined edges, better legibility. And this year you don't get to opt out. Recompile with Xcode 27 and your app adopts the new look whether you asked for it or not.

Then, in more or less the same breath, Apple told us the look might not matter much longer.

Because the other half of that keynote was App Intents. New entity and intent schemas that let your app push its content into Spotlight's semantic index, so Siri can find it and act on it through plain language. A View Annotations API so Siri can reach into what's on screen and do something with it. Foundation Models going open source. Xcode itself running coding agents from Anthropic, Google and OpenAI, wired in over MCP.

Read those two stories next to each other and the message is hard to miss. Make the screen prettier. Also, assume something that can't see the screen is about to become your real user.

Nobody at Apple stood up and said "the UI is dead." They rarely say the quiet part out loud. But it doesn't have to land in the App Review Guidelines as a hard rule to be true.

The front door moved

Here's what I keep coming back to as someone who ships product.

For years the front door to software was a screen. You designed the screen, you argued over the screen, you A/B tested the button on the screen. The screen was the product.

That's shifting under us. The front door is becoming an agent. Siri, Copilot, Claude, whatever your customer happens to be talking to. It reads on their behalf and makes the call on their behalf. Increasingly it acts on their behalf too. It does not care about your hero animation. It cares whether it can understand what you do, and then do it.

I ran into this with our own product. We're a payments company. We built an MCP server for our platform so an agent can look up a payment or kick off a refund without anyone opening the dashboard. Building that changed how I think about the whole thing. In that flow, our carefully designed dashboard wasn't the product. The clean, machine-readable version of it was.

Then everyone rushes to llms.txt and gets it half wrong

The reflex, once this clicks, is to drop an llms.txt on your site and call yourself future-proofed.

I had that instinct too. And clean, structured text genuinely helps. Serving markdown instead of a wall of HTML can cut the tokens an agent burns reading your page by half or more. Some teams report close to 10x. Fewer tokens means the model actually finishes your page instead of bailing halfway through. That part is real.

But be honest about what llms.txt is and isn't. After roughly eighteen months of noise, it's on about one in ten sites, and a big slice of that is Shopify quietly switching it on for every store by default. The bigger problem: the major crawlers from OpenAI, Google and Anthropic mostly don't fetch it. A study across 300,000 domains found it doesn't measurably move your AI citations. If you're adding it as an SEO cheat code, you'll be let down.

Where it actually earns its place today is narrower and more useful. It works as a clean map for coding agents. Cursor, Claude Code, Copilot and the rest read it. Documentation sites get real mileage from it. That's the tell. The people getting value from agent-readable content treat it as plumbing, not marketing.

What I'm telling my team instead

So I'm not chasing llms.txt for citations. I'm asking for something duller and, I think, more durable.

Treat the machine-readable version of every important surface as a real output, not an afterthought. If a page or a screen matters, there should be a clean text representation an agent can consume without scraping your DOM and guessing.

Put a short summary at the top of everything. Two or three lines, plain language, saying what this page is and what you can do here. A summary block helps a human skimming on their phone. It also happens to be the first thing a model reads before deciding whether the rest of your content is worth its context window. You write it once and both readers win.

Expose actions, not just words. Content is turning into table stakes. What an agent actually wants is a verb. "Refund this." "Book that." "Show me last month." App Intents on Apple's side, MCP on ours, a boring documented API underneath. The teams that do well in the agent era won't be the ones with the prettiest content. They'll be the ones whose product can be operated with no human in the room.

And measure the thing that now matters. Can an agent complete your core task, start to finish, without a screenshot? We've started treating that as a first-class test, the same way we treat "can a new engineer run the whole stack in five minutes." If the answer is no, no amount of Liquid Glass is going to save you.

The UI got demoted, not buried

I don't think the UI is dead. I've got designers I'd go to bat for and screens I'm proud of. But it's been demoted. It used to be the product. Now it's one interface among several, and often the one your customer touches least.

Apple just spent a keynote making the screen prettier and, at the same time, making it optional. That's not a contradiction. That's the shift, sitting in one room.

So here's the question I keep putting to my team, and I'll put it to you. If the agent is the new user, what does your product look like to something that can't see?

I Deleted Our Confluence. The Code Is the Wiki Now.

arun rajkumar — Mon, 29 Jun 2026 13:19:47 +0000

A feature needed context. I opened the wiki.

The page was six months old. It described an architecture we'd rebuilt twice since. It was wrong, top to bottom, and confident about it. Three engineers had already shipped decisions that week based on it.

Nobody messed up. The page just got left behind by the code, the way they all do.

So I deleted it. Then I deleted the habit that kept making it.

This is the part of Bodhiorchard, the open-source dev workflow I've been building on my own, that I get the most pushback on. So let me actually make the case. Including where it doesn't hold.

Every wiki you own is lying to you

You just haven't caught it yet.

It starts honest. Someone writes up how the payments service works, and that day it's perfect. Then the code moves. A field gets renamed. A flow reroutes. A service splits in two.

Nobody updates the page. Not out of laziness. Updating the page is everyone's job, so it's nobody's.

Six months later a new hire reads it, believes it, and ships a bug.

By then the wiki isn't documentation. It's a museum of how things used to work.

We've all quietly signed up for the same deal: pretend the wiki is current, then grep the code when you actually need an answer. The grep is the real documentation. The page is decoration.

The reason docs rot isn't discipline

It's that a wiki is a second copy of the truth.

You write it by hand. You keep it next to the thing it describes. The two drift apart. Always. Two copies of one fact, updated by different people on different days, will diverge. That's not a team failing, it's just entropy.

Code can't drift from itself. It's the thing that runs. When the doc and the code disagree, the code wins, because the code is what's live at 2am.

So the whole thing rests on one line:

The code is the wiki.

Not "we document well." Not "the docs sit near the code." The list of what your system does gets generated from the source, on its own, and never gets hand-written in the first place. You can't forget to update something that was never separate.

The baseline scan

Connect a repo and Bodhiorchard scans it. It doesn't ask you to describe anything. It reads the call graph, the module boundaries, the route handlers, the history, and pulls the live features straight out.

My own run came back with this:

Baseline scan complete.
  4 repositories indexed
  19 active features extracted
  312 code locations linked
  0 pages written by a human

Nineteen features. Each one traceable to the exact files that back it. I typed none of it. Nobody keeps it current.

Two things make this more than a fancy grep.

First, it indexes code locations, not just words. Every fact points back to a real file and symbol:

{
  "feature": "Idempotent refund webhook handling",
  "summary": "Bank may resend the same refund webhook up to 3x; processed once.",
  "code_locations": [
    "payments/src/webhooks/refund.handler.ts:24",
    "payments/src/guards/refundGuard.ts:8",
    "shared/db/migrations/0041_refund_dedupe.sql"
  ],
  "linked_repos": ["payments", "shared"],
  "last_synced_commit": "9f2c1ab"
}

Ask "how does refund idempotency work?" and the answer gets rebuilt from that. Not from a paragraph someone wrote at launch.

Second, it links across repos. A frontend call gets wired to the backend handler it actually hits. The thing wikis are worst at, "where does this logic continue," is the thing a code graph is best at.

And it doesn't go stale, because staleness is designed out:

on PR merge to main:
  -> re-scan the affected paths
  -> update the feature's code_locations + commit history
  -> re-embed for semantic search
  -> flag anything the diff orphaned

Every merge updates the feature that changed. The next person, or agent, to touch it inherits today's truth. A daily job sweeps for drift, so it shows up as a flag instead of a production incident.

You don't even open a dashboard to read any of this. You ask in plain English in Slack, and the answer comes back with a link to the code it came from.

What it changes day to day

Onboarding stops starting from a lie. A new engineer asks what the system does and gets an answer built from what it does today, files attached. Not the version from two refactors ago.

Status questions get answered from reality. "Are we on track for the P3 item, and what's the go-live date?" comes back from the live record, not a number someone typed into a board last Tuesday.

And your AI agents stop reasoning from stale context. This is the one I underrated. An agent is only as good as the context you hand it. Feed it a six-month-old wiki page and it'll cheerfully build on an architecture that's already gone. You get a clean PR that's wrong in a way that costs you an afternoon to spot.

That's why I stopped treating AI context files and human docs as two separate things. They're one thing with two readers. Generate them from one source, or watch them split apart the way the wiki did.

Where it stops

I'm not going to tell you this kills documentation. It doesn't. And where it stops matters.

Auto-extraction is great at what exists and where. It's useless at why.

A scan can tell you there's an idempotency guard on the refund webhook and point you at the line. It can't tell you the guard is there because one bank resends webhooks three times and double-refunded a customer back in March. That's intent. You earn it through pain, and no scan will ever infer it.

So the why still needs a person. In Bodhiorchard it lives in the BUD: one markdown file per feature, holding the intent, the criteria, the decisions.

# BUD-241 · Idempotent webhook handler for refunds

## Intent
Bank resends the same refund webhook up to 3x. We must process exactly once.

## Why this is hard (the part a scan can't infer)
- 2026-03 incident: duplicate webhook -> double refund. Don't regress this.
- An already-refunded txn must be REJECTED, not silently retried.

## Acceptance criteria
- Duplicate webhook IDs are a no-op (return 200, no state change)
- Illegal transition complete -> pending is impossible

The BUD is written by a human. But it's versioned, it's searchable, and it travels with the code as context for every agent. So even the human part stays alive instead of rotting in a tool nobody opens.

That split is the point. Machines maintain what rots fastest. People own what machines can't. The busywork dies, the judgment stays.

Try it, and tell me where it breaks

Bodhiorchard is Apache 2.0, self-hosted, and runs on a Mac mini in the corner of my room. Your repos, embeddings, and audit log never leave your hardware. I built it on my own time. The regulated fintech I run engineering at is where I felt this pain. It's not what owns the code.

Repo, with six demo videos and four sample repos to point it at: https://github.com/mickyarun/bodhiorchard
Full methodology: https://bodhiorchard.ai/

I'm not after stars. I'm stuck on one question.

Does "the code is the wiki" survive contact with your team? Or does the why sprawl back across five tools no matter how good the extraction gets? And if it does, where does it leak first?

I spent fifteen years maintaining wikis that were wrong by Friday. I finally stopped. If you've killed a doc tool and lived to tell it, what broke first: the tool, or your team's trust in it?

I'm Arun, CTO and co-founder of Atoa, a UK open banking payments platform, and the solo author of Bodhiorchard. I write about what building with AI is actually like, not what the conference slides say. Find me on X @mickyarun.

We Keep Our Architecture Rules in the Repo. The AI and the New Hire Read the Same File.

arun rajkumar — Tue, 23 Jun 2026 13:23:04 +0000

A few weeks ago I watched an agent build a feature beautifully.

Clean code. Tests passed. Did exactly what I asked.

Three sessions later, I opened the same service and didn't recognise it. Nothing was wrong, exactly. Every individual decision was reasonable. Stacked together, they'd quietly walked the codebase somewhere I would never have designed it.

That's when it clicked. The problem wasn't the model. The model was great. The problem was that every session started from zero — no memory of the boundaries I'd been protecting, no idea which patterns were load-bearing, no clue about the trade-off I made three weeks ago for a reason I never wrote down.

I'd seen this exact failure before. Just with humans.

The new hire who never read the docs

You know the version. Someone joins. They're sharp. They ship something in week one that works — and breaks an unwritten rule nobody told them about. Not their fault. The rule lived in my head, or in a Slack thread from last March, or in the muscle memory of whoever's been here longest.

So we'd explain it. Then explain it again to the next person. The "why" never made it anywhere durable. It just got re-explained, badly, on demand.

An AI session is a new hire who shows up brilliant, fast, and with total amnesia. Every single time. Re-explaining the codebase to a fresh chat window every morning is exhausting, and honestly I'd forget half of it under pressure anyway.

Same problem. I'd just been solving it twice.

One source of truth, two audiences

Here's the shift that fixed it for us: the context an AI agent needs to not wreck your codebase is the same context a new engineer needs on day one.

Not similar. The same.

Which patterns are deliberate. Where the boundaries are and why crossing them costs you. What "done" means here. Which decisions are settled and which are still up for debate. A human needs that to contribute without breaking things. An agent needs that to contribute without breaking things.

So we stopped keeping it in our heads and started keeping it in the repo. Plain markdown. Committed. Versioned with the code it describes.

service-payments/
├── CLAUDE.md          # how this service works, and why
├── src/
├── test/
└── ...

A root CLAUDE.md (or AGENTS.md — pick the convention your tools read) carries the project-wide principles. Each service that has real rules of its own gets its own. When an agent opens that service, it loads the file automatically. When a human opens that service, the same file is sitting right there, written so a person can actually read it.

One file. Two readers. Nothing to keep in sync, because there's only one of it.

What actually goes in the file

This is where most teams get it wrong. They dump the obvious in there — "we use TypeScript," "run the tests before you push" — and the file becomes noise everyone scrolls past.

The rule I use: a line earns its place only if leaving it out would let a plausible, reasonable-looking mistake sail through review.

That filter kills most of what you'd be tempted to write. What survives is the good stuff:

## Boundaries
- Services talk over the message bus, never direct HTTP to each other.
  If you need another service's data synchronously, that's a design
  smell — raise it, don't route around it.

## Validation
- Every inbound payload is parsed by a schema at the edge. No raw
  request bodies past the controller. A missing field fails loud on
  the way in, not three layers deep at runtime.

## What "done" means here
- A feature isn't done when it works. It's done when the next person
  can tell what it does without asking you.

## Settled vs open
- SETTLED: how we do idempotency. Don't reinvent it; copy the pattern.
- OPEN: our caching story. If you touch it, expect a conversation.

Notice none of those are syntax. They're judgment. The settled-vs-open split alone has saved me hours, because it tells both the agent and the human where to copy an existing pattern versus where to stop and ask a person.

The "why" matters as much as the rule. "Don't call services directly" is an order. "Don't call services directly, because the moment you do you've created a hidden dependency that nobody can see until it breaks at 2am" is something a human will actually remember and an agent will actually respect.

The honest part

This isn't free, and it isn't a silver bullet.

The files rot if you let them. A rule that's no longer true is worse than no rule — it teaches the wrong thing to two audiences at once. So they get reviewed like code, because they are code now. When a settled decision changes, the file changes in the same PR. If that feels like overhead, it's the overhead you were already paying in repeated explanations — just made visible.

And no, I didn't stop using AI tools while waiting for the perfect setup. The point isn't to control the agent. It's to make sure my long-term thinking is still present in a codebase that's increasingly being written by someone — something — that wasn't in the room when the decisions got made.

When one file stops being enough

A markdown file works until it doesn't. One service, a handful of rules — CLAUDE.md is perfect. But spread it across a dozen services and the tending becomes the whole job. The rules drift from the code they describe. The "why" behind a feature ends up split across a spec, a ticket, a PR description, and a conversation nobody can find six weeks later. The flat file can't keep up, and a stale rule teaches the wrong thing to both readers at once.

That rot is what pushed me to build Bodhiorchard — an open-source, self-hosted project I've been working on independently (Apache 2.0, runs on Claude Code). Same idea as the file, taken further. Instead of one feature's knowledge scattered across tickets, everything for that feature lives in a single living document: the spec, the tech spec, the test plan, the acceptance criteria, the full history — tied to the actual code. And the knowledge layer stays current by syncing from the code and those docs automatically, so it's semantically searchable by a human and fed straight into every agent's prompt.

That's the part I care about most. Not a wiki you have to remember to update. A wiki that's current because it's wired into where the work already happens. Confluence goes stale the day you write it. This doesn't, because nobody's job is to keep it alive by hand.

The principle never changed. One source of truth, two audiences. I just got tired of being the sync engine.

What changed

Less re-explaining. That's the boring, real win.

New engineers read the same file the agent reads, and it turns out the document you write for a machine that takes everything literally is a really good onboarding doc. No assumed context. No "you'll pick it up." Just the actual shape of the thing.

And the drift slowed down. Not because the agent got smarter — because it finally knew which walls were load-bearing.

I used to think the codebase lived in the code. It doesn't. Half of it lives in the decisions around the code — and for years I kept that half in my head, where exactly one reader could access it.

Now it's in the repo. Where everyone can. Human or not.

If you're letting AI write a meaningful share of your code: where do the rules of your codebase actually live right now? And who can read them?

Same Prompt, Four AI Tools, One Cricket Banner: ChatGPT Won the Image, Grok Won the Video, and Claude Built a Website Again

arun rajkumar — Tue, 16 Jun 2026 12:30:00 +0000

TL;DR — A few weeks ago I tested four AI tools on a build job: a website for my son's cricket academy. This time the job had nothing to do with code. The coach just wanted a banner he could post. Same four tools, totally different result. ChatGPT made the best image, Grok made the best video, Gemini wouldn't make anything, and Claude tried to solve a graphics problem by writing HTML.

If you read the last post, you've met my son's cricket coach. He runs MMCA — Maverick Master's Cricket Academy. Started in 2020, based in Bengaluru, genuinely good with the kids.

The website is live now and parents have started messaging him on WhatsApp. So last weekend he came back with the next thing he needed, which is the thing every small academy actually runs on:

"Can you make me a weekend batch banner? Something I can post in the parent groups."

Now, this is a completely different job from the last one. That first experiment was design and development — agents writing real code, running tests, deploying to Cloudflare. This one is just graphics. No repo, no deploy, nobody reviewing a pull request. Just: here's my logo, here's a sample I like, make me something I'd be happy to send out.

So I figured I'd run the same four tools again and see what happened. Same brief, same logo, everything on the default model with no special settings: ChatGPT, Claude, Gemini, Grok.

Here's roughly what I typed, the way a normal client would brief you:

Similar to this banner, make one for MMCA Academy (since 2020, logo attached). Weekend batch Sat 4:30—7, Sun 7—9:30pm. Add a small phrase like the sample. Be creative, keep it simple, but don't copy the sample exactly.

The whole test really came down to one instruction: be creative, but don't copy. Whatever each tool did with that told me everything.

Round 1: the static banner

ChatGPT got it on the first go. "WEEKEND BATCH. TRAIN. PLAY. GROW." Logo top-left, the "Since 2020" bit kept, timings in clean little cards, an enrol number, three badges across the bottom for coaching, skill, discipline. It clearly understood this was a flyer a coach would hand out at a school gate, and that's exactly what it gave me.

Then I asked for one more version — smaller logo, add a human hero this time — and it came back with "DREAM. PRACTICE. PERFORM." and a photoreal batsman walking out under stadium lights. Looked like a film poster. Two prompts, two banners I'd genuinely use, no arguing with it.

Claude is the one that made me laugh. I asked for a banner. It told me it would "create the MMCA banner as an HTML file you can download," ran six commands, and gave me a dark navy web page. "TRAIN HARDER. Play Smarter. Win Together," with Saturday/Sunday cards and a Register button. And to be fair it looked nice — same eye for design that won me over on the website build.

But it's not a banner. It's a landing section. You can't drop a <div> into a WhatsApp group and call it a poster.

That's the part worth sitting with. The tool I actually shipped the website with, the one with the best taste when the medium is code, defaulted straight back to code the moment I asked for graphics. It's wired to build. Ask it to build something and it's brilliant. Ask it to draw something and it quietly turns your design job back into an engineering one.

Grok at least made an actual image, which already put it ahead of half the field. Problem was it threw everything at the wall — three overlapping player photos, mismatched fonts, text everywhere, faded cricketers bleeding through the background. The exact opposite of "keep it simple." It knew what a banner was. It just didn't know when to stop.

Gemini gave me three attempts and three different ways of saying it couldn't quite generate that. The image guardrails kept tripping over what was, I'll remind you, a children's cricket flyer. I gave up after the third try. For a test that's purely about making graphics, a tool that won't make graphics doesn't really place.

Round 1 goes to ChatGPT, and it's not close. Two prompts, two finished banners, on brand, logo respected, the restraint Grok didn't have and an actual image Gemini wouldn't produce.

Round 2: make it move

Static was only half of what I was curious about. The real 2026 question is whether I can turn a flat banner into a short clip with a voiceover. So I took the good banner and gave two tools a single line: "make this banner live."

Grok nailed it. One prompt, six seconds. The banner came alive — the batsman moving, the paint-splash colours animating in, the timings resolving on screen — and over the top, a clean Indian-accented voiceover reading the academy out. "Where practice meets purpose." Honestly it looked like something an agency would charge ₹15,000 for.

One caveat, and it's the CTO in me talking: check the details. The phone number that showed up in the video wasn't the one I'd put in the source banner. Motion tools will happily rewrite text you wanted left alone, so you proof it before it goes out. Gorgeous result, but you don't post it blind.

Gemini, the same tool that wouldn't make me a still image, decided it would make me a video. Ten seconds of abstract paint-splash motion, a "WEEKEND BATCH" title card, a voiceover — but disconnected from the actual banner, and the on-screen text kept breaking apart and reflowing into gibberish. The idea was there, the execution wasn't. A trailer for a banner that never got made.

Round 2 goes to Grok. For motion plus voice off a single prompt, nothing else came close.

The scorecard

Tool	Static banner	Live video	Read the brief?
ChatGPT	Won it in 2 prompts	—	Yes, with restraint
Grok	Cluttered, no restraint	Won it, voice + motion	Half — strong on motion
Gemini	No output, guardrails	Out of context, broken text	No
Claude	Built an HTML page	—	Wrong medium, nice taste

Image goes to ChatGPT. Video goes to Grok.

What changed from the coding test, and what didn't

Last time, on a development job, Claude was the tool I actually wanted to keep working with. The taste that made its website the nicest in that lineup is the same taste that made its HTML "banner" pleasant to look at here. None of that's a knock — it was just answering a question I hadn't asked. Point a code-native model at a design brief and it reaches for the thing it's best at.

Switch the job from build to draw and the whole ranking flips. A few things I'm taking away:

The best coding agent isn't automatically the best graphics agent. Obvious once you say it out loud, easy to forget when your whole team has standardised on one tool. The model that shipped my website couldn't make me a poster.

Guardrails are a product decision you feel as a user. Gemini turned down a kids' cricket flyer three times and then made a broken video of it. Whatever the safety reasoning, what I experienced was a tool that wouldn't do the simplest creative thing I needed.

And "done" beats "impressive." ChatGPT's banners weren't the flashiest pixels I've ever seen. They were finished, and I could post them in two prompts. Grok's video was the flashiest thing in the whole test and still needed me to catch a wrong phone number. For graphics, I'll take the tool that hands me something I can ship today over the one that wows me in the demo.

So I'm not picking a winner overall. I'm picking one per medium. ChatGPT makes the still, Grok makes it move. That's the actual workflow now — not one model to rule them all, just the right one for the thing in front of you.

The coach got his banner. Two of them, really, plus a video. Cost me a handful of prompts and one careful read-through.

Last time the lesson was that taste decided a coding job. Turns out taste decides a graphics job too. It just lives in different tools.

Which one are you reaching for when the job is graphics and not code? And has your favourite coding agent ever quietly tried to turn a design task back into a dev task on you? Curious to hear it.

AI #DesignTools #BuildInPublic #GenAI #Startup

Open Banking vs Card Rails: Latency, Cost, and Developer Experience

arun rajkumar — Wed, 10 Jun 2026 08:08:10 +0000

I've integrated both. Cards and open banking. In production. Moving real money for real UK merchants.

So when developers ask me "which is actually better to build on?" I don't give them the marketing answer. I give them the three numbers that decide it: how much it costs, how fast the money moves, and how much of your life you lose to the integration.

Let me walk through all three. Honestly. Including where cards still win.

1. Cost — and why it's not close

Here's the part nobody at the card networks wants in a headline.

A UK card payment costs you somewhere between 1.5% and 3%+ per transaction once you stack interchange, scheme fees, and your processor's margin. The "0.2% debit interchange cap" everyone quotes is the floor of the floor — it's not what lands on your statement.

An open banking payment costs roughly 0.1%–1.0%, or a flat 20p–50p. No interchange. No scheme fee. Because there's no scheme. The customer authorises the payment inside their own banking app and the bank moves the money directly.

The concrete version: a local garage takes £500 for a repair. A 1.5% card fee costs them £7.50. The same payment over open banking can cost around 10p. (Noda)

That's not a rounding difference. That's the difference between a payments line item you tolerate and one you forget exists.

And there's a second-order cost cards carry that nobody puts in the pricing table: chargebacks. £20 a pop, plus the engineering time to fight them, plus the fraud surface you have to defend. Open banking payments are bank-authenticated at source. There's no card number to steal and no "I didn't authorise this" dispute when the customer tapped approve in their own banking app. The fraud surface is smaller, so the price can be lower. The two facts are connected.

2. Latency — settlement, not the spinner

This is where developers get the comparison wrong, so let me split it cleanly.

Authorisation latency — the spinner the user stares at — is comparable. Both flows take a few seconds. A card auth round-trips the network; an open banking payment redirects the user to their bank's SCA and back. From the user's chair, both feel like "tap, wait, done."

Settlement latency is where they diverge violently.

A card payment authorises instantly but settles in ~2 business days. The money is promised, then it sits in limbo, then it arrives — minus fees, and reversible for months.

An open banking payment runs over Faster Payments. Settlement is near-instant — seconds to minutes — straight bank-to-bank, 24/7. There's no two-day float, no "pending payout" dashboard, no reconciling Tuesday's sales against Thursday's deposit. (Payop)

If you've ever written reconciliation code, you already feel why this matters. Half the complexity in payments tooling exists to model the gap between "authorised" and "settled." Close that gap to near-zero and a whole category of state machine — pending, settling, settled, partially-reversed — collapses into one event: paid.

3. Developer experience — where I'll be honest both ways

Let me give cards their due first.

Card SDKs are mature. Stripe's docs are art. The card flow is a solved, copy-paste problem with twenty years of Stack Overflow behind it. If you're doing global, card-first commerce, that maturity is worth real money. I'd still reach for cards there.

Open banking is younger, and the early ecosystem was genuinely painful — you were integrating against dozens of bank APIs, each with its own quirks, its own auth dance, its own downtime. That's the part that earned open banking its "hard to build on" reputation a few years ago.

But that reputation is now outdated, and here's why: the bank-by-bank mess is exactly what a good PISP abstracts away. You don't integrate 40 banks. You integrate one API that speaks Payment Initiation, handles SCA, manages the consent lifecycle, and fans out to Faster Payments for you.

In practice, the flow is short:

// 1. Create a payment — you describe intent, not card mechanics
const payment = await atoa.processPayment({
  amount: 4999,            // £49.99 in minor units
  currency: 'GBP',
  reference: 'order_10472',
  redirectUrl: 'https://yourapp.com/return',
});

// 2. Send the customer to their bank to authorise (SCA happens here)
redirect(payment.authorisationUrl);

// 3. The bank moves the money over Faster Payments.
//    You get told when it's actually settled — not "authorised, check back Thursday."

// Webhook: the event you actually care about is real, not a promise
app.post('/webhooks/atoa', (req, res) => {
  const event = verify(req);              // verify signature
  if (event.type === 'payment.completed') {
    fulfilOrder(event.data.reference);    // money is already in the bank
  }
  res.sendStatus(200);
});

Notice what's missing from that code. No card object. No PCI scope to inherit. No tokenisation vault to secure. No requires_capture → capture two-step. No chargeback webhook to handle. You describe a payment, the customer approves it in their bank, the money arrives, you fulfil. The thing you're modelling is the thing that actually happens.

That's the DX argument in one sentence: open banking lets you write code that matches reality instead of code that models a 1970s settlement delay.

The honest scorecard

	Card rails	Open banking
Cost per txn	1.5%–3%+	0.1%–1% / 20p–50p
Settlement	~2 business days	Near-instant (Faster Payments)
Chargebacks	Yes, £20+ each	Structurally absent
PCI scope	Yours to carry	Not your problem
SDK maturity	Excellent, 20 yrs	Younger, but abstracted
Best for	Global, card-first	UK consumers, instant settlement

Cards aren't dead. If your customers are international and card-native, build on cards. I mean that.

But if you're a UK SaaS, marketplace, or merchant tool charging UK consumers — you're paying card prices and eating card latency for an experience your users don't need. The numbers back the switch, and they're moving in one direction: UK open banking payments are up 53% year on year, with nearly 1 in 3 adults already using it. (Open Banking Ltd)

Try it yourself

The fastest way to feel the difference is to build it. Atoa's sandbox gives you a real Payment Initiation API, real Faster Payments settlement, and webhooks that fire when money actually moves — not when it's promised. docs.atoa.me

Spin up a test payment. Watch it settle in seconds instead of days. Then look at what you'd have paid in card fees for the same transaction.

That second number is the one that changes your mind.

Have you shipped both card and open banking flows in production? I want to hear where the DX actually broke down for you — the messy bits, not the brochure version.

OpenBanking #Payments #Fintech #API #BuildInPublic

I Replaced Scrum, Jira, and Our Wiki With 12 AI Agents on a Mac Mini

arun rajkumar — Mon, 08 Jun 2026 16:33:49 +0000

A survey last week put it at 54%. More than half the code shipped today is AI-generated.

In my own work the number is probably higher. AI writes the first draft. AI estimates the work. AI generates the tests. I've written before about the dangerous 20% — the edge cases, the illegal state transitions, the judgment AI quietly skips. That 20% is why I still need senior engineers.

But there's a second 20% problem nobody talks about. Not in the code. Around it.

Sprints. Story points. Standups. Jira boards no one updates. Confluence pages that went stale the day they were written. Every one of those tools assumes a human does the work and another human tracks the work.

That's not my team anymore.

So I stopped bending fifteen-year-old process around an AI-native team. I built my own way of working and open-sourced it. It runs on a Mac mini in the corner of my room. This is what's inside.

Your whole org as a grove. Each repo is a tree, each feature a branch, each teammate present in the world. More on this below — but yes, that's the actual dashboard.

The thing that finally broke me: the wiki

Here's the moment it clicked.

A new feature needed context. I opened our wiki. The page was six months old. It described an architecture we'd refactored twice since. The "source of truth" was confidently, completely wrong — and three engineers had made decisions based on it that week.

Documentation lies the moment you stop maintaining it. And nobody maintains it, because maintaining it is the busywork we all silently agree to skip.

Source code doesn't lie. It can't. It's the thing that actually runs.

So the first rule of the system I built: the code is the wiki. Knowledge is extracted from the repository — the call graph, the module boundaries, the patterns, the history — and indexed continuously. When an agent or a human asks "how does settlement work?", the answer is reconstructed from what's true right now, not from a page someone wrote last quarter and abandoned.

No Confluence. No Notion graveyard. The only document that's allowed to be authoritative is the one that compiles.

Nobody wrote this wiki. A baseline scan read the repositories and produced it — 19 live features across 4 repos, each one traceable to the code that backs it.

And you don't even open the dashboard to read it. Ask in Slack, in plain English — "are we progressing on the P3 backlog item? what's the go-live date?" — and a bot answers from the live BUD: status, assignee, target date, a link back to the source. Not a number someone typed into a board last Tuesday. The thing that's actually true, right now.

The same emoji-react, thread-reply Slack you already live in — except the answers come from the source of truth, not from memory.

So "the code is the wiki" isn't a slogan — it's an architecture. Knowledge lives in four layers that stay in sync on their own:

The repos themselves — source code plus a per-repo CLAUDE.md, synced on every PR merge to main.
Agent skills — org standards, design guidelines, API patterns; synced on change.
The central store — BUDs, enterprise rules, architecture decisions; real-time.
Vector search — semantic search across all of it, auto-indexed.

Two things make this more than a fancy grep. It indexes code locations, so any knowledge captured during development points back to the exact file and symbol it came from — and it links across repos, so a frontend call is connected to the backend handler it actually hits, not left as two disconnected facts in two different wikis. And it never goes stale: after every PR merge, the affected feature is updated with the new commit history and the new code locations automatically, so the next agent that touches it inherits the current truth, not last month's.

That's the whole pitch against Confluence — auto-synced from source instead of hand-maintained, semantically searchable instead of keyword-matched, always current with daily staleness detection, and wired straight into the agents' prompts so they're never reasoning from a stale page.

Agent-Driven Development, in one table

I call the methodology Agent-Driven Development (ADD). The simplest way to explain it is to put it next to the thing it replaces.

Agile ceremony	What it assumed	Agent-Driven Development
Sprint planning	Humans do all the work, so plan their hours	Agents draft; humans decide what's worth building
Story points / planning poker	Gut-feel proxy for time	AI-PERT + Monte Carlo → real P50/P70/P85 dates
Jira tickets	Work scattered across a board	One BUD per feature: spec + tech plan + tests + history
Confluence / wiki	Someone keeps docs current (nobody does)	Knowledge syncs from the source code
Daily standup	Humans report status out loud	A Status Agent reads the PRs and tells you what moved
Retrospective	A meeting you forget by Friday	A Learning Agent mines the actual diffs and incidents

The pattern underneath all six rows is the same: let the machines handle the noise, so humans spend their judgment where judgment actually matters.

The 12 agents

Here's the whole cycle on one diagram before I break it down — twelve agents around a loop, with a human reviewing at the centre and at every gate.

Chat Intake (Triage) → BUD → Design → Tech Architecture (Tech Lead reviews; Smart Assignment picks the dev) → Development (AI + Human) → Test Generation → Testing (QA) → UAT & Deploy (Status) → Feature → Learning & Skills. An external bug reopens the feature. The loop never pretends it's a straight line.

ADD runs a feature from a chat message to production through a chain of specialised agents. Each owns one phase. A human reviews and decides at every gate — this is human-in-the-loop by design, not lights-out automation.

It starts in Slack. You drop a request; the Intake agent doesn't just file it — it checks for existing features and BUDs so you don't build a duplicate, then asks the questions a good PM would: who is this for, why now, what's the timeline.

"Change the notification icon to modern design?" → the agent checks for duplicates, then interrogates the intent before a single line is written.

From there, every feature moves through the same seven-phase lifecycle, each phase a tab on its BUD:

Slack idea → Intake → Requirements → Design → Tech Spec
   → Development → Code Review → Testing → Prod
        ↑ estimation, status, learning and skills run alongside ↑

Every phase can run on an agent — or you flip it off and drive it yourself from your local AI via MCP. "Stage agents are off, you're driving this BUD" is a real toggle, per phase, per assignee. That's what human-in-the-loop actually looks like.

Around that spine sit the agents that kill the ceremonies:

Estimation — AI-PERT + Monte Carlo instead of story points (below).
Status — reads the PRs so you never run another standup.
Learning — mines the real diffs and incidents when a BUD closes.
Skills — profiles who's strong at what from git history, and feeds it back into estimation and routing.

The agents do the busywork. You do the deciding. That division is the whole philosophy.

The standup reads the work, not the people

I haven't run a status standup in months. The Standup Agent does it at 08:30 on a cron — but the interesting part is where it reads from. It doesn't ask anyone "what did you do yesterday." It reads what actually happened.

Hooks and an MCP server in each dev's local setup post the real signal back to the BUD: the prompts, the commits, the sessions. A TODO gets auto-claimed when work starts on it and auto-marked done when the agent finishes the code — so the board reflects reality without anyone updating it. The agent then aggregates the git, PR, bug and chat activity into a summary with risk flags on anything lagging.

Four file-level TODOs, all ticked by the work itself. PR #50 merged, 4 commits, 2 files, 5 sessions, 0 errors — captured from hooks, not typed into a board. The status is a side effect of building, not a separate chore.

And because the Design Agent generates wireframes from your project's design system extracted out of the code — the real CSS tokens, not a guess — what it produces is on-brand by construction. Same with the tech spec: it's written against your actual architecture and tokens, so "follows the brand guidelines" stops being a review comment and becomes the default.

The quality loop that reassigns itself

This is the part I'm proudest of, because it's where most teams quietly accumulate debt.

The Test Plan Agent auto-generates the test plan from the BUD's acceptance criteria and the code — Playwright e2e, unit and integration, security, and the manual UAT cases a human still has to sign off. An MCP token wires your QA automation repo in, so test commits flow straight back to the BUD.

24 test cases for one small feature — and notice the manual ones marked "neither can ship as silent regressions, require human sign-off." The agent writes the tests; it doesn't get to wave them through.

Code review is auto-triggered against your org's rules and submitted back on the PR. And here's the loop that closes itself: testing has a bug threshold — complexity × a configurable multiplier. Cross it, and the work auto-reassigns. The original developer moves to bug review, QA rotates to the next waiting BUD, and each bug is auto-classified as a missed feature versus a development bug so it takes the right fix path. Quality debt doesn't pile up quietly, because the system reacts to it before a human notices.

The BUD: one document instead of three tools

Every feature lives in a single markdown document called a BUD — Business Understanding Document. Spec, technical spec, test plan, and decision history, all in one place, vector-indexed so any agent can pull it as context.

# BUD-241 · Idempotent webhook handler for refunds

## Intent
Bank sends the same refund webhook up to 3x. We must process once.

## Acceptance criteria
- Duplicate webhook IDs are a no-op (return 200, no state change)
- A refund on an already-refunded txn is rejected, not retried
- Illegal transition complete → pending is impossible

## Tech plan
- Dedup key: (provider, webhook_id) unique in Postgres
- Reuse shared `refundGuard` util — do NOT reinvent

## History
- 2026-06-05 design approved (human gate)
- 2026-06-05 estimation: P70 = 2 days

That's the whole feature. No ticket in Jira, no spec in Confluence, no test plan in a Google Doc that nobody opens. One file. It travels with the code, and it's the context every agent reads before it touches anything.

Killing story points with statistics

Story points always bothered me. They're a proxy for time that we then pretend isn't a proxy for time, and they don't compose across a team where one person knows a module cold and another has never opened it.

ADD replaces them with AI-PERT plus a Monte Carlo simulation.

For each phase the model generates optimistic / likely / pessimistic estimates — classic PERT — but weighted by a per-developer, per-module skill score (0–1.0, derived from git and BUD history), current load, and backlog depth. Then 10,000 simulated runs turn that distribution into dates with confidence intervals:

Feature: Idempotent refund webhooks
  P50  →  Jun 9   (50% chance done by)
  P70  →  Jun 10  (70% chance done by)
  P85  →  Jun 12  (85% chance done by)

"85% confident by the 12th" is the shape a stakeholder actually wants. It's also honest in a way "8 points" never was — it shows you the uncertainty instead of hiding it inside a fake integer.

Where do those skill scores come from? Git history. The system reads who has actually shipped what, per module, and builds a profile — expertise you can see instead of guess at.

Five developers, eighteen modules, scored from real commits. This is what feeds estimation and routing — not a manager's hunch about who "knows the auth code."

Is the skill-score input perfect? No. It's derived from who happened to touch what, so it can encode bias. That's one of the two things I most want feedback on.

And the loop closes itself. When a BUD ships, the Learning Agent writes the retrospective from the actual diffs — including an estimated-vs-actual table that tells you exactly where the model was wrong, so the next estimate is better.

No retro meeting. The agent reads the merges and the timeline and hands you the drift — Design −25%, Development +603% — so estimation actually learns.

The part that sounds whimsical and isn't: the virtual world

The whole organisation renders as a living 3D world — and it's multiplayer. Not a dashboard you look at. A place your team is actually in, together.

Each repository is a tree. Each feature is a branch. Each agent is an orchardist tending the grove. A feature in progress is a branch growing; a merged one bears fruit; a stalled one needs pruning. Health is visible at a glance: a thriving tree versus one quietly dying.

And every teammate is there with you. You walk around with WASD, sprint, jump, orbit the camera over the grove. Your colleagues are avatars with their own houses, present in real time. You can wave, cheer, greet, invite someone over. It sounds like a game because part of it is one — but the effect is presence. A standup is people reading status out loud. This is people standing in the same place, looking at the same living map of the work.

Your team, present. Move, sprint, wave, cheer, invite. The status bar is real controls, not decoration.

It started as a visualisation. It became the most honest org chart I've ever had — because it's drawn from the code, not from a slide. Here's a walkthrough.

Shipping quality is the game

Here's the part I didn't expect to care about and now love.

The world is gamified — but it rewards the right thing. You earn XP and Skill Points, level up, unlock vehicles, upgrade your house. Crucially, the economy is tuned to quality, not output. Ship a BUD to production: +1 SP. Give a code review: +0.25. Quality score above 80%: +0.5. Bug found in testing: −0.25. Bug found in production: −1. And the points for shipping don't pay out until the BUD actually reaches CLOSED — through testing, UAT, prod. You don't get rewarded for the green checkmark. You get rewarded for the thing surviving contact with reality.

Read the numbers: a production bug costs you more than shipping earns. That's the whole point. In a world where AI can churn out code that passes tests, the scoreboard has to reward what AI is bad at — code that holds up.

That ties straight back to where I started. AI nails the 80%. The 20% — the part that doesn't blow up in production — is what we actually want to incentivise. So that's what the game scores.

It runs on a Mac mini, and your data never leaves it

This is the part I care about most, and the part most "AI dev platform" pitches skip.

Bodhiorchard is self-hosted by design. Postgres with pgvector, your repositories, the embeddings, and the full audit log live on your hardware. For me, that hardware is a Mac mini. No repo content is shipped to anyone's cloud. For a regulated shop — and I lead engineering at an FCA-authorised fintech, so this is not theoretical for me — that's the difference between "interesting demo" and "allowed to exist."

Inference is your choice. It runs on Claude Code today; Ollama and OpenAI are on the roadmap for fully air-gapped setups. The agent layer is engine-independent — swapping the model is API rewiring, not a redeploy.

The stack, for the curious:

Backend   FastAPI · Python 3.12
Frontend  Vue 3 · PlayCanvas (the 3D world)
Data      Postgres + pgvector · Redis
Agents    Local MCP server (read + bounded write tools)
License   Apache 2.0

It's also built for real orgs, not just a solo demo: detailed roles and permissions, multi-org support out of the box, and capacity planning baked into triage and assignment — the Triage Agent defers work when the team is full, and Smart Assignment balances by real-time utilisation rather than who shouts loudest. So the "self-hosted toy" worry doesn't really hold; it'll sit inside an org's access model on day one.

Honest status, because HN will ask anyway

I'd rather tell you this up front than have you find it.

What's live today: the platform, the BUD lifecycle, the MCP write-path, repository and code-graph indexing, skill profiling, and the 3D living-tree dashboard. The agents are real and they work with a human in the loop at every gate.

What I'm still building: the fully autonomous execution loop. The direction I'm taking it is deliberately narrow — auto mode first for small, low-risk BUDs, where one agent chain runs tech spec → code → code review → test → deploy end to end, then stops and waits for a human to approve the release. Not "point the swarm at production and walk away." Lights-out on the small stuff, a human gate where it counts. That's the active work, not a shipped claim. So today this is agents-assisted, human-in-the-loop, and anyone who tells you their agent swarm ships production code fully unattended is selling something.

This is an independent project. I built it solo, on my own time, not affiliated with any employer — the fintech is where I felt the pain, not the thing that owns the code.

You don't have to start from zero

If you're on Jira today, you don't throw your backlog away. Connect Jira Cloud and import your existing issues straight into BUDs — point Bodhiorchard at the work you already have and watch the grove fill in.

The on-ramp is a migration, not a rewrite. Your tickets become BUDs; the agents take it from there.

There's also a cross-repo graph view — bus-factor analysis, threat detection, BUD-stage filtering across every repo — for when you want the dependency map instead of the grove. Same data, different lens.

What I actually want from you

Not stars. Feedback. Two questions I'm genuinely stuck on:

Does "the BUD is the single source of truth" survive contact with your reality? Or does real-world ticketing always sprawl back across five tools no matter what you do?
Where would self-hosted + bring-your-own-inference actually change your mind versus a hosted SaaS PM tool — and where is it just more ops burden you don't want?

The full methodology is written up at bodhiorchard.ai — the twelve agents, the manifesto, the Agile-vs-ADD table, all of it. The repo has six demo videos and four sample repositories you can point it at: https://github.com/mickyarun/bodhiorchard

I spent fifteen years being told the ceremony was the engineering. Sprints felt broken long before AI. AI just made it impossible to keep pretending.

So I replaced them. If you've killed a ceremony and lived to tell the tale — which one did you kill first?

I'm Arun — CTO & Co-Founder of Atoa, a UK open banking payments platform, and the solo author of Bodhiorchard. I write about what building with AI is actually like, not what the conference slides say. Find me on X @mickyarun.

How We Hire for the 20% AI Can't Do (And Why We Stopped Asking Candidates to Code From Scratch)

arun rajkumar — Tue, 02 Jun 2026 14:43:11 +0000

A few weeks ago I published a piece called "AI Agents Are Great at 80% of Our Code. The Other 20% Is Why We Still Need Seniors."

It got 25 reactions and 34 comments. Several of those comments asked the same question in different words:

"How do you actually measure that 20% when you're hiring?"

Fair question. I dodged it in the first article because I didn't have a clean answer yet. Now I do. Or at least, we have a process that's working better than anything we tried before.

This is that answer.

The old interview was broken before AI made it obvious

For years, we ran the standard playbook. Whiteboard problem. Timed coding exercise. "Build a REST endpoint in 45 minutes." You know the drill.

Here's what that interview actually tested: can this person write syntactically correct code under pressure, from memory, with someone watching?

That's a real skill. It's just not the skill that matters anymore.

AI handles the code-writing part. I don't mean it handles it perfectly — I wrote a whole article about the 20% it gets wrong. But the 80% that is boilerplate, CRUD, API wrappers, standard patterns? An agent will generate that in seconds. Clean. Typed. Probably with better variable names than I'd pick.

So if I'm hiring someone and my interview tests whether they can do what an agent already does faster — what exactly am I learning?

That they can type under pressure. Great. So can the agent. And it doesn't get nervous.

The interview we actually run now

We stopped asking candidates to write code from scratch. Instead, we hand them code an AI agent already wrote.

The code looks fine. It passes the tests we included. The variable names are clean. The types are correct. A junior looking at it would say "ship it."

But it's wrong.

Not wrong in a way that crashes. Wrong in a way that costs money three weeks later. Wrong in a way that only someone who thinks about consequences would catch.

Here's the shape of it. We give candidates a webhook handler for processing payment confirmations. The handler works. It receives the event, updates the database, returns a 200. Clean code.

What's missing: idempotency. If the bank retries the webhook — and banks always retry — the handler processes the payment twice. The customer gets charged twice. We get an FCA complaint. The code is correct. The system is broken.

Or we show them a payment flow with state transitions. pending to authorised to settled. Looks right. But there's a path where a payment can go from settled back to pending. That's an illegal state transition. In our domain, that means money that was already in a merchant's account could theoretically get pulled back without a refund record. No test catches it because no test was written for a transition that shouldn't exist.

We ask candidates to review this code. Not write it. Review it.

The ones who have the 20% find these things. Not always immediately. Sometimes they stare at it for five minutes and then say "wait — what happens if this gets called twice?" That moment is worth more than any algorithm they could whiteboard.

It's not what they'd change. It's why.

We added a second part to the interview. Once a candidate identifies issues in the AI-generated code, we ask them to walk us through a PR rejection.

Not "what would you change." We already know what needs to change. We want to hear why they'd reject it.

This is where you separate pattern-matchers from engineers.

A pattern-matcher says: "There's no idempotency key. You should add one." Correct. Also surface-level. They've seen the pattern before and recognized its absence. That's good, but it's not enough.

An engineer says: "There's no idempotency key, which means a network retry from the bank will double-process the payment. The customer sees two debits. Your support team gets a ticket. You file a dispute with the acquiring bank. The refund takes 5-7 business days. And if this happens at volume, you've got a regulatory reporting obligation."

Same observation. Completely different depth. The first person knows the pattern. The second person knows what happens downstream when the pattern is missing.

That downstream awareness — the ability to trace a bug forward through the business — is the 20%.

Hire for intent, not resumes

Our interview process changed because our hiring philosophy changed first.

We don't hire resumes. We hire intent. Let me give you three examples.

One developer's resume listed one skill under "Technical Proficiency": Googling. I'm not paraphrasing. That's what it said. B.Sc. No fancy internships. No side projects on GitHub. Just someone who was honest about what they knew and relentless about learning what they didn't. Today they own our merchant-facing app. The whole thing.

Another cold-messaged us asking for a job. No referral. No warm intro. Just a direct message. In the interview, they were quiet. Not shy — quiet. Listened more than they talked. When they did talk, they went straight to the solution. No preamble, no hedging, no "well it depends." Just: here's the problem, here's how I'd fix it, here's what could go wrong.

A third started as an intern. They're now building our Open Banking integration end-to-end. Not assisting. Not maintaining. Building.

The common thread isn't a degree or a tech stack or years of experience. It's three things: curiosity, ownership, and willingness to be wrong.

The first didn't pretend they knew things they didn't. The second didn't try to impress with volume — they impressed with clarity. The third didn't wait for someone to assign harder problems — they grew into them because the problems were there and they weren't afraid to try.

None of them would have passed the old coding interview particularly well. All of them are exactly the kind of engineer you want reviewing an AI agent's output.

The 20% isn't just code — it's design thinking

Here's something most "AI and hiring" articles miss: the 20% that matters isn't only about catching bugs in payment logic. It's about knowing how to think about problems that don't have a spec yet.

Before Atoa, I spent years in design thinking — working with clients who were showcasing products at CES. One project sticks with me. A world-leading chocolate manufacturer wanted to launch a series of chocolates based on human emotions — Anger, Disgust, Sad, Happy, Wimpy. The brief: build software that captures a person's emotion in real-time, recommends the matching chocolate, and makes it go viral on social media.

Now imagine the marketing manager walks into your office and drops this on your desk. The brief is: make it viral. Which platform do you build on? Where does the experience live? What's the feature that makes someone want to share it?

Assume technically anything is possible. The technology isn't the constraint. Your thinking is.

Here's the filter: if your first answer is "I'll build a mobile app and a web app" — that's a straight reject. Not because mobile and web are wrong technologies. But because you jumped to how before you thought about why. You're solving for delivery before you've solved for virality. You're thinking like a developer when the brief asked you to think like a designer.

The interesting answers start with questions. Who's the audience? Where do they already spend time? What makes someone stop scrolling and share something? What's the 3-second hook? How does the chocolate brand benefit from every share? What's the mechanic that makes this grow without paid media?

Now here's my challenge to you: how would you approach this? Drop it in the comments. Not the tech stack — the thinking. How do you decompose this brief into something that actually goes viral?

There's no single right answer. That's the point. This is a design thinking exercise — the kind of problem where the 20% lives. The brief is intentionally vague. The constraints are real. And the interesting part isn't the technology you pick. It's how you think about a problem before you write a single line of code.

No AI agent is writing a spec for that. No benchmark captures the ability to look at a brief like "emotion-based chocolate recommendation engine for CES" and turn it into a system. That's design thinking. The ability to hold a vague, human problem in your head and translate it into technical architecture — while keeping the user experience front and centre.

I look for this in interviews too. Not the ability to solve a well-defined problem. The ability to define the problem in the first place. When I ask a candidate "how would you approach this?" and they immediately start writing code — that tells me something. When they first ask "who's using this, where, and what does success look like?" — that tells me something very different.

The 20% is judgment about code. But it's also judgment about products, users, and what should exist in the world. AI can generate solutions. It can't ask the right question.

What the 20% actually looks like in an interview

Here's what I'm watching for when a candidate reviews code. It's not a checklist — it's a set of signals.

Do they think about what shouldn't happen?

Most engineers think about the happy path. The payment goes through. The webhook fires. The database updates. Done.

The 20% engineers think about the unhappy path first. What happens when the webhook fires twice? What happens when the database write succeeds but the response times out? What happens when the bank says "yes" and our system says "no" and now the money exists in a state neither side agrees on?

If a candidate's first instinct is "how does this work?" — that's fine. If their first instinct is "how does this break?" — that's the signal.

Do they ask about failure modes before writing anything?

We've started noticing this in walkthroughs. Some candidates immediately start typing fixes. Others ask questions first. "What's the retry policy on these webhooks?" "Is there a dead letter queue?" "What happens to in-flight payments if this service goes down?"

The ones who ask first are almost always better engineers. Not because asking is inherently better than doing. But because in the 20% territory — the code that handles edge cases, race conditions, regulatory requirements — the cost of building the wrong thing is higher than the cost of asking one more question.

Can they explain a tradeoff they made, not just what they chose?

This is the question I ask every candidate, regardless of seniority: "Tell me about a technical decision where you chose the worse option on purpose."

The interesting candidates have an answer. "We chose synchronous calls between two services because the audit trail was easier to reason about, even though async would have been more resilient." "We kept a manual process instead of automating it because the edge cases weren't well understood yet and we didn't want to automate the wrong thing."

The 20% is full of decisions like this. The right answer isn't always the technically superior one. Sometimes the right answer is the one that's easier to debug at 2am, or the one that produces a cleaner audit trail, or the one that a new engineer can understand without reading three pages of context.

The junior training pipeline problem

Here's the question that kept me up after the first article: if AI handles 80% of the code, how do juniors ever build the judgment that makes seniors valuable?

The 80% used to be the training ground. You learn to write CRUD endpoints. You learn to wire up a database. You learn to handle HTTP errors. You make mistakes in the boring code, you get them caught in review, and slowly you develop an instinct for the less boring code.

If an agent writes all of that for you on day one, what are you actually learning?

This is a real problem. And "just let them use AI" isn't the answer, because using AI well requires the judgment you're supposed to be building.

I'll be honest — I've had to let someone go because of this exact gap. They were using AI for everything. But they were using the default model in Cursor while the rest of the team had moved to Opus for anything that touched critical code. They weren't thinking about which tool to use when. They were just pressing tab and shipping. The code looked fine. The judgment wasn't there. And in a payment system, that's not a skill gap you can coach around — it's a risk.

At Atoa, we pair juniors with seniors on the hard problems. Not the 80% problems. The 20% ones. The payment state machine that handles twelve edge cases. The webhook handler that has to be idempotent across retries, timeouts, and partial failures. The reconciliation logic where our system says one thing and the bank says another.

The senior doesn't watch the output. They watch the process. They're looking for two things.

First: "What did you skip?" Not what did you get wrong — what did you not even consider? That gap is where the learning lives. A junior who writes a webhook handler and doesn't think about idempotency hasn't made a mistake. They have a blind spot. Mistakes you can catch in tests. Blind spots you can only catch by asking the right question at the right time. That's what the senior is there for.

Second: "What happens when this fails?" Not "did you handle the error." Did you think about what the system does when this component fails? Does the rest of the pipeline stall? Does the customer see a broken state? Does the merchant lose money? The junior doesn't need to have the answer. They need to have the habit of asking the question.

The painful lessons still happen. They just happen faster because the senior is there to compress the feedback loop from "you'll figure this out in three years" to "let me show you why this matters right now."

The best hire isn't the best coder anymore

Three years ago I'd have hired the candidate who wrote the cleanest code the fastest. That person is still good. They're just not rare anymore. An AI agent writes clean code fast. That's table stakes.

The hire I'm looking for now is the person who reads an AI agent's clean, well-typed, properly structured code — and says "this will break in production, and here's exactly how."

That person can tell an agent what it got wrong. More importantly, they can explain why it matters. Not just "add an idempotency key" but "add an idempotency key because the bank will retry, and without it, this elegant code will charge a customer twice."

The 20% was never about writing harder code. It's about knowing which code is dangerous.

We changed our interview because the job changed. The job isn't writing code anymore. The job is judgment.

And judgment is the one thing you can't generate with a prompt.

This is a sequel to AI Agents Are Great at 80% of Our Code. The Other 20% Is Why We Still Need Seniors. If you're building a team that works with AI agents, I'd love to hear how your hiring process has changed. Drop a comment or find me on X @mickyarun.

AI Agents Are Great at 80% of Our Code. The Other 20% Is Why We Still Need Seniors.

arun rajkumar — Thu, 28 May 2026 06:20:38 +0000

We let AI agents loose on a payment platform. They crushed the boring stuff. Then they silently broke the stuff that matters.

A survey came out last week. 54% of all code is now AI-generated. Up from 28% last year.

I read that number and thought: yeah, that tracks. We're probably in that range too.

But here's the thing nobody's asking — which 54%?

Not all code carries equal weight. A CRUD endpoint for fetching merchant details? Low risk. The webhook handler that transitions a payment from pending to complete? That's someone's rent. Someone's payroll. Get that wrong and money moves where it shouldn't, or worse, money doesn't move at all.

I'm the CTO of a payment platform. FCA-authorised, processing real money, real merchants, real consequences. We run NestJS microservices, Docker, Traefik — the usual stack. And we've been using AI agents aggressively for over a year now.

I'm not here to tell you AI is dangerous. It's not.

I'm here to tell you it's dangerous when you forget what it's actually good at.

The 80% Where AI Agents Are Genuinely Brilliant

Let me give credit where it's due. AI agents have made our team faster in ways that would have seemed absurd two years ago.

API scaffolding. Generating service boilerplate. Writing Zod validation schemas. Spinning up new endpoints. Creating test stubs. Refactoring imports. Migrating patterns across repos.

We run multiple microservices. When we need a new service, an agent can scaffold the entire thing — module structure, base configuration, Docker setup, Traefik labels — in minutes. What used to be a half-day of copy-paste-and-tweak is now a conversation.

When we overhauled our env management across all repos, AI agents did the grunt work. They mapped every .env file, found naming conflicts, identified common variables, and generated a unified Zod schema. What would have taken a team days of grep-and-spreadsheet work took hours.

For this 80% of the codebase — the predictable, pattern-following, structurally repetitive code — AI agents are the best junior developers money can buy. Tireless. Cheap. No ego. Almost never make a mistake on the stuff they're good at.

An army of juniors sitting at your terminal.

Then You Hit the Other 20%

Here's where it gets interesting.

We had an agent build out a webhook handler. Webhooks in payments are critical — they're how you know a payment succeeded, failed, or needs attention. The agent wrote the handler. It looked clean. Tests passed.

But it silently ignored the edge cases.

Status transitions have rules. A payment can go from pending to complete. It cannot go from complete back to pending. When a human developer builds this, they think about the illegal transitions because they've seen what happens when money moves backwards. They build the guard because they've felt the pain of not having it.

The agent didn't care about that. It built the happy path beautifully and treated the edge cases like they didn't exist.

When we do this work manually, this type of error never happens. A senior developer who has worked in payments for years doesn't forget the impossible transitions. It's not in their code — it's in their bones.

The Pattern I Keep Seeing

This isn't a one-off. After months of working with AI agents on a regulated payment stack, one pattern is consistent:

AI agents optimise for completion, not correctness.

They want to finish the feature. Get to the green checkmark. And to get there efficiently, they take shortcuts that look reasonable on the surface.

The agent builds what should happen. It rarely builds what should not happen. In payments, the negative cases are where all the real risk lives. What happens when a webhook arrives twice? What happens when a refund is requested on an already-refunded transaction? What happens when the bank returns an unexpected status code? The agent doesn't think about any of that unless you explicitly tell it to.

Then there's the reusability problem. We have shared utility packages. Helper functions. Common patterns that the team has standardised on over years. The agent doesn't care. It writes its own version from scratch. It works, but now you have two implementations of the same logic — one tested and trusted in production, one freshly generated and untested. The agent is focused on completing this feature, not maintaining the architecture.

And the subtlest one — agents seem to optimise for fewer back-and-forth turns. It looks like they're saving cost, saving context. Complex validation? Skip it, the basic case works. Error handling for a rare edge case? Not worth the tokens. The result is code that passes every test you wrote but fails on the scenarios you didn't think to test — because those are exactly the scenarios the agent also didn't think about.

Juniors Don't Ship Products. They Write Code.

Here's the frame that made this click for me.

Claude — or any coding agent — is the best junior developer money can buy. An army of juniors. Tireless, cheap, no ego, near-zero error rate on routine work.

But juniors don't ship products. They write code.

The difference between code and a product is judgment. Knowing which transitions are illegal. Knowing that the retry logic has a specific backoff curve because you've been burned by what happens when it doesn't. Knowing that the webhook handler needs idempotency because banks sometimes send the same notification three times.

That knowledge doesn't come from training data. It comes from years of operating a system, debugging at 2am, explaining to a merchant why their settlement was delayed.

The most dangerous mistake a CTO can make in 2026 is buying AI to replace senior engineers. The right move is buying AI to enable them.

Replace your senior with AI? You get speed plus silent disasters.

Enable your senior with AI? You get an architect with an army.

What We Actually Do About It

I'm not writing this to complain about AI. I'm writing this because we've built a system that works, and it might help you too.

The first thing we did was make our architecture machine-readable. We extract design patterns and architecture rules into formats that agents can consume. When an agent works on our codebase, it doesn't just see code — it sees boundaries, patterns, rules about what belongs where. Not documentation nobody reads. Lints and constraints that the agent can't ignore.

Then we invested heavily in testing the negative cases. Every PR — human or AI — runs through the same suite. But we specifically built tests for the stuff agents skip: illegal state transitions, duplicate webhook handling, idempotency checks. If the agent silently drops a negative case, the tests catch it before it ships.

And seniors still review everything that touches money. No AI-generated payment logic ships without a senior looking at it. Not because we don't trust AI — because we know exactly where it's blind. The review isn't checking syntax. It's checking judgment. Did the agent handle the ambiguous bank status? Did it respect our existing retry logic? Did it use the shared utility or reinvent the wheel?

This problem bothered me enough that I started building Bodhi Orchard — an open-source agentic development framework. The core idea: don't just let agents write code. Feed them the full context — architecture, design patterns, test plans, existing utilities — so they stop making the same blind-spot mistakes. Human decisions over human busywork, with guardrails that actually enforce quality.

The Real Question for 2026

The survey says 54% of code is AI-generated. I believe it.

But here's my question: what percentage of bugs in 2026 will be AI-generated?

And more importantly — who's going to find them?

Not the agents. They wrote the bugs in the first place. Not the juniors — they won't know enough to spot what's missing.

It's going to be the seniors. The architects. The people who've operated these systems long enough to know where the bodies are buried.

The 80% is solved. AI won. Celebrate that.

Now invest in the humans who understand the other 20%. Because that's where your product lives or dies.

I'm Arun, CTO & Co-Founder of Atoa — a UK open banking payment platform. I write about what it's actually like to build fintech with AI, not what the conference slides say it's like. If this resonated, follow me here or on X @mickyarun.

And if you're curious about building AI-native development with proper guardrails, check out Bodhi Orchard.

Your Payment API Wasn't Built for AI Agents. Open Banking Might Be the Fix.

arun rajkumar — Wed, 27 May 2026 11:09:19 +0000

Stripe just shipped an Agentic Commerce Suite. PayPal launched Agent Ready. Visa predicts millions of consumers will use AI agents to complete purchases by the 2026 holiday season. Mastercard introduced Agent Pay with its own verification layer. Google launched the Agent Payments Protocol with 60+ partners.

Everyone is scrambling to make payments work for AI agents.

And I keep looking at all of it thinking: you're bolting agent support onto a stack that was designed for a human staring at a checkout page. That's not an integration. That's a retrofit.

I run payments infrastructure. Our platform processes open banking payments for UK merchants — the kind where money moves directly from the customer's bank account, no card network in between. And from where I sit, the agentic payments conversation has a blind spot the size of Visa's interchange fee.

Let me explain.

The card stack assumes a human is present

Here's what happens when you process a card payment today:

User types card number into a form (or taps a saved card)
Your frontend collects PAN data, sends it to a tokenisation layer
The token goes to an acquirer, who talks to the card network, who talks to the issuing bank
3D Secure kicks in — the user gets a push notification or SMS OTP
The issuing bank authorises (or declines)
Settlement happens days later

That flow was designed around one assumption: a human is sitting at a screen, ready to respond to authentication challenges.

Now replace the human with an AI agent.

The agent doesn't have eyes to read an OTP. It can't tap "approve" on a banking app push notification. It can't solve a CAPTCHA. It can't parse a 3DS iframe that renders differently on every issuing bank's domain.

So what do the card networks do? They build workarounds. Stripe's agentic suite generates virtual cards. Mastercard's Agent Pay pre-registers agents and skips some auth steps. Everyone is finding clever ways to route around the authentication wall that they built.

That's the tell. When your entire ecosystem is engineering around its own security layer, the architecture has a problem.

Open banking was built for machines talking to machines

Open banking works differently. There's no card number. No PAN. No tokenisation vault. No 3DS iframe.

Here's the flow:

Your app (or agent) calls a payment initiation API
The API returns a redirect URL to the customer's bank
The customer authenticates directly with their bank (biometrics, app-based SCA)
The bank confirms the payment
Money moves. Settlement is instant or same-day.

Notice what's different. The payment API is a clean, stateless request-response interface. The authentication happens on the bank's side, not inside your checkout flow. Your code never sees a card number, never handles an OTP, never renders an auth challenge.

For a human using a checkout page, this is a nice UX improvement. For an AI agent calling a payment API, this is a structural advantage.

The agent makes an API call. It gets back a payment URL. It hands that URL to the human for one-time bank authentication. Done. The agent doesn't need to handle auth. The bank does. The separation of concerns is clean.

And with VRPs (Variable Recurring Payments) now live in the UK, it gets even better. The human authenticates once, sets spending limits, and the agent can initiate payments within those limits without any further human interaction. No virtual cards. No pre-registered agent identities. Just an API call against a mandate.

That's not a workaround. That's the architecture actually working as designed.

What breaks when agents use card APIs

I've been watching developers try to build agentic payment flows on card rails. Here's what keeps going wrong:

PCI scope explosion. If your agent is generating virtual cards, storing card tokens, or managing card-on-file relationships, your PCI compliance surface just grew. AI agents that handle card data need the same compliance posture as any system that touches PANs. That's not a small thing. That's SOC2 scope, penetration testing, quarterly scans — all for an agent that could've made a bank-to-bank API call instead.

Authentication is the bottleneck. 3D Secure was designed as a human-in-the-loop check. Every attempt to skip it for agents either weakens security (bad) or creates a parallel auth system (complex and fragile). Open banking's approach — SCA happens at the bank, not at your checkout — means the agent never needs to authenticate. It just calls the API.

Settlement lag creates state management nightmares. Card payments settle in days. When an agent is orchestrating a multi-step workflow (compare prices → select vendor → pay → confirm delivery), it needs to know whether payment actually landed. With cards, you get an authorisation that might reverse, a settlement that arrives Tuesday, and a chargeback window that stays open for months. With open banking, payment confirmation is real-time. The state machine is simpler because the money actually moved.

Micro-payments don't work on card rails. AI agents generate hundreds of micro-transactions per session. The interchange fee floor on card payments makes sub-pound transactions economically absurd. Open banking's fee structure is flat or percentage-based without the card network's minimum — which is why it actually works for the agentic pattern of many small, frequent payments.

What I'd actually build

If I were starting an agentic commerce integration today for UK customers, here's the architecture I'd reach for:

For one-off agent-initiated purchases: Open banking payment initiation. The agent creates a payment request via API, gets a consent URL, passes it to the user. One SCA event, then the money moves. No card data anywhere in the stack.

Agent → Payment API (create payment request)
      → User gets bank auth link
      → User approves in banking app (biometrics)
      → Webhook confirms payment
      → Agent continues workflow

For recurring agent-managed spending: VRP mandates. User sets up a mandate once — monthly cap, per-transaction cap, approved merchant. The agent calls the payment API within those bounds. No re-authentication. No virtual cards. No 3DS.

User → Sets up VRP mandate (one-time SCA)
Agent → Calls payment API within mandate limits
      → Instant confirmation via webhook
      → No further user interaction needed

For the auth layer: Don't build one. Seriously. The bank handles it. Your agent's job is to orchestrate the payment flow, not to authenticate the user. That's separation of concerns, and it's the right call whether you're building for agents or humans.

The real question no one's asking

Everyone is asking "how do we make card payments work for AI agents?"

I think that's the wrong question.

The right question is: why are we starting with the payment rail that requires the most human interaction, then engineering the human out?

Open banking was built on the premise that software talks to bank APIs. The authentication layer lives at the bank. The payment instruction is a clean API call. Settlement is immediate. There's no card number to protect, no 3DS challenge to render, no interchange fee eating your margin on micro-transactions.

It wasn't designed for AI agents. But its architecture fits the agentic pattern better than anything the card networks are retrofitting.

Sometimes the future doesn't come from the company with the biggest R&D budget. Sometimes it comes from the infrastructure that was built on the right abstraction in the first place.

The UK has live open banking rails, live VRPs, and an FCA that's actively building the regulatory framework for what comes next. If you're a developer building agentic commerce for UK customers, you have a head start. Use it.

I'm Arun, CTO at Atoa. We build open banking payment infrastructure for UK merchants. If you want to see what the API looks like: docs.atoa.me

Try the sandbox → docs.atoa.me