DEV Community: Thomas Hansen

Why Claude Is 10x Cheaper When It Builds on Magic Cloud

Thomas Hansen — Thu, 06 Aug 2026 07:05:32 +0000

Everyone optimizes the wrong variable.

Cheaper models.
Shorter prompts.
Compressed context.

That all helps a little.

But look at Anthropic's rate card instead, and one asymmetry jumps out: output tokens cost 5x input tokens on every current model. Claude Fable 5 is $10 per million tokens in, and $50 per million tokens out.

Which means the most expensive thing your AI agent does is write code as output.

Magic is architected so it doesn't.

And rather than argue this in the abstract, we let Claude build a complete full-stack app on our hyperlambda.dev cloudlet — while measuring everything.

The rate card, straight from Anthropic

These are Anthropic's official API prices, per million tokens, fetched from their pricing documentation on August 6, 2026:

Model	Input	Output
Claude Fable 5	$10	$50
Claude Opus 5 / 4.8	$5	$25
Claude Sonnet 5 (intro, through Aug 31)	$2	$10
Claude Sonnet 4.6 / Sonnet 5 (from Sep 1)	$3	$15
Claude Haiku 4.5	$1	$5

Two things are worth staring at.

First, the output multiple is universal. Every tier charges 5x more for what the model writes than for what it reads.

Second, Anthropic's newer tokenizer — used by Claude 4.7 and later — produces roughly 30% more tokens for the same text. Round-tripping source code through a model's context literally got more expensive this year.

Prompt caching and the Batch API can discount those rates. But a discount on waste is still waste. The interesting question is why the tokens are being spent at all.

Where a coding agent's tokens actually go

A conventional coding agent building a backend runs a loop.

Read files. That is input.
Write code. That is output, at 5x.
Read the error. Input again.
Rewrite. Output again.
Re-read to verify. Input again.

Every debug iteration compounds, and the compounding happens at the most expensive rate on the card. The model is not reasoning in most of those moments. It is acting as a very costly transport layer for source code.

I have written before about how Hyperlambda changes these economics and measured roughly 80 percent savings on a Fable-priced build. This article is about the mechanism underneath those numbers — and a fresh build with its own receipts.

What we built to prove it

We asked Claude to build Token Ledger: an LLM spend tracker.

Yes, that is deliberately meta. Claude built a token-cost dashboard while its own token cost was being metered.

The deliverable: a SQLite database with three linked tables — providers, models, and a usage log — seeded with Anthropic's actual rate card from the table above. Fifteen HTTP endpoints, every one of them role-secured. Two aggregation endpoints feeding charts. And a designed, dark, authenticated dashboard.

Look at the dashboard's own numbers for a moment. The second KPI card reads "output share of spend: 37%" — on a realistic mixed workload, over a third of the bill is output tokens. And the spend-by-model chart shows Fable 5 dwarfing everything else, because at $50 per million output tokens, it does.

The app is arguing the article's thesis from inside the screenshot.

The build ledger

Wall-clock time was measured with timestamps, not estimated.

What	Number
Live secured backend — database, schema, seed data, 15 endpoints	222 seconds
Complete working app, including the hand-written frontend	431 seconds
Backend lines of code generated	669
Backend lines of code hand-written	0
Claude output tokens spent on backend code	0

The last row is the entire article.

The backend was produced by twelve calls to Magic's CRUD generator and three calls to its SQL endpoint generator. Each call is a compact declarative argument — a table name, a column list, a role restriction, an SQL statement. Around a hundred tokens each, roughly 1,500 tokens of arguments in total.

Not one of the 669 generated lines passed through Claude's output stream at $50 per million tokens. The platform wrote them, server-side, using the same battle-tested generators the Magic dashboard uses.

Honest scope on the numbers: the 222 seconds include reading the platform's guides and setting up the design tokens. Screenshots and end-to-end verification came after the 431-second mark and included two pauses waiting for human tool approval, so they are excluded from the build figures.

That login screen is not decoration. Every endpoint behind it is gated by Magic's built-in RBAC — no hand-rolled JWT handling anywhere, because there is no hand-written backend anywhere.

The five mechanisms

Why does this architecture starve the token meter? Five reasons, each visible in the build above.

1. Declarative calls replace emitted code

One CRUD-generator call is roughly a hundred output tokens of arguments. It produces a complete endpoint — paging, sorting, filtering, validation, auth — of sixty to a hundred and twenty lines. Streaming the equivalent as source code is thousands of output tokens, usually across multiple attempts. In this build, 1,500 tokens of arguments bought 669 lines of backend.

2. Code generation happens server-side

When something bespoke is needed, Magic's Hyperlambda Generator takes a plain-English prompt and writes the file on the server. The code never enters Claude's output stream or its input stream. Claude pays for a sentence, not a source file. And here is the stronger version of that point: this particular build needed zero generator calls. The declarative tools covered the entire backend.

3. Code never round-trips through context

Magic's operating rules forbid the agent from reading generated Hyperlambda back. Verification goes through live HTTP invocation and the OpenAPI spec. A conventional coding agent re-reads its files constantly — every read is input tokens, every edit is output tokens. On Magic, that loop is not discouraged. It is structurally impossible.

4. No debug spirals

The generators are deterministic. There is no generate, error, paste-the-stacktrace, regenerate cycle — the invisible multiplier on every agent bill. This build's complete bug ledger: one entry, a headless-browser viewport quirk while taking screenshots. Zero bugs in 669 generated backend lines.

5. One-call grounding

At session start, one call returns who the agent is, what backend it is on, and its full operating instructions. One more call returns the exact list of capabilities that exist on the instance. Compare that with an agent grepping directories and reading files to discover what a codebase can do — all of it billed as input, none of it producing anything.

The accounting: same app, two architectures

Take the same deliverable — the Token Ledger backend, fifteen secured endpoints — and price both paths at Anthropic's current rates.

The Magic column is this build. The coding-agent column is a calibrated estimate for the same result via a conventional file-editing agent — scaffold, routes, auth, validation, and the customary debug loops — consistent with the roughly 140,000-versus-25,000-token gap measured in the July benchmark, with the backend-code share broken out.

	Claude on Magic (measured shape)	Claude with generic tooling (estimate)
Output tokens spent on backend code	0	~30,000
Total output tokens, backend slice	~2,000	~35,000
Total input tokens, backend slice	~30,000	~180,000
Cost at Fable 5 ($10 / $50)	≈ $0.40	≈ $3.55
Cost at Opus 5 ($5 / $25)	≈ $0.20	≈ $1.78
Cost at Sonnet 4.6 ($3 / $15)	≈ $0.12	≈ $1.07

Call it roughly 9x on this app, and the estimate columns are labeled as exactly that — estimates. The ratio is not a constant of nature. It is a consequence of one design decision: source code, the most expensive thing a model can emit, never enters the token stream.

And notice what happens as the app grows. A CRUD-generator argument is about a hundred tokens whether the table has three columns or thirty. Hand-written code is not. The gap widens with size.

Where 10x holds — and where it is 5x

Now the honest fine print.

The July benchmark measured roughly 80 percent — 5x — across a full session, because a real session also contains reasoning, planning, schema decisions, and verification, and those do not compress. The frontend in this build was hand-written by the agent, at normal output rates, and took as long as the entire backend.

The 10x figure belongs to the code-emission slice of the work: the backend, the endpoints, the auth, the data layer. On backend-heavy agentic workloads that slice dominates, and the blended number climbs toward it. On reasoning-heavy work, expect the 5x, not the 10x.

Both numbers are worth having. Neither requires exaggeration.

Conclusion

The standard advice for cutting Claude costs is to pick a smaller model, cache your prompts, and batch your jobs. All fine. All discounts on the same architecture.

Magic changes the architecture. The agent stops being a code emitter paying $50 per million tokens for the privilege, and becomes an operator of a platform that already knows how to build backends — declaratively, server-side, with security enforced by the runtime instead of regenerated per project.

We measured it: a live, role-secured, fifteen-endpoint backend in 222 seconds, 669 lines generated, zero lines through the token meter.

Claude is a great engineer. Stop paying it by the line.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

Originally published at hyperlambda.dev.

Break my AI Sandbox and make $100 - Psst, nobody's done it yet!

Thomas Hansen — Sat, 01 Aug 2026 10:10:45 +0000

I have a standing offer: find a verified security bug in Magic's backend — the C# code or the Hyperlambda runtime — and I'll pay you $100.

Nobody has collected.

$100 is obviously not the point. Companies pay 100 times that for bounties on software with a fraction of the attack surface. The point is that I'm willing to put money on the architecture, publicly, permanently — because the architecture is the product.

The runtime is the security boundary

Most AI coding tools work like this: the model generates free-form code, and you hope it generated something safe. The model is the security boundary. Which means every prompt injection, every hallucination, every "ignore previous instructions" is a potential breach.

Hyperlambda inverts this. The AI generates code, but the runtime decides what executes:

