DEV Community: arun rajkumar

Your MCP Eval Checklist Has an Auth Row. In Payments It's the Whole Table.

arun rajkumar — Mon, 10 Aug 2026 14:16:19 +0000

There's a good checklist going around dev.to for vetting an MCP server before you wire it into an agent. Four things to look at. Tool surface area: how many tools, and are they atomic or coarse. Auth model: API key, OAuth, token scope. Maintenance: last commit, open issues, is anyone home. Token profile: does it dump a full document when a summary would do.

It's a genuinely good checklist. I've used a version of it. For most tooling categories it's exactly the right lens.

Then you point an agent at something that moves money, and three of those four rows go quiet.

Not because they stop mattering. Because one of them grows until it's the only thing you're really deciding.

A read tool and a write tool are not the same animal

Here's the thing that took us a while to say out loud.

If an agent calls a code-search tool twice, you get the same answer twice and waste a few tokens. If it reads a git diff twice, nobody notices. Reads are safe to repeat. That's the whole reason retries are the default everywhere in the agent stack. A tool call times out, the client tries again, you move on.

A payment tool call is not a read. Retry it once and you've billed someone twice.

We build open banking payments. The failure that actually keeps me up isn't a hallucinated argument or a server returning a forged result. It's the boring one. The connection blips mid-checkout, the client does what clients do and retries, and now there are two payment intents where the user meant one.

So the eval question for a money-moving tool isn't "what's the auth model." It's "what happens on the second call I didn't mean to make."

Idempotency lives on the intent, not the turn

The fix is old and unglamorous. Idempotency keys. Everyone in payments already knows them. The part people get wrong with agents is where the key lives.

The instinct is to make the agent turn idempotent. Same prompt, same result. That's the wrong seam. The agent turn is fuzzy by design, and you don't want it to be the thing carrying the guarantee.

Put the key on the payment intent. The client generates it once, before the tool is ever called, and it travels with the money, not with the conversation.

// The key is minted where the intent is born, not inside the agent loop.
const intent = {
  idempotencyKey: crypto.randomUUID(), // one per real-world payment
  amount: 4200,
  currency: "GBP",
  payee: "merchant_8842",
};

// Retries of the SAME intent collapse to one charge.
// A genuinely new payment gets a new key, on purpose.
await paymentsTool.charge(intent);

Now a dropped connection is harmless. The retry carries the same key, the server recognises it, and the second call returns the first result instead of moving money again. The agent can be as jittery as it likes. The guarantee sits below it, where the stakes are.

Read paths open, write paths gated

The other move is to stop treating "tools" as one category.

On the read side we let the agent run. Fetch balances, list transactions, pull an account's status, look up a payout. If it over-calls, it wastes tokens and we tune it later. Low blast radius, no gate.

On the write side, anything that changes state or moves money goes behind a human confirmation. Not the agent confirming to itself. A person, or a service acting under an explicit, narrow mandate, in the loop before the call executes.

If you're on Claude Code or a similar setup, the cheap version of this is a pre-call hook that classifies the tool and decides whether it needs a gate.

// Classify by side effect, not by name.
const NON_RETRYABLE = new Set(["charge", "refund", "payout", "mandate.create"]);

function preToolUse(call) {
  if (NON_RETRYABLE.has(call.tool)) {
    return requireHumanApproval(call); // blocks until a person says yes
  }
  return allow(call); // reads sail through
}

The point isn't the code. It's the split. Reads and writes want different defaults, and a checklist that scores a server as one thing misses that the same server can hold both.

The credential is a mandate, not a key

The auth row on the checklist usually asks whether it's an API key or OAuth. Fine question. Wrong altitude for payments.

What you actually want to hand an agent is a mandate. Scoped to an amount and a payee. Time-boxed, so it expires whether or not anyone remembers to revoke it. Revocable mid-flight. And auditable after the fact, so when someone asks "why did this money move" there's a straight answer that doesn't depend on trusting the model.

A key says "this caller is allowed." A mandate says "this caller is allowed to move this much, to this party, until this time, and here's the record." The second one is the only thing I'd let near a live payment rail.

We already keep that audit spine for money movement, because we're regulated and there's no version of this job where you don't. The work with agents wasn't inventing it. It was extending the same discipline to tool calls, so an agent's action leaves the same trail a human's would.