Hyperlambda is not free-form code. It's a declarative structure that parses into an AST, and the runtime validates that AST before anything runs.
Slots are whitelisted. If a slot isn't on the whitelist for the current context, it doesn't execute. Period. The AI can hallucinate whatever it wants — the runtime says no.
RBAC is enforced at execution time, not generation time. It doesn't matter what code was generated or by whom. If your JWT doesn't carry the role, the invocation is refused.

If the AI writes something it shouldn't run, the runtime says no. That single sentence is the difference between a demo and something a regulated company can ship.

Receipts

I don't expect you to take my word for it. In April I let Claude Code — one of the strongest code-analysis agents available — loose on the entire Magic codebase with explicit instructions to break it.

It found real issues. All hardening, none sandbox escapes:

No cap on request body size, allowing a memory-exhaustion DoS. Fixed.
Missing timeouts that left the server exposed to Slowloris-style slow-drip attacks. Fixed.
An edge case in path resolution that needed an explicit traversal guard. Fixed.
A debug statement leaking information to the console. Removed.

And here's what it couldn't do, after crawling roughly 9,000 commits accumulated over some 7 years:

No SQL injection. Every database access goes through parameterized ADO.NET.
No password extraction. BCrypt with per-user salts.
No secrets leakage. AES-GCM for storage.
No auth bypass. Standard JWT, correctly implemented.
No sandbox escape. Every attempt to execute something outside the whitelisted slots was refused by the runtime.

The full write-up is here: Claude Code tried to break Magic Cloud, and mostly ended up confirming its security.

Why free-form codegen can't make this offer

Think about what it would take for an AI agent platform built on free-form code generation to make the same offer.

They'd be paying out daily. When the model is the boundary, one clever prompt is a breach. The industry's answer so far has been layers of prompt-level guardrails — instructions asking the model to please behave. That's not security. That's etiquette.

When the runtime is the boundary, the model's behavior becomes almost irrelevant to your security posture. The model can be jailbroken, poisoned, or just plain wrong — and the blast radius is a refused invocation and a log entry.

This is why I can put a standing bounty on it. The security claim isn't "our AI is well-behaved." The claim is "the runtime refuses everything that isn't explicitly allowed." That's a falsifiable, testable claim — so go test it.

How to collect

Go to playground.hyperlambda.dev and hammer it. Or self-host — the whole thing is MIT licensed, so you can read every line of the code you're attacking.
Find a verified bug in the backend C# or Hyperlambda code. Sandbox escape, RBAC bypass, executing a non-whitelisted slot — anything that breaks the security model.
Send it to me. I verify it, I fix it, I pay you $100, and I'll publicly credit you for the find.

Prompt-level shenanigans against the AI itself don't count — making a chatbot say something silly is not a runtime breach. The claim under test is the runtime.

If you're evaluating AI agent platforms

Ask every vendor you're talking to one question: what happens when the AI generates something it shouldn't?

If the answer involves the words "the model is trained to" or "our system prompt instructs" — you're buying etiquette, not security. If the answer is a deterministic runtime mechanism you can read the source code of, you're buying engineering.

Magic has been running in production since 2020. It's MIT licensed. The code is at github.com/polterguy/magic, and the docs are at docs.ainiro.io.

Break it and make $100. Psst — nobody's done it yet.

Originally published at hyperlambda.dev.

Turn Your Legacy SQL Server Database into a Modern Full Stack App in Minutes

Thomas Hansen — Fri, 31 Jul 2026 20:42:35 +0000

The app in the screenshots below took 7 minutes to build.

Not a mockup. A login screen backed by JWT authentication, a client manager reading and writing through a role-secured CRUD API, and an Emails tab that dispatches real messages over SMTP. The backend was produced by wrapping a database in generated CRUD endpoints, plus one English sentence handed to the Hyperlambda Generator for the send-email endpoint.

I have published the receipts for builds like this before, so this article is not another ledger.

It is about the part of those 7 minutes that usually gets lost.

The database was the boring part

Nothing in the build depended on the database being new.

The CRUD generator does not care where a schema came from. It reads metadata — tables, columns, types, keys — and every Microsoft SQL Server database on earth exposes exactly that. The database in this demo was created seconds before the endpoints were. Yours carries twenty years of history, three generations of developers, and foreign keys that encode how your business actually works.

Same metadata. Same generator. Same 7 minutes.

That is the entire point. The demos always run on fresh databases because demos need reproducibility — but the machinery only ever sees the schema, and your ERP on SQL Server has a better schema than any demo. The hard part of a full stack app — modelling the business correctly — is the part you finished years ago.

What got built

The front door. JWT authentication against the platform's built-in auth — no auth library, no password hashing code, no session plumbing anywhere in the app.

The client manager. Search, add, edit, delete, and per-client notes — every operation travelling through generated CRUD endpoints, each one gated on a role before any logic runs.

And the one endpoint that is not a table projection: composing an email to a client, dispatched through the platform's SMTP integration. That endpoint was described in a single English sentence and generated in seconds — the application never saw a mail-provider credential, because there is none in the application.

The recipe

Four moves.

Connect the database. Magic speaks to SQL Server through the standard .NET data provider — it is one more client, nothing installed inside the database, no schema changes.

Wrap the tables. The CRUD generator reads the schema and emits endpoints — read, create, update, delete, count — with authentication and role-based access control already wired in.

Describe what CRUD cannot do. "Look up this client's email address and send them a message" is one sentence, and the Hyperlambda Generator turns it into a working, role-gated endpoint.

Serve the frontend. The same system that serves the API serves static files, so the app's HTML, CSS and JavaScript went live the moment they were written. One host, no CORS, no separate deployment.

The full walkthrough — scoped database users, read-only starts, connecting an agent over MCP — is its own article: Create an AI Agent From Your SQL Server or MySQL Database, Step by Step.

No agent required

This build ran through an AI agent over MCP, but the CRUD wrap does not need one. The dashboard's Backend Generator does the same thing point-and-click: pick the database, tick the tables, choose which roles may call what, and click Generate.

Same generated endpoints, same enforcement, no conversation required. The agent is a convenience, not a dependency.

"But my database is legacy"

Legacy means load-bearing, not obsolete — I have made that argument at length in Supabase for SQL Server and MySQL, so here is the short version.

You connect through a scoped database user, so the platform can never do more than the credentials the DBA granted. You can start read-only, which turns "what if something writes the wrong thing" into a non-question for day one. And the whole stack runs in two containers you place yourself — same rack, same VLAN, same firewall the auditors already approved. The database does not change, and the data does not leave.

The fine print

Seven minutes was measured for this schema, at this size. Your 200-table ERP will take longer — but the added time goes into decisions, not code: which tables deserve exposure, which operations each table gets, which roles may call them. Those are judgment calls a DBA is already equipped to make, and they were never the expensive part.

The frontend is where human taste still spends its time. Generated backends are uniform; good interfaces are not.

And writes deserve the same respect they have always deserved. Start read-only, prove the surface, then grant writes table by table. The speed changes nothing about the discipline.

The question worth asking

The question is no longer whether your organisation can afford to modernise the systems built on SQL Server. It is whether wrapping one of them in a secured API and a working app is still a project at all — or just an afternoon.

Magic is MIT-licensed and open source at github.com/polterguy/magic, with documentation at docs.ainiro.io.

46,000 Lines of Angular, Gone in a Weekend

Thomas Hansen — Mon, 27 Jul 2026 07:14:31 +0000

I replaced the entire Magic Cloud dashboard this week. Forty-six thousand lines of Angular — HTML, TypeScript and CSS — gone, and in its place a React application of fifteen and a half thousand lines that does more than the thing it replaced.

Twenty hours of coding. Thirty hours in total, counting my own reviewing, testing and swearing.

I know exactly what that job costs when you do it by hand, because I have already done it by hand. In 2021 I rewrote this same dashboard the traditional way. A senior developer worked on it for a month and a half. Then I picked it up and worked on it for months more. Call it a three-month job for two experienced developers who knew the domain cold.

That comparison is the only reason this article is worth writing. Anyone can claim an AI wrote a lot of code quickly. Very few people have the same application, built twice, by the same author, with the same requirements — where the only variable that changed is the tooling.

The ledger

	Then	Now
Framework	Angular	React 18 + Vite + TypeScript
Lines of code	~46,000	15,497
Files	many hundreds	47
Runtime dependencies	the Angular universe	7
Production build	tens of MB	856 KB
Build time	minutes	~1 second
Time to write	~3 months, two people	30 hours, one person supervising

A word on that line-count comparison, because it is the kind of number people rightly poke at. Angular splits a single component across a .ts file, an .html template and an .scss stylesheet. React folds all three into one .tsx. Counting the old TypeScript against the new TypeScript would flatter me dishonestly, so both sides count everything: markup, logic and styling. Forty-six thousand against fifteen and a half.

The dependency line matters more than it looks. The whole application runs on React, React-DOM, React Router, CodeMirror, SignalR, marked and DOMPurify. That is the entire third-party surface. There is no state management library, no component library, no CSS framework, no build plugin zoo. When your dependency list fits in one sentence, upgrades stop being events.

How it actually ran

I drove Claude — Fable for the bulk of the work, Opus for the parts that needed more thinking. The model wrote essentially all of the code. My job was to babysit: sanity-check what came back, test it in a browser, catch the things that were confidently wrong, and decide what to build next.

The loop that made it work was not "describe the feature and hope." It was: screenshot the old Angular screen, build the new one, screenshot the new one, compare them, fix the gap. Verification happened against rendered pages, not against source code. That distinction matters, because a model reading old Angular source will faithfully reproduce old Angular mistakes. A model looking at what the screen actually does will build what the screen actually does.

Below is what came out of that loop, screen by screen — because the interesting claim is not that thirty hours produced code, it is that thirty hours produced this much working software.

Login

The dashboard talks to any Magic backend, so the first thing it needs is which one. The backend selector remembers every cloudlet you have ever signed into and keeps a separate JWT for each, so switching between them does not mean signing in again.

Underneath the password field are two things the Angular version never had. Magnetic link sends a temporary sign-in link to your email — it doubles as passwordless login, and it only appears if the backend actually has SMTP configured, because offering it otherwise is a dead end. Continue with Google signs you in over OIDC against whatever providers the backend has registered. Both were built during this port, not ported into it.

Dashboard

The landing screen answers "what is this cloudlet, and is anything wrong with it" in one glance: version, endpoint count, users, tasks, log items.

Two panels below that are new. The first announces that your cloudlet is an AI agent — with the MCP plugin installed, the URL shown there hands any MCP-capable agent your endpoints as callable tools. Claude, or anything else speaking the protocol, can discover and invoke them directly.

The second is the Chatbot Wizard, which runs the other direction: give it a website, pick a model and a persona, and the backend crawls the site, turns what it finds into training data, and gives you an embeddable chatbot grounded in your own content. The crawl takes minutes and reports progress over a SignalR channel, so the feedback window opens before the job starts — a socket that connects late misses the first messages. You can close the window; the crawl carries on.

Hyper IDE

The file manager and code editor for everything on your server, and the component that absorbed the most work.

The tree browses the whole backend file system. Files open as tabs, several at once, and each tab tracks whether it is dirty — a dot appears on the tab and beside the path in the header the moment you change something, and navigating away asks before discarding it. The editor runs a Hyperlambda mode ported from the old dashboard, so slot invocations are coloured correctly, and Ctrl+Space completes against the backend's actual vocabulary — the list of slots is fetched from the server you are connected to, and cached per backend, because two cloudlets with different plugins know different slots. That is the popup in the screenshot above, listing the log.* slots this particular cloudlet knows about.

Executing a file is smarter than it was. If the file is a real HTTP endpoint — it ends in .get.hl, .post.hl and friends, and lives under /modules/ or /system/ — the IDE invokes it as an endpoint, with arguments, and shows you the status code and response headers. Only files that are not endpoints get evaluated directly. You can upload and download files, preview HTML, XML, images, JavaScript and CSS straight from /etc/www/, and press F1 on any selection to ask the AI what it does.

Playground

Hyperlambda, executed on your server, without saving anything first. Input on the left, result on the right, F5 to run. It is the scratchpad you reach for when you want to know what a slot actually returns, and it saves snippets when the scratch turns out to be worth keeping.

SQL Studio

Two tabs over the same three selectors: database type, connection string, database.

The SQL tab is a query editor with syntax colouring, Ctrl+Space completion over your real tables and columns, saved snippets, .sql import, CSV export of results, and a Safe mode toggle that caps what a careless query can do. Selecting part of the text executes only the selection.

The Designer tab is the one I am quietest about and proudest of. It renders every table in the database as a card — primary keys, column types, nullability, and the foreign keys spelled out underneath — and lets you add tables, add columns and wire up relations without writing DDL. It will also hand you the DDL for a single table or the whole database if you would rather write it yourself.

Databases

Create SQLite databases, back them up, restore them from an uploaded backup, delete the ones you no longer need — and, on the second tab, connect to external MySQL, PostgreSQL and SQL Server instances. Everything else in the dashboard then treats those exactly like a local database.

Generator

Point it at a database, tick the tables, and it writes you a complete CRUD backend: POST, GET, PUT and DELETE per table, with paging, sorting, aggregates, distinct and search endpoints if you want them. You choose which roles may call what, whether writes are logged, how long GET responses may be cached, and whether existing files may be overwritten. The second tab wraps a custom SQL statement in an endpoint of its own.

This is the part that turns a schema into a secured API in seconds, and it is why the backend is rarely where the time goes.

Endpoints

Every endpoint on the backend, grouped by module, with its HTTP verb. Open one and you get a form built from its actual arguments — fill them in, invoke it, and see the status code, the response headers and the body rendered according to its content type.

It handles files in both directions now, which it did not before: endpoints that accept multipart/form-data get a proper file picker with image thumbnails inline, and endpoints that return files offer them as downloads. Each module will also hand you its OpenAPI specification, which is how you point an external tool — or an agent — at a subset of your API.

Users and roles

Who may reach your backend, and what they may do. Create users, assign roles, change passwords, lock accounts. Roles are the same objects the Generator gates endpoints with and the same ones inside the JWT, so this screen is the authorisation surface for the entire platform in one table.

Task Manager

Hyperlambda that runs on a schedule or on demand — backups, cleanup jobs, crawls, alerts. Tasks can repeat on an interval, fire once at a fixed date, or follow a custom repetition pattern, and you can execute any of them immediately to see what happens. Executing asks first, because a task named delete-old-log-items means it.

Machine Learning

The largest single screen in the application, at two thousand lines. Models define which LLM answers, at what temperature, with what system message and what threshold. Training data is the content those models answer from — crawled from a site, uploaded as files, or written by hand. Vectorising turns it into embeddings; embedding hands you the snippet that drops the finished chatbot onto a web page. A history tab shows what people actually asked it.

Plugins

The Bazar: MCP, OAuth, OpenAI, Ollama, HuggingFace, Shopify, HubSpot, NetSuite, scraping, charts, and a couple of dozen more. One click installs a module into your cloudlet, endpoints and all. You can also install your own from a ZIP file.

Profile

Your name, your email, your password — and access tokens, which is the part that matters operationally. Generate a long-lived JWT for a service account, a CI pipeline or an integration, scoped to the roles you pick and expiring on a date you choose.

Log

What your backend has been doing, newest first, filterable, with severity on every row. It is where you go when something did not work, and the generated CRUD endpoints write to it automatically when you ask them to log writes.

What got better, not just moved

If this had been a straight translation I would not have bothered writing about it. The features that did not exist in the Angular version, all built inside those same thirty hours:

OIDC login — sign in with Google or any registered provider
File upload and download through the Endpoints screen, with inline image previews
Dirty-file tracking across Hyper IDE, SQL Studio and the Playground
Multiple files open at once, as tabs
Multi-backend support with a separate JWT per cloudlet and shareable ?backend= links
Magnetic-link login for passwordless sign-in
The MCP agent banner and the Chatbot Wizard
Previewing HTML, XML, images, JavaScript and CSS from /etc/www/
An AI support agent on F1, answering from the Hyperlambda and Magic documentation

The bug ledger

Two rules make this kind of build survivable: the model writes, and a human reviews everything before it lands. Here is what the review caught.

React's StrictMode caused three separate bugs. It deliberately runs effects twice in development, which broke an image preview (the object URL was revoked before the image loaded), killed a SignalR connection (started and stopped in the same tick), and made two stacked dialogs land on the same z-index. All three were the same root cause wearing different hats, and all three were found by looking at the screen, not the code.

The model invented a slot that does not exist. It used date.add for date arithmetic. There is no such slot. The fix was math.add with a time node — the pattern already used elsewhere in the codebase.

It invented a role, too. It gated the dashboard on an admin role. The backend has 159 endpoints and every one of them checks root. Caught during review, renamed everywhere.

A mail endpoint was built with the wrong node shape, which produced a runtime error rather than an email. A magnetic link took three attempts to redirect correctly, because the token was being stripped from the URL before a second render could read it. An expired token walked straight into the dashboard, because expiry was being checked without asking the server whether the token was still valid.

And two mistakes the model made about its own work, which I include because they are the most instructive of the lot. It told me one screen had no confirmation dialog before running a destructive task — it had searched the code in a way that could not have found the guard, which was sitting six lines above what it read. And it told me a screenshot I had pushed did not exist, when the file was recoverable the whole time. Both were confidently wrong, and both were wrong in the same direction: reporting an absence after looking in the wrong place.

Nothing on this list shipped. But the list is the honest cost of the method, and anyone telling you their AI build had no such list is not counting.

What this actually demonstrates

It would be easy to read this as "AI writes code fast." That is not the finding, and it is not what changed.