So, the checklist

Keep all four rows. For a knowledge base or a code-search server, run the standard lens and move on.

But the moment a tool can move money, promote one question above the rest and answer it first: is this call retryable, and if it isn't, what stops the second one? Everything else on the checklist is downstream of that.

A read tool can be replayed all day. A payment tool replayed once bills a real person real money.

Are you seeing any of the community MCP servers treat retryable and non-retryable tools as different classes yet, or is that still left entirely to whoever's calling them?

Gartner Says 40% of Apps Will Have AI Agents by December. Here's the Plumbing Nobody Puts on the Slide.

arun rajkumar — Mon, 03 Aug 2026 08:09:14 +0000

There's a number going around dev.to this week. Gartner says 40% of enterprise apps will ship a task-specific AI agent by the end of 2026. Last year it was under 5%.

Every deck quotes it. Every thread argues about it. Fine.

I run engineering at a UK payments company. We're FCA-authorised, SOC2, the whole regulated stack. On the side I build an open-source agent framework called Bodhiorchard, where a dozen agents do real work on a real codebase. So I've shipped the thing the slide is describing. And I can tell you the 40% isn't the hard part.

The hard part is everything under the slide. And the biggest piece of it is money.

The demo is not the deployment

An agent demo is easy. You give it a prompt, it writes some code or drafts a report, everyone claps.

Then you try to put it near a live system and the questions start. What can this thing actually call? What happens when it's confidently wrong? Who gets paged?

None of that shows up in a projection. All of it shows up in production.

The real boundary isn't "no money." It's a signed mandate.

The reflex guardrail is to forbid the scary thing. Don't let the agent move money. Read-only, propose-only, a human clicks the button.

That reflex is already history. Agents are going to move money, because paying is half of what it means to finish a task. An agent that can research a supplier, compare options and fill a cart, then stops and waits for a human to tap "confirm," isn't an agent. It's an intern with a shopping list.

This is the part of the 40% that actually rewires the economy. Not agents writing code. Agents that transact. The moment an agent can pay, it stops being an assistant and becomes an economic actor, and the rails for that are being built right now.

That's what we're building at Atoa: a regulated bank rail for AI agents. An agent settles a payment bank to bank, over an FCA-authorised rail, with a signed record on every move. Built for the protocols this is standardising on, AP2 for mandates, x402 for pay-per-request, MCP as the interface. So "never let it touch money" was never going to be our answer. The answer is where the authority lives.

An agent's permission to spend can't be a line in a system prompt that a clever input talks its way around. It has to be a signed, scoped mandate: explicit about how much, to whom, within what limits, and verifiable on its own. Every payment gets a real-time affordability check. Every payment leaves a signed, provable record, who authorised it, what the funds check returned, where it settled.

That's the shift worth internalising. The boundary moved from "can the agent act?" to "is the agent's authority explicit, scoped, and provable?" Money moving for an autonomous agent needs more oversight, not less. So you make the authority a hard artifact and the audit trail non-optional, and then you let it pay.

Context in, not hope in

Here's a real one from Bodhiorchard.

An agent was asked to produce a payout report. Left to its own reading of the task, it started building a brand new service to generate that report. The report already existed. It was about to rebuild something we already had, in a slightly different shape, as new surface area to maintain.

The fix wasn't a smarter prompt. It was context. We feed agents structured context through MCP before they write a line, what we call a BUD in Bodhiorchard. Once the agent could see the existing report and the decisions behind it, it did the sane thing. It extended what was there instead of spawning a duplicate.

That's the difference between an agent that helps and one that quietly grows your tech debt. Not intelligence. Context.

Deterministic checks come before the probabilistic step

An agent's output is a guess. A good guess, often. Still a guess.

So the guess doesn't get to be the last word. Before anything an agent produces goes near a real code path, it runs the checks a human would have to pass. Types. Schema validation. The test suite. The design-pattern lints that encode decisions no off-the-shelf linter ships with. In the payments flow, the affordability check plays the same role: a deterministic gate the probabilistic step has to clear before anything settles.

If that deterministic layer isn't there first, you haven't deployed an agent. You've deployed a very fast intern with commit access and no code review.

Someone owns the failure

This is the part nobody wants on the slide, because it's a headcount question, not a technology one.