The expensive part of the 2021 rewrite was never typing. It was reading the old implementation to work out what a screen did in the edge cases, holding forty-odd screens' worth of behaviour in your head, and checking parity one control at a time. That is the part that compressed. The model does not get bored on screen thirty-one, and it does not skip the tedious parts of the Machine Learning page because the Dashboard was more fun.

What did not change is who is responsible. I reviewed everything. I found the invented slot, the invented role, and the token that should not have been trusted. The ratio moved; the accountability did not. Thirty hours with a competent reviewer is not the same thing as thirty hours unattended, and I would not claim otherwise.

Three months to thirty hours, on the same application, by the same person. That is the number I would want to see from someone else before I believed any of this, so it is the number I am publishing.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

Everything Supabase Does Not Have, in One Video: An AI Agent Builds a Role-Secured CRM

Thomas Hansen — Fri, 24 Jul 2026 13:05:35 +0000

Supabase is a good product. I have written about it approvingly, I have shown how to run AI agents on top of an existing Supabase database, and none of that changes today.

But there is a list of things Supabase does not have. Not "does worse" — does not have. And instead of writing that list as a feature matrix, I recorded a video where every item on it gets used, in one conversation, by an AI agent building a complete CRM from a single prompt.

The prompt was one paragraph: create an app named crm6 — a database with three tables, a CRUD web API, the ability to send emails to contacts, and a modern frontend, with the whole API restricted to users in the "guest" role. The agent — Claude, connected over Magic's MCP server — did the rest. This article walks through what it built, and points out, at each step, the capability it leaned on that Supabase does not ship.

What got built

An SQLite database with three tables — contacts, deals, and activities — with foreign keys, defaults, and seed data.
Sixteen HTTP endpoints: full GET/POST/PUT/DELETE plus record counts for every table, and a send-email endpoint — every one of them restricted to the "guest" role.
Email dispatch that looks up a contact by id and sends through the platform's SMTP integration.
A designed frontend — JWT login against Magic's built-in auth, a KPI dashboard with a pipeline chart, searchable contacts with an email composer, a drag-and-drop deals kanban, and an activities list.

Total hand-written backend code: zero lines. The CRUD layer was produced by the crudifier — twelve declarative calls, 722 lines of generated Hyperlambda, each call returning in well under a second. The send-email endpoint was generated from a plain-English prompt in 7.6 measured seconds. The only thing authored line by line was the frontend, and the agent wrote that too.

Watch the build

Now the list.

1. A backend that generates itself

Supabase gives you PostgREST: a generic REST reflection of your schema. That is genuinely useful, and it is also where it ends. The moment you need an endpoint that is not a table projection — "look up this contact's email address and send them a message, and throw if the contact does not exist" — you are writing an edge function by hand, in TypeScript, with your own error handling, and deploying it yourself.

On Magic the agent described that endpoint in one English sentence, and the Hyperlambda Generator produced it, saved it, and put it on the wire — role-gated like everything else — in 7.6 seconds. The backend is not a reflection of the schema. It is generated, customizable code, produced from intent.

2. Access control the agent cannot code its way out of

This is the structural one, and the reason the video is possible at all.

Supabase's security model is row-level security: SQL policies you write per table, per app. When an AI agent generates your application code, every generated query and every generated function has to correctly respect those policies — and the service-role key that bypasses them is sitting right there in the environment. The security boundary lives inside generated code, which means every generation is a fresh chance to get it wrong.

Magic enforces access at execution time, in the runtime. Every endpoint in this build declares that it requires the "guest" role, and the check runs before any endpoint logic — the agent's generated code never gets the option of forgetting it. After the build, anonymous requests against the CRUD layer and the email endpoint were fired as verification: 401, access denied, every time.

That is why you can hand an agent production credentials on this platform and watch it work. The platform, not the prompt, decides what those credentials can do. Supabase has nothing equivalent — not because their engineers are not capable, but because their architecture places authorization inside the application, and the application is now written by a probabilistic author.

3. A native MCP server

Everything in the video happens over one MCP connection. Creating the database, generating endpoints, uploading files, verifying the result — the agent operates the platform through the same tool surface you are using when you talk to your own Magic cloudlet from Claude.

Supabase has MCP as an add-on for development workflows. Magic's MCP server is the platform: every capability, scoped to the authenticated user's roles, with the agent able to generate new tools for itself when the existing ones do not fit. There is no "integration" step in the video because there is nothing to integrate.

4. Email as a platform primitive

The CRM sends email to contacts. On Supabase that feature means an edge function, a third-party mail API, an API key to manage, and retry logic you own forever. On Magic, SMTP is configured once at platform level, and the generated endpoint simply sends — the agent never saw a mail-provider credential, because there is none in the application.

5. A web server

The frontend in the video is served by the same system that serves the API. The agent wrote three files — HTML, CSS, JavaScript — into the platform's file system, and they were live at their URL the moment they were written. No Vercel, no Netlify, no storage-bucket-pretending-to-be-a-website, no CORS configuration between your frontend host and your backend host, because there is only one host.

Supabase Storage holds files. It is not a web root, and Supabase does not want to be your web server. Magic is one deployable unit that is your database, your API, your auth, your mail, and your frontend host — which is precisely what lets one agent in one conversation ship the whole thing.

6. The boring ones that add up

JWT auth with ticket rotation built in — the frontend logs in against the platform's auth endpoint and refreshes its ticket on a ten-minute window. No auth library was installed anywhere in this build.
Task scheduling, logging, and a server-side file system — not used heavily in the video, but they are the reason the agent never had to leave the platform for anything.
MIT license, one container, nothing gated — the entire stack in the video is the open-source product. There is no hosted-only feature making the demo prettier than your deployment.

What Supabase has that Magic does not

Fairness cuts both ways, and this list is real: realtime subscriptions over Postgres replication, the depth of the Postgres extension ecosystem, client SDKs for every framework under the sun, and a community large enough that every question you will ever have is already answered somewhere. If your product is built around live-updating Postgres data and your team's velocity comes from that ecosystem, Supabase remains the right call — I said so in the comparison article, and it still holds.

But none of those close the gap the video demonstrates. They make Supabase a better database platform. They do not make it a system an AI agent can safely operate end to end.

The point

The interesting question in 2026 is no longer "which backend has the better dashboard." It is: when the next developer on your team is an agent with a prompt, what can it actually do — and what stops it from doing what it should not?

In this build the answer was: everything, and the runtime. A database, sixteen role-secured endpoints, email dispatch, and a designed, working frontend, from one paragraph of intent — with every operation bounded by execution-time RBAC the agent could not generate its way around. That combination — generation, enforcement, MCP, mail, and hosting in one self-hosted, MIT-licensed unit — is the system that has everything Supabase does not.

Magic is open source at github.com/polterguy/magic, documentation at docs.ainiro.io, and hosted cloudlets at ainiro.io if you would rather not run it yourself.

This article was originally published on hyperlambda.dev.

78% of Enterprise AI Teams Now Run MCP Agents in Production — Here's Why Most of Them Are Doing It Wrong

Thomas Hansen — Thu, 23 Jul 2026 10:27:11 +0000

Seventy-eight percent of enterprise AI teams now run MCP-backed agents in production, and 28% of the Fortune 500 operate their own MCP servers.

The ecosystem has passed 10,000 servers, with SDK downloads running at roughly 97 million per month.

Less than two years after Anthropic open-sourced the protocol, MCP is no longer the interesting experiment. It is the default way AI agents reach company data.

That is the good news.

The bad news is that adoption happened faster than security maturity. Most of those production deployments were stood up in the demo era — a shared API key in a config file, every tool exposed to every caller — and never hardened afterwards.

They work. They also hand an autonomous agent the keys to company data with less access control than you would accept for a summer intern.

From experiment to infrastructure

The timeline is worth appreciating, because it explains the problem.

MCP went from novelty to infrastructure in record time. Every major vendor now ships servers — Microsoft alone offers a catalog of 60+ MCP servers across Copilot, Copilot Studio, and Azure AI Foundry. And in five days, on July 28th, the largest specification revision since MCP launched becomes the official spec, starting a 12-month deprecation clock for older protocol versions.

A protocol with a formal deprecation policy is not an experiment anymore. It is plumbing.

And here is the thing about plumbing: experiments don't get attacked. Infrastructure does.

When 28% of the Fortune 500 runs something, that something becomes a target. The security posture that was fine for a weekend demo — because nothing valuable was behind it — is now sitting in front of CRMs, ERPs, financial data, and customer records.

The three ways teams are doing it wrong

I have looked at a lot of MCP deployments over the last year, and the failures cluster into three patterns.

1. Over-broad tool exposure

The most common mistake is the simplest one: the server hands every connected agent every tool it has.

Read the database? Sure. Drop the database? Also sure. Same catalog, same caller, no distinction.

This violates the oldest rule in security — least privilege — and it does so at the worst possible layer, because the caller is a language model. Every serious treatment of MCP security published this year lands on the same conclusion: the tool catalog an agent sees must be scoped to what that agent's user is allowed to do, not to what the server is capable of.

If the agent can enumerate a destructive tool, some prompt, someday, will convince it to call that tool.

2. Bolted-on or absent authentication

The second failure is authentication that isn't really authentication.

A long-lived API key pasted into a JSON config is not identity. It is a password that never rotates, shared by everyone who copies the config, tied to no user, and invisible to your identity provider.

The protocol itself has moved past this. The MCP team just promoted its Enterprise-Managed Authorization extension to stable status, which routes MCP server access through the organization's identity provider — with support already shipped by Anthropic across Claude, Claude Code, and Cowork, by Visual Studio Code, and server-side by Asana, Atlassian, Canva, Figma, Linear, and Supabase.

When the protocol's own answer to "who is calling?" is your IdP, a shared bearer secret in a dotfile is no longer a pragmatic shortcut. It is technical debt with a blast radius.

3. Trusting the conversation

The third failure is the subtle one, and it is the one that makes MCP security genuinely different from API security.

An agent is a confused deputy by construction. It reads tool results, web pages, emails, documents — and every one of those inputs is a potential instruction channel. Prompt injection through tool output is not a theoretical attack; it is the standard attack.

Which means one thing, architecturally: you cannot firewall a conversation. No system prompt, no guardrail phrasing, no "please only use tools responsibly" preamble will hold. If the security check lives in the prompt, the security check is a suggestion.

The permission decision has to live on the server, at the endpoint, enforced on every call regardless of what the model believes it is doing. I have written before that agentic AI without permission boundaries is just malware with UX — MCP at enterprise scale is exactly where that stops being a slogan and starts being an incident report.

What doing it right looks like

The fix is not exotic. It is three principles, each one mapping to a failure above.

Identity, not shared secrets. Every MCP session belongs to a real user, authenticated against real identity infrastructure, with a token that expires. Per-user, revocable, auditable.

Role-gated tool catalogs. The tools/list an agent receives is filtered by the caller's roles before the agent ever sees it. The agent cannot be talked into calling a tool it cannot enumerate.

Server-side enforcement as the last line. Even if the catalog leaks, even if the model hallucinates a tool name, the endpoint itself checks authorization on every invocation. The prompt proposes; the server disposes.

This is how Magic Cloud's MCP server is built, and it is worth describing not as a product pitch but as a worked example of the pattern — because Magic did not add security to MCP. The MCP layer inherits it.

Every MCP tool in Magic is an HTTP endpoint with its own authorization requirement. The access token is a real JWT tied to a real Magic user with real roles — the same auth system that protects the API protects the MCP surface, because they are the same surface. When an agent connects, the tool list it receives is the list of endpoints its user's roles permit, nothing more. And when it invokes a tool, the role check runs server-side, before any endpoint logic, on every single call.

There is no separate "MCP security model" to configure, drift, or forget. If a user cannot call an endpoint over HTTP, their agent cannot call it over MCP. One contract, enforced once, in one place.

That is what held up when a frontier coding agent spent a session actively trying to break it — and it is the same boundary that makes it safe to let an agent build an entire role-secured CRM in one conversation: the platform, not the prompt, decides what the agent can touch.

The window is closing

Here is why this matters now rather than eventually.

The July 28th spec release starts a 12-month deprecation clock. Every team running MCP in production will touch their stack in the next year whether they want to or not — to move off deprecated protocol versions if nothing else.

That migration is the natural moment to fix what the demo era left behind. Swap the shared key for identity-backed tokens. Scope the tool catalog by role. Push the permission check down to the server where it belongs. Doing it as part of a migration you already have to do is cheap. Doing it after an agent with a wide-open catalog gets injected by a poisoned tool result is not.

Being in the 78% is no longer the differentiator. Everyone is in the 78%.

The differentiator is being in the minority that can answer, precisely and per-user, the only question that matters once agents are in production:

What exactly can this agent do, and who said so?

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

Originally published at hyperlambda.dev.

From Zero to Production Backend with HTTPS in One Copy-Paste: Magic Cloud on DigitalOcean

Thomas Hansen — Tue, 21 Jul 2026 07:21:28 +0000

Modern deployment orthodoxy is very clear about what you need to run a backend in production: a Kubernetes cluster, a CI/CD pipeline, a "platform team", an observability stack, and a cloud bill with a comma in it. Preferably also a DevOps engineer to babysit all of the above, because none of it babysits itself.

Here's what you actually need: one $12 droplet, and one copy-paste.

Everything below deploys a complete production backend - API, admin UI, database, and automatic HTTPS - and the only "pipeline" involved is Ctrl+C, Ctrl+V.

The deployment is a text file. The text file is the tutorial.

What you're actually getting

Before the steps, let's be precise about what comes out the other end, because "simple" usually means "toy" and this isn't one.

One droplet, running one Docker container. The container holds the Magic Cloud backend - an ASP.NET Core API on an internal port, never publicly exposed - which also serves its own compiled Angular admin UI. No nginx for the frontend, no separate frontend service, no second container to keep in sync. In front of it sits Caddy, which obtains and renews free Let's Encrypt certificates for your domain automatically. An internal SQLite database is created on first boot, and later you can connect MySQL, PostgreSQL, or SQL Server through the UI.

Your data lives in four named Docker volumes - databases and uploads, config (including your JWT secret), installed modules, and your own files. These survive upgrades, reboots, and container rebuilds. This is the part enterprise vendors charge you a retainer to explain, and here it's just... four volumes.

This walkthrough follows the official DigitalOcean deployment doc in the repository - that's the canonical reference if you want every detail.

Step 1: The copy-paste

Create a droplet. Pick Ubuntu 24.04 and a plan with at least 2 GB RAM - 4 GB is the comfortable choice. Why does a backend this lean want that much memory? It doesn't. The Angular production build during first boot does, because frontend tooling in 2026 remains a gas that expands to fill all available RAM. The deployment script even creates a 4 GB swap file specifically so cheap droplets don't get OOM-killed mid-build. That's the level of "it just works" we're going for: the script assumes the worst and handles it.

Now the actual deployment:

Open .do/cloud-init.yaml from the repository
Edit one line - DOMAIN= - to the domain you'll be using
Copy the entire file, and paste it into Advanced Options / User Data on the droplet creation form
Create the droplet
Point your domain's DNS A record at the droplet's IP

That's it. That's the deployment. The cloud-init file installs Docker, clones the repository, builds the all-in-one image, and starts it behind Caddy with all four volumes wired up. You configured a production environment by editing one line in a text file, which is one line more configuration than I'd prefer, but I can live with it.

Step 2: Wait, and why waiting is fine

First boot takes 15 to 20 minutes, and your domain answers only when it's done. Most of that time is the Angular production build, which is slow by nature and unbothered by your schedule.

I'm giving this its own section because every tutorial skips it, and every reader hits it. During those minutes your domain refuses connections. If you're behind Cloudflare, you'll see a 521. Your reflex will be that something broke. Nothing broke - this is the expected state, not a failure. Caddy retries certificate issuance on its own, so HTTPS comes up by itself within minutes of DNS propagating.

If you can't stand not watching, SSH in and follow along:

tail -f /var/log/cloud-init-output.log

When the log goes quiet and the build is done, your domain serves the login screen. Over HTTPS. With a real certificate you never requested, configured, or renewed.

Step 3: Log in and rotate the keys

Browse to https://your-domain/ and log in with root / root. The frontend loads the setup wizard automatically, which walks you through changing your root password, optionally adding your OpenAI API key for the AI features, and optionally configuring additional database connections.

The detail worth pausing on: when you change the password, the system also replaces the default JWT secret with a freshly generated one and persists it to the config volume. Most platforms put "rotate your secrets" in a hardening checklist you'll read never. This one does it as a side effect of the one thing every human does anyway - changing the default password. Security that happens by default beats security that happens by discipline, every single time.

Because config and data are persistent volumes, your new password, your JWT secret, and your database all survive reboots and upgrades.

Day 2: Upgrading later

"Sure, deploying is easy - but what about maintaining it?" - the standard objection to every simple setup. Here's the entire maintenance story. SSH in and run:

cd /opt/magic
git pull
docker build -f .do/Dockerfile.backend -t magic .
docker rm -f magic
docker run -d --name magic --restart unless-stopped --network magicnet \
  -v magic_files_etc:/magic/files/etc \
  -v magic_files_data:/magic/files/data \
  -v magic_files_config:/magic/files/config \
  -v magic_files_modules:/magic/files/modules \
  magic

Caddy keeps running untouched, certificates and all. And the content rules on container start are deliberately boring: the frontend folder is overwritten from the new image - overwrite only, your own web files are never deleted. Platform folders come fresh with every upgrade. Everything else - data, config, modules, your files - is copied from the image only if missing, and never touched if it exists. Your data outlives every container you'll ever run.

The numbers

Time for the section you knew was coming.

The one-copy-paste path: $12/month for 1 vCPU / 2 GB, or ~$24/month for the comfortable 4 GB plan. Add 20% if you want droplet backups. Worst realistic case: under $30/month, all-in.