When an agent fails, it usually doesn't crash. It fails plausibly. The report looks right. The code compiles. The number is just wrong. That kind of failure needs a human owner who knows the domain well enough to smell it, and a record clean enough to trace it back.

My mental model: an agent is an army of near-zero-mistake juniors. That's a gift to a senior engineer and a trap for a team without one. Enabling seniors with agents is the right move. Replacing seniors with agents is how you find out what plausible failure costs.

So

Yes, 40% of apps will probably have an agent by December. The slide will be right.

But the agent isn't the work. The scoped mandate, the context feed, the deterministic gate, the human who owns the failure. That's the work. That's the 60% under the waterline.

And the biggest piece of that iceberg is payments. The agent economy doesn't start when models get smarter. It starts when agents can pay, safely, over rails that were built for them. That's not a 2030 story. It's live now, and we're building one of the rails.

If you're shipping an agent this year, which of those four do you already have, and which are you hoping the model handles for you?

AI Agents Ship Bugs When They're Blind. So We Stopped Building Blind.

arun rajkumar — Fri, 31 Jul 2026 06:51:09 +0000

Most AI coding mistakes don't look like mistakes.

They compile. The tests pass. CI is green. The diff reads fine at 6pm on a Friday. Sometimes it's a bug that surfaces two weeks later when money moves where it shouldn't. And sometimes it's not a bug at all — the agent quietly rebuilds something you already had, and you don't notice until you're maintaining two versions of the same thing.

Same root cause both times. The agent couldn't see. It had my prompt. It didn't have the codebase.

I'm the CTO of a payments company. We're FCA-authorised, we move real money for real merchants, and we've leaned on AI agents hard for over a year. So I've watched this happen enough to stop blaming the model for it. Let me show you exactly what I mean, because it happened to me last week.

The report that didn't need to exist

We were adding multi-business support to payouts. One parent account, several businesses underneath it, each needing its own slice of the flow.

The agent did the core work well. I want to be clear about that. On the multi-business payout logic itself, the code was correct. No complaints.

Then I asked for a small follow-on: add callback parameters and a few dynamic fields into the payout report.

The agent went and built a new reporting service. New repo, fresh scaffolding, a whole new report pipeline. It worked. It compiled, it ran, it produced exactly the report I'd asked for.

One problem. We already had a payout report — the single-business one, live in production, tested against real settlements for months. The right move was to extend it to handle multiple businesses and the new fields. Instead I now had two report implementations for the same domain. One battle-tested, one freshly minted. And every future change to payout reporting would either be made twice or silently drift apart.

That's not a bug. Nothing broke. It's worse in a quieter way. It's code-quality debt the agent created because it couldn't see that the thing it was building already existed.

This is the part I keep coming back to. It's not only about bugs. It's about code quality. A blind agent doesn't just get logic wrong. It reinvents, it duplicates, it walks past the shared helper and writes a fourth one. Every instance of that is a small tax you pay forever.

Why a senior wouldn't have done this

A coding agent is the best junior developer money can buy. Tireless, cheap, no ego, near-zero mistakes on routine work. An army of them at your terminal.

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

A senior handed that report task would have opened with a different question. Not "how do I build a report" but "don't we already have one of these?" That instinct isn't in training data. It comes from having maintained a codebase long enough to know that a second implementation of anything is a liability, not a feature.

The agent never asked that question. Not because it's dumb. Because it only had my sentence. It had no way to know the single-business report existed, where it lived, or that extending it was the whole job.

So the problem stopped being "how do I get a smarter agent" and became "how do I put the judgment a senior carries in their bones somewhere the agent can read it — before it writes a line."

That question is why I built Bodhiorchard. It's open source, Apache 2.0, self-hosted. We run it at Atoa now.

We stopped handing agents a prompt. We hand them a BUD.

The unit of work in Bodhiorchard isn't a Jira ticket. It's a BUD — a Business Understanding Document. One living source of truth for a feature: what it is, why it exists, who asked for it, the design, the tech spec, the decisions made along the way. Vector-indexed, full history, no scatter across Confluence and Slack and someone's memory.

The point of a BUD is that the context is attached to the work, not floating around it. And crucially, Bodhiorchard traces a feature down to the actual code that implements it. A feature isn't a paragraph. It's a paragraph wired to the files, services, and procedures that make it real.