The orthodox path: a minimal managed Kubernetes setup starts around $150-300/month before you've deployed anything, and that's the cheap part - the expensive part is the human who understands it. Even a fraction of one DevOps engineer's time costs more per month than a decade of this droplet.

And the AI part - the Hyperlambda Generator, which writes backend endpoints from plain English - currently costs nothing. The repository lists future pricing at $49 per 1,000 requests, but today there's no payment wall at all. So the complete stack, AI code generation included, runs at the price of three coffees a month.

The honest version

One droplet is one droplet. There's no high availability, no autoscaling, and if the datacenter region has a genuinely bad day, so does your backend until you restore from backup. If you're running payment infrastructure for millions of users, this is not your architecture, and I won't pretend otherwise.

But here's the uncomfortable truth for the orthodoxy: the overwhelming majority of business backends fit comfortably inside one droplet of this size, and always will. Droplet backups exist. Restores work. And you can graduate to the complicated architecture when you have the problem it solves - not preemptively, because a conference talk scared you into cosplaying Google.

Until that day, your entire DevOps department is a text file with one edited line.

Get started with Magic Cloud, grab the code on GitHub, or talk to us if you'd rather we deploy it with you.

Originally published at hyperlambda.dev.

Your 20-Year-Old SQL Server Database is a Better AI Agent Than Anything OpenAI Sells You

Thomas Hansen — Sat, 18 Jul 2026 08:25:37 +0000

Your ERP runs on SQL Server. Your line-of-business app runs on MySQL. Your data is clean, your uptime is measured in years, and your DBA could restore the whole thing blindfolded. And every AI vendor on earth is telling you the first step towards "AI transformation" is migrating away from all of it.

That's not a technical requirement. That's a sales tactic.

They don't want your database in the AI conversation, because your database doesn't pay them rent

The Migration Industrial Complex

Watch any AI agent demo from the last two years. It runs on fresh Postgres, in somebody else's cloud, on a schema that was created 45 seconds before the recording started. Nobody demos on the SQL Server 2008 instance that's been running your order flow since before the iPhone existed - because their tooling can't, and admitting that would ruin the pitch.

So instead they've built an entire industry around convincing you that your database is the problem. The consultants call it "data modernization". The SaaS vendors call it "onboarding", which is a cute word for "upload your customer records to our servers and pray". The system integrators call it a "6 to 18 month transformation project", and they invoice accordingly.

A typical migration project for a real production database runs anywhere from $250,000 to $1.2 million, takes 9 to 18 months, and carries genuine risk of breaking the business it was supposed to "transform". And here's the punchline: at the end of it, you still don't have an AI agent. You have the same data in a different database, and a fresh invoice.

Meanwhile, the actual thing you wanted - an AI agent that can answer questions about your customers, your orders, and your tickets - never required moving anything at all.

Prompts are not permissions

Now, the other camp will tell you migration is unnecessary because you can "just let the LLM write SQL against production". These people are even more dangerous than the consultants, because at least the consultants only steal your money.

Handing a language model a raw database connection and a system prompt saying "please only read, don't drop anything" is not security. It's a horoscope. Prompts are suggestions. The model can be confused, jailbroken, or simply wrong - and your production database will happily execute whatever it produces, because your production database was never asked for its opinion.

The correct answer is the one your database has been screaming at you since the 90s.

RBAC, not prompts. Permissions, not vibes.

With Magic Cloud, the architecture is boring on purpose. You create a scoped database user - ordinary DBA hygiene, enforced by SQL Server or MySQL itself. Magic connects as one more client, reads your schema, and generates secured CRUD endpoints for exactly the tables you select, each one wired with authentication and role-based access control. Its native MCP server then exposes those endpoints as tools to Claude, or any MCP-capable agent.

The agent never sees a connection string. It never writes SQL. It gets a toolbox, filtered by the roles it authenticated with, and an endpoint outside its roles doesn't refuse politely - it does not execute. Underneath even that sits the scoped database user, enforced by the one component in your stack you already trust completely.

Three layers of enforcement, zero layers of prompt engineering. If you want the full step-by-step - scoped user, connection, CRUD generation, MCP - I wrote a detailed practical guide over at hyperlambda.dev. The whole path is an afternoon, and your database remains completely unchanged throughout.

The Hyperlambda Generator, or why hallucinations bounce off

Generated CRUD covers 80% of what an agent needs. For the rest - the weird reporting join, the custom workflow, the endpoint nobody predicted - you use the Hyperlambda Generator. Describe the endpoint in plain English, and a fine-tuned LLM writes the Hyperlambda for you.

"But LLMs hallucinate!" Yes, they do. Which is exactly why we didn't build this the way everybody else builds it.

First, the model isn't guessing at some general-purpose language with a billion Stack Overflow answers of varying quality. Hyperlambda is a small, constrained runtime, and the generator was fine-tuned specifically for it. Smaller surface, radically fewer ways to be wrong.

Second - and this is the part the "agentic coding" crowd hasn't figured out yet - the platform is self-describing at runtime. Every capability the runtime has can be enumerated and queried as ground truth on the actual server the code will run on. The generator doesn't recall what the platform can do from training data that might be stale; the platform tells it. Hallucinated capabilities become structurally impossible to ship, because a capability that doesn't exist has nowhere to execute.

Third, generated code runs inside the whitelisting system. The runtime maintains an explicit list of what code in a given context is allowed to touch, enforced at the interpreter level. So even in the worst case - a confused generation, a hostile prompt, whatever - the code physically cannot reach beyond its whitelist. It can't hand the guest role your PII, because the interpreter refuses to execute the attempt.

Compare that to a coding agent free-styling Python against your production connection string, and tell me again which database is "legacy".

The numbers

Let's put the two paths side by side, for the identical outcome - an AI agent operating on your existing business data:

The migration path: $250K to $1.2M, 9 to 18 months, a rewritten integration landscape, retrained staff, and a risk profile that keeps your CTO awake. And the agent work hasn't even started yet.

The Magic path: $0 to start. Magic is open source - clone it, Docker it, run it forever, including fully on-premise behind the same firewall your auditors already approved. One container next to your database, one afternoon of work, and the data never leaves your network. No per-seat tax, no per-row upload pricing, no rent.

That's not a 10% optimization. That's an entire budget line evaporating, plus a year of calendar time you get back.

The honest version

I'm not going to pretend this makes every database problem disappear. If your schema is genuinely rotten, an AI agent on top of it will give you fast, well-secured answers derived from rotten data - garbage in, garbage out, now with better latency. And start read-only. A read-only agent over real business data is already massively useful, and it turns "what if the agent writes something wrong" into a non-question for day one. Grant writes table by table, when you're ready, as deliberate decisions - the same way your DBA has granted everything else for twenty years.

Which is really the whole point. The security model that protects your business from an over-eager AI agent isn't some new invention you need to learn. It's the one sitting in your database already, ignored by every vendor whose business model depends on you abandoning it.

Your "legacy" database isn't the thing holding your AI strategy back. It's the only part of your AI strategy that was finished before you started.

Get started with Magic Cloud, or talk to us if you'd rather we show you on your own stack.

Create an AI Agent From Your SQL Server or MySQL Database, Step by Step

Thomas Hansen — Fri, 17 Jul 2026 09:56:29 +0000

Keep the database. Add the agent.

If your data lives in SQL Server or MySQL, you have mostly been left out of the AI agent conversation. The demos run on fresh Postgres in someone's cloud. The tooling assumes a greenfield stack. And the databases that actually run your business — the ERP on SQL Server, the line-of-business MySQL nobody is allowed to touch — get treated as a problem to migrate away from rather than an asset to build on.

This article is the practical counter to that. By the end of it, you will have a working AI agent that can read and operate on your existing SQL Server or MySQL database — through secured, generated endpoints, with the database itself completely unchanged.

No migration. No schema changes. Nothing installed inside the database. The whole path is: scope a database user, connect Magic, generate endpoints, connect the agent over MCP. Each step takes minutes.

The architecture in one paragraph

Magic connects to your existing database as one more client — the same way any application would. On top of that connection, its CRUD generator reads the schema and generates HTTP endpoints per table, each with authentication and role-based access control wired in. Magic's native MCP server then exposes those endpoints as tools, and any MCP-capable agent — Claude, Codex, Qoder — operates on your data through them. The agent never touches the database directly. Between it and your tables sit three enforced layers: the scoped database user, the runtime's role checks on every endpoint, and the whitelisting system underneath. All of it runs wherever you need it to — including fully on-premise, on the same network segment as the database.

Now the steps.

Step 1. Create a scoped database user for Magic

Do this first, not eventually. It is the layer everything else stands on, and it is enforced by the database engine itself — the one component in this whole stack you already trust completely.

On SQL Server, create a login and a database user for Magic, and grant it exactly the access the agent layer should have. If the agent should only work with three tables, grant SELECT on three tables and nothing else. Add INSERT or UPDATE per table when you are ready for writes.

On MySQL, same idea: create a dedicated user and GRANT it the specific privileges on the specific tables.

One practical caveat before you lock this down completely: the endpoint generation in step three depends on reading the schema — tables, columns, types, and keys, the metadata your database exposes through its information schema views. A user scoped down to SELECT on three tables may not be able to see enough of that metadata for the generator to do its job. The pragmatic answer is a temporary, less restricted user with metadata read access, used only while generating the endpoints — then switch Magic's connection to the tightly scoped user for everything that runs afterwards. Generation is a one-time act you perform deliberately; the scoped user is what the agent lives with.

This is ordinary DBA hygiene, and that is precisely the point. You are not learning a new security model to give an agent access to your data — you are using the one your database has had for decades. If Magic's credentials can only read three tables, nothing generated on top of them can do more than that, no matter how confused any layer above ever gets.

Starting read-only is the conservative default, and I recommend it. A read-only agent over real business data is already genuinely useful — and it turns the scariest question in this whole exercise ("what if the agent writes something wrong?") into a non-question for day one.

Step 2. Connect the database to Magic

Magic deploys as one Docker container for the backend and one for the dashboard. For an on-premise database, run them inside the same network perimeter — the connection never has to cross your firewall.

Add your database as a connection in Magic, using the credentials from step one. Magic speaks to SQL Server and MySQL through the standard .NET data providers, so the connection string is the same shape your existing applications already use.

That is the entire integration. Magic is now a client of your database — nothing more. Your existing applications, integrations, and reports continue exactly as before, because nothing about the database changed.

Step 3. Generate CRUD endpoints for the tables that matter

Point Magic's CRUD generator at the connected database and it reads the schema — tables, columns, types, keys — and generates Hyperlambda HTTP endpoints for the tables you select: read, create, update, delete, and count, each as its own endpoint, each with authentication and role-based access control already in place.

Two decisions are worth actual thought here, and they are both decisions a DBA is well equipped to make.

Which tables become capabilities. Not the whole schema. The agent needs the tables that answer real questions and support real workflows — customers, orders, tickets. Internal bookkeeping tables can stay unexposed.

Which operations each table gets. If you scoped the database user read-only in step one, generate read and count endpoints and the two layers agree with each other. When you later grant writes at the database level, generate the matching endpoints then.

If your database carries queries that do not fit CRUD — the reporting join across six tables, the aggregate someone runs every Monday — wrap them with the SQL endpoint generator: you write the SQL, define its arguments, and it becomes one more secured endpoint. Legacy databases have earned their weird queries; this is how they become tools instead of tribal knowledge.

Then test the endpoints the ordinary way, over HTTP, before any AI enters the picture. List records. Fetch one. If something about the exposure feels wrong — a field that should not be visible, a table that should not be writable — this is where the correction costs nothing.

Step 4. Connect your agent over MCP

Magic includes a native MCP server. Connect Claude — or any MCP-capable agent — to it, authenticating as a Magic user with specific roles.

This step is where the earlier decisions pay off. The agent does not receive a database connection, and it does not receive a SQL surface. It receives tools: the endpoints you generated, filtered by the roles of the user it authenticated as. An endpoint outside its roles does not execute. Not "is instructed not to" — does not.

That distinction is the difference between this architecture and the "just let the model write SQL against production" demos. Prompts are not permissions. A runtime that refuses to execute is a permission. I have written about this at length in the runtime whitelisting article, so here I will just note what it means practically: the worst a confused agent produces on this stack is a failed call, and underneath even that failure sits the scoped database user from step one, enforced by SQL Server or MySQL itself.

Step 5. Give it real work

The agent is now connected to your actual business data, so test it with actual business tasks — not trivia.

Ask it to look up a customer and summarise their order history. Ask which tickets are open past their deadline. Ask it to cross-reference two tables the way a colleague would ask a DBA. If you exposed writes, have it create a record, then verify the row in the database yourself.

Two things tend to happen in this phase. First, the agent is more useful than expected, because it is grounded in real data rather than improvising. Second, you immediately get ideas for the two or three custom SQL endpoints that would make it dramatically better — which is exactly the right feedback loop. Add them, and the agent's toolbox grows without its permissions growing.

What you have at the end

A twenty-year-old database, unchanged, now has: a secured HTTP API over the tables that matter, an AI agent that operates through that API inside role boundaries, and a clean growth path — more tables, more custom endpoints, writes when you are ready — where every expansion is a deliberate grant rather than an accident.

And because every layer of this runs in containers you place yourself, the entire stack — database, API layer, MCP server — can live on-premise, behind the same firewall, in the same network segment the auditors already approved. The agent connects in; the data never leaves.

The pattern generalises past the first agent, too. The same endpoints serve embeddable chatbots, scheduled tasks that run against the data and send email, and — through the Hyperlambda Generator — agents that describe new endpoints in plain language and have them generated inside the same permission model. The first agent is rarely the last thing you build on this surface.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

FAQ

Does the AI agent get direct access to my SQL Server or MySQL database?

No, and that is the core of the design. The agent talks to Magic over MCP and only ever invokes generated endpoints, each gated by roles at execution time. The database only ever sees Magic's scoped credentials from step one.

Can I do this without allowing any writes?

Yes — and it is the recommended starting point. A read-only database user plus read-only generated endpoints gives you a useful question-answering agent over live business data with no write path at all.

Does my database need to be reachable from the internet?

No. Run Magic's containers inside the same network as the database. The database port never needs external exposure — the MCP surface is the only thing you choose to make reachable, and it sits behind authentication.

Do I have to write Hyperlambda?

No. The CRUD generator emits it, and the SQL endpoint generator wraps SQL you already know how to write. The generated code is readable and editable when you want to customise, but the path in this article involves authoring none of it by hand.

The first LLM on earth that cannot hallucinate

Thomas Hansen — Tue, 14 Jul 2026 14:02:22 +0000

Yes, the headline is bait. No, it's not a lie.

Every AI vendor on the planet claims their model "reduces hallucinations." Reduction is a percentage. Cannot is an architecture. This article is about the architecture.

What a hallucination actually is when a model writes code

When an LLM writes Python or JavaScript, an invented API call is syntactically perfect. pandas.read_excel_fast(), express.validateJWT(), a package that never existed — the model produces them with total confidence, and the language happily accepts them. The code compiles. It passes a glance-level review. It fails at the worst possible moment: at runtime, in production, against real data.

This is the dirty secret of free-form code generation: a general-purpose language has an infinite vocabulary. Any name the model dreams up is grammatically valid code, indistinguishable from the real thing until it runs.

The industry's answer? Review everything, trust nothing. Every generated line gets a human pass before production — which quietly hands back the time the AI was supposed to save you.

Step 1: Close the vocabulary

Our generator doesn't emit free-form source code. It emits Hyperlambda — a language where code is an execution tree, and every executable node is an invocation of a slot: a named capability registered in the runtime.

The crucial property: the set of slots is finite. There is a registry. A capability either exists in it or it doesn't. The model cannot invent a capability — it can only name one. And names are checkable.

In a free-form language, a hallucinated function is valid code. In a closed-vocabulary language, a hallucinated slot is a detectable lie.

Step 2: Statically prove every instruction exists

Detection is a slot called [hyperlambda.verify-slots]. You hand it a piece of Hyperlambda, and it walks every node in executable statement position — the root level, plus the body of every body-bearing slot it encounters, resolved from slot signature metadata rather than hardcoded names, to any nesting depth — and checks each invocation against the registry.

hyperlambda.verify-slots:@"strings.reverse:Hello world"

The model made strings.reverse up. The verdict:

hyperlambda.verify-slots:bool:false
   :strings.reverse

false, plus the exact names of everything that doesn't exist, as structured data. Not a stack trace three weeks later. Not an incident report. A named, mechanical, pre-execution verdict, delivered in milliseconds.

Step 3: The model never gets a vote

Now wire the two together. Our Hyperlambda generator runs inside a loop:

Generate — the model produces an execution tree from a natural-language prompt.
Prove — verify-slots walks every executable statement and checks it against the registry.
Reject and retry — if anything doesn't exist, the exact missing names go straight back into the generation context, and the model tries again.
Ship only on true — code leaves the loop only when the verdict is a mechanical, binary yes.

Nothing about this depends on the model behaving. The model can hallucinate all it wants inside the loop — what comes out of the loop provably invokes only capabilities that exist. Hallucinated code is structurally unable to ship.

You don't have to trust the model. The machine checks its homework.

If you'd rather watch than read, here's the whole thing in action:

The fine print, up front

Big claims deserve precise edges, so here's exactly where this one begins and ends.

Guaranteed: no invented capability ever executes. Every instruction in production logic provably exists on the runtime it runs on. This entire class of failure — the hallucinated API, the phantom package, the made-up function — is eliminated, not reduced.