Work moves through seven phases, each its own tab on the BUD:

Requirements → Design → Tech Spec → Development → Code Review → Testing → Prod

Every phase has an agent. Every phase also has a toggle. Flip the agents off and it says "you're driving this BUD" — human in the loop, by design. This was never meant to run while you sleep.

The same task, inside Bodhiorchard

So I gave it the same job. Add callback params and dynamic fields to the payout report. Same class of model. Same one-line request.

This time it didn't start blind. The request came in against the payout feature's BUD, and because the BUD is wired to code, the agent pulled the context over MCP and found the existing single-business report — the real procedure, in the real repo — before it wrote anything.

# The agent reads context before writing — and finds what already exists
POST /mcp   → get_bud_context(bud_id: "PAYOUTS-217")

{
  "feature": "Payouts — multi-business support",
  "request": "add callback params + dynamic fields to the payout report",
  "precedent": {
    "report": "services/reporting → PayoutReport (single-business, live in prod)",
    "guidance": "extend this. do not stand up a second report pipeline."
  },
  "domain_rules": [
    "One report implementation per domain",
    "Reporting reads the ledger projection, never writes to it"
  ]
}

It extended the existing report. Multi-business, dynamic fields, callback params, added to the code that was already there. No new service. No second pipeline. One report that now does more.

The difference wasn't intelligence. It was sight. One agent could see the codebase and one couldn't.

And notice what the agent gets to do versus what it doesn't. The MCP write tools are bounded to the creative phases — it can create and update a BUD, draft the spec, propose the code. Nothing that moves money is a tool an agent can call directly. Read and propose across everything. Execute nothing with a blast radius. That line is drawn on purpose.

Behind the context sits a mechanical gate. Design-pattern lints run in CI, and if an agent reaches for a banned pattern or stands up a duplicate where an ADR says there should be one, the build fails. Not "a reviewer might catch it." The gate fails, every time. And the test suite leans hard on the negative cases agents love to skip — the illegal state transition, the duplicate event, the report that should have been an extension.

The scoreboard is pointed at the thing AI is worst at

Bodhiorchard has a scoreboard, and it does not reward output. It rewards shipped, working value.

You earn points when a BUD reaches production and when your code-review quality holds above a threshold. You lose a point for a bug caught in testing, and more for one that reaches production. The payout only lands when the feature is closed end-to-end, not when the PR merges.

Read that incentive again. It pays for correctness that survives production and for quality that holds up in review — exactly the things a fast, blind agent erodes when it's optimising for a green checkmark. Volume of code earns you nothing. A duplicate report that passes its own tests earns you nothing. Shipping the right thing does.

The honest status

I'm not going to tell you the agents run the whole SDLC while we sleep. They don't. The platform, the BUD lifecycle, the MCP context path, the feature-to-code indexing, the skill profiling — that's live and we use it daily. A fully autonomous execution loop is still being built. Today it's agent-assisted with a human in the loop at the phases that carry weight, and for anything touching payments that's exactly where I want it.

Where do agents own a boundary? Reading context, finding precedent, proposing a spec, drafting code, linting against recorded decisions. Where do they never own one? Anything where the failure mode is money in the wrong account. That's not a limitation I'm apologising for. That's the design.

So, back to blindness

The new report was never a model failure. Neither was the duplicate-refund class of bug before it. Both came from the same place: handing something a blank prompt and hoping it would guess the code you'd already written and the decisions you'd already made.

Give it the context a senior would carry into the review — the domain rules, the precedent, the boundaries, the code that already exists — and put a mechanical gate behind that context so nobody, human or agent, ships past it. The agent stops reinventing your codebase and starts extending it. It stops being a liability and starts being the army your seniors always wanted.

The 80% was already solved. This is how you stop the other 20% from shipping bugs — and from quietly rotting your code quality — while you're not looking.

What's the last thing an agent rebuilt in your codebase that already existed — and where was the context it needed to find it?

I'm Arun, CTO and co-founder at Atoa, building open banking payments for the UK. I built Bodhiorchard, it's open source, and we run it in our workflow. Repo's here if you want to poke at it — feedback over stars: github.com/mickyarun/bodhiorchard. Find me on X @mickyarun.

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.