Not claimed: proven-to-exist is not proven-to-be-wise. Whether logic should run is a separate question, and it gets a separate answer: a per-role whitelist enforced at the execution boundary itself, so even perfectly valid code can only touch the capabilities your RBAC policy explicitly names. And whether the logic is correct for your business is what tests are for — same as code written by humans, who, it should be said, also occasionally invoke functions that don't exist.

The point isn't that generated code becomes magically perfect. The point is that the trust boundary moves from the prompt to the runtime — from "hope the model behaved" to "the runtime refuses everything else."

Why I think this is the actual answer

The whole industry is trying to fix hallucination inside the model: better training, better prompts, better RAG. That's fighting probability with probability. A model is a sampler; you can shrink the error rate, but you can't sample your way to cannot.

A closed vocabulary plus a static proof gets you cannot — with boring, deterministic, thirty-year-old computer science. No new model required.

The runtime underneath all of this is Magic Cloud — MIT-licensed, open source, self-hostable. Audit the verifier yourself; it's a couple hundred lines of C# that walks a tree and asks a HashSet some questions. The best security arguments are the ones you can read.

And that's the whole trick, honestly. The first LLM on earth that cannot hallucinate isn't a smarter LLM.

It's a dumber runtime that refuses to be impressed.

Magic Cloud vs Supabase: what an MIT-licensed backend does differently

Thomas Hansen — Sat, 11 Jul 2026 19:41:42 +0000

I want to say this up front: Supabase is a good product. This is not a takedown. But I keep meeting developers who like Supabase's model and still can't use it — because of one of a handful of hard constraints that no amount of Supabase configuration removes.

I build Magic Cloud, an MIT-licensed, self-hosted backend platform. Below are the differences that actually matter — specifically the things Supabase users ask for and structurally can't get, and honestly, the places where Supabase remains the better pick.

The quick comparison

	Supabase	Magic Cloud
License	Open-core, some features hosted-only	MIT, everything included
Self-hosting	Community-supported compose stack	First-class, one backend + one dashboard container
Database	PostgreSQL (theirs)	SQLite default; connects to your existing MySQL, PostgreSQL, MSSQL
Server-side logic	Deno edge functions, separate deploy	Generated endpoints, live instantly, no build step
Access control	Postgres RLS, written per app	Execution-time RBAC enforced by the runtime
AI story	pgvector + client libraries	Native RAG, chatbots, MCP server, endpoint generator

Now the parts a table can't capture.

1. It connects to the database you already have

This is the difference that decides most evaluations, so it goes first.

Supabase is a managed Postgres. You don't connect Supabase to your database — you migrate your data into theirs. If your data lives in a fifteen-year-old SQL Server, or a MySQL instance three other systems depend on, that migration is somewhere between painful and impossible.

Magic points at any existing MySQL, PostgreSQL, SQL Server, or SQLite database and generates a complete, secured CRUD API on top of it. The data stays where it is. Nothing migrates. The CRUD generator reads your schema and emits one endpoint per operation per table, each with authentication and role checks already wired in.

For teams with legacy databases, this isn't a feature comparison — it's the whole decision.

2. Backend logic without a separate runtime

Supabase's answer to "I need server-side logic" is edge functions: Deno, a separate deploy artifact, its own toolchain, and cold starts. It works, but it's a second system bolted onto the first.

In Magic, an endpoint is a file on the server. Create the file, the endpoint is live. No build, no deploy pipeline, no cold start — after first execution the compiled AST is cached and subsequent calls execute in roughly 100–200 milliseconds.

The runtime language is Hyperlambda, and before that triggers an objection: you're not expected to write it. It's generated — by the CRUD generator, or by the Hyperlambda Generator, which compiles plain-English prompts into working endpoints. Think of it like the SQL your ORM emits. Readable, editable, rarely hand-authored.

A side effect worth more than it sounds: since every endpoint is a plain-text file, your entire backend is version-controllable with git, as-is. Supabase's server-side logic lives inside the database as RLS policies and triggers, and extracting it into reviewable migrations is its own discipline. Magic's answer is git add.

3. Sending email is a platform primitive

Small one, but it's a perennial forum question: "how do I send email from Supabase?" The answer is always the same — you can't, beyond auth emails; go sign up for Resend or SendGrid and write an edge function.

Magic has SMTP built in. Endpoints send mail, with MIME attachments, as a one-liner of generated code. Same story for task scheduling: where Supabase offers pg_cron (which runs SQL), Magic has persisted, schedulable tasks that execute arbitrary backend logic — the "every Monday, call this API and email the report" job that SQL-only cron can't express.

4. The AI layer is a platform, not a column type

Supabase's AI story is pgvector plus client libraries: here's a vector column, build your RAG pipeline yourself.

Magic ships the pipeline. Website crawling, vectorization, RAG-backed machine-learning types, an embeddable chatbot widget, and AI functions — configured from the dashboard, no glue code. If the goal is "a chatbot trained on our docs, on our infrastructure," that's a dashboard task, not a sprint.

5. The part I think matters most: agents can safely operate it

Both platforms now have MCP servers, so both let AI agents talk to the backend. The difference is what happens when agents build on it.

Supabase's security model is row-level security: SQL policies, written per application. When a human writes the app, RLS works well. When an AI agent generates the app, every generated endpoint and query has to correctly respect those policies — the security boundary lives inside the generated code, and every generation is a fresh chance to get it wrong. A service-role key where an anon key belonged. A query that sidesteps a policy. The model doesn't have to be malicious, just wrong once.

Magic inverts this. Hyperlambda executes as an AST, and every node must bind to a slot the runtime exposes. Permissions are enforced at execution time: endpoints declare which roles may invoke them, and the whitelisting system controls which slots code in a given context can bind to at all. If a capability isn't whitelisted, generated code cannot call it — not "is instructed not to," but structurally cannot. The worst a bad generation can do is fail.

That means an agent connected over MCP can generate new endpoints, create databases, and wire up logic — and everything it produces runs inside the same runtime-enforced boundaries as human-written code. Security is a property of the platform, implemented once in C#, instead of a property each generated app has to reimplement. I've written up the architecture in detail here.

In one reproducible session, an agent given a single natural-language prompt created a database, generated a public API, wired email notifications, deployed a chatbot widget and landing page, and verified every step over HTTP — and when the platform rejected a malformed widget, the agent read the built-in guides over MCP and fixed its own mistake. No human in the loop between prompt and working system.

6. Nothing is gated

Magic is MIT-licensed end to end. There's no enterprise edition, no hosted-only dashboard features, no open-core split where the self-hosted version quietly lacks SSO or log drains. The hosted cloudlets at AINIRO run the same code you can deploy yourself from the GitHub repo — because there's nothing to gate.

Self-hosting is the primary deployment model, not a community afterthought: one Docker container for the backend, one for the dashboard.

Where Supabase is still the right choice

Credibility requires this section, so here it is, unhedged.

You need Postgres specifically. Extensions, replication, a team fluent in it. Supabase's all-in bet on Postgres is a genuine strength; Magic treats databases as pluggable, which is more flexible but less deep on any single engine.

You rely on the ecosystem. Client SDKs for every framework, enormous community, a tutorial for everything. Magic's community is smaller. If your velocity comes from copy-pasting battle-tested Supabase snippets, weigh that honestly.

You want realtime and storage-with-CDN out of the box. Realtime subscriptions and storage buckets are Supabase strengths without a direct Magic equivalent.

You want a managed service and were never going to self-host. Supabase's hosted product is genuinely good. Most of this article's argument is about the self-hosted path.

Summing up

If your constraints include an existing database, real self-hosting, MIT licensing, or AI agents building and operating backend functionality, Magic Cloud solves problems Supabase structurally can't. If your constraints are Postgres depth and ecosystem gravity, stay with Supabase — sincerely.

The repo is at github.com/polterguy/magic, the docs at docs.ainiro.io, and a longer evaluation-focused comparison at hyperlambda.dev. Spin it up in Docker and point it at a database you already have — that first CRUD generation is the moment the difference clicks.

Save $171,032 Annually on your Company's Claude subscription!

Thomas Hansen — Fri, 10 Jul 2026 05:28:57 +0000

I used Magic Cloud to generate a simple CRUD API, with an SQLite database, two tables, allowing me to manage tasks and clients. Basically a micro "Jira" thing.

Then I asked it how much more tokens it would have used if it didn't have Magic, and its price estimate increased from ~$0.53 to ~$2.60, implying Magic saved me 82% of my tokens on one simple task. Notice, this was a 5 minute job ...

Then I asked it how much this would translate into for a company with 25 employees, where each employee actively uses Claude, and the company is heavily using agentic AI. Its answer ...

A company with 25 employees, would save $171,072 annually on average. That's a cost reduction of $570 per month, for every single employee you have.

In addition to this, comes 80% time savings, since Claude becomes 5x faster with Magic, new capabilities (Magic allows for direct deployment of solutions), etc, etc, etc.

Psst, Magic is Open Source, can be installed on your own infra in 10 minutes, and you can find at at GitHub (link in the first paragraph).