DEV Community: Thomas Hansen

Masturbation Is 100 Times More Dangerous Than AI

Thomas Hansen — Mon, 14 Sep 2026 13:01:38 +0000

This headline is intentionally provocative.

It is also based on a simple comparison between two uncertain figures.

The comparison

An old estimate suggested that between 250 and 1,000 people die each year in the United States from autoerotic asphyxia.

Autoerotic asphyxia means sexual activity involving strangulation or oxygen restriction. It is not ordinary masturbation.

Separately, a small number of suicides involving ChatGPT, Claude and other conversational AI systems have been publicly reported or alleged through lawsuits, family statements and investigations.

A reasonable working estimate for these publicly reported AI-associated suicides is approximately 2 to 10 cases.

Using midpoint figures:

500 autoerotic deaths ÷ 5 AI-associated suicides = 100

Therefore:

Masturbation is approximately 100 times more dangerous than AI.

The calculation is not a medical conclusion. It is a statistical punchline.

The limitations

The estimate of 250 to 1,000 autoerotic deaths per year is old and uncertain.

A recent systematic review identified 101 published autoerotic death cases across 44 years. This is not a complete national or global registry. It only counts cases documented in the forensic literature.

AI-associated deaths have similar classification problems.

A death may involve:

A chatbot conversation
Existing mental illness
Social isolation
Family conflict
Drug use
Financial or relationship problems
Other online communities
Several simultaneous causes

The presence of an AI conversation does not, by itself, establish causation.

There is currently no standard death-certificate category called “death caused by ChatGPT” or “death caused by Claude.”

Historical autoerotic-death estimate

Recent systematic review of autoerotic deaths

Database of reported AI-associated fatalities

Other unusual causes of death

The following figures are mostly from the United States.

Cause	Approximate figure
Bee, wasp and hornet stings	72 deaths per year
Cattle-related incidents	Approximately 20–22 deaths per year in older estimates
Lightning	Approximately 20 deaths per year
Furniture and television tip-overs	217 reported deaths from 2013 to July 2023
Vending machines	37 reported deaths from 1978 to 1995
Shark attacks	Usually 5–10 deaths worldwide per year
Falling coconuts	Unknown
Garden rakes	Unknown

Bee, wasp and hornet stings

The CDC recorded 788 deaths from hornet, wasp and bee stings between 2011 and 2021.

That equals an average of 72 deaths per year.

The annual figure ranged from 59 to 89. Eighty-four percent of the victims were male.

CDC data

Cattle

Cattle can kill people by trampling, kicking, crushing or striking them.

Older CDC agricultural estimates placed cattle-related deaths at approximately 20–22 per year in the United States.

The victims were mainly agricultural workers handling cattle in pens, chutes and loading areas.

CDC agricultural safety material

Lightning

Lightning kills approximately 20 people per year in the United States.

The rate has declined substantially over the last several decades because of improved warnings, public education, emergency care and changes in outdoor work.

CDC-hosted lightning mortality study

Furniture and televisions

Unsecured furniture, televisions and appliances can tip over onto people.

The Consumer Product Safety Commission reported 217 fatalities from January 2013 through July 2023. Of those victims, 155 were children.

The same report estimated approximately 17,800 emergency-department-treated injuries per year from these incidents.

CPSC tip-over report

Vending machines

The vending-machine statistic is often exaggerated.

The CPSC reported at least 37 deaths between 1978 and 1995 after people rocked or tilted vending machines.

That equals approximately two deaths per year during that period.

The machines fell onto the victims. They did not kill people by dispensing drinks incorrectly.

CPSC vending-machine warning

Falling coconuts

Falling coconuts can cause fatal head injuries.

However, the popular claim that coconuts kill 150 people per year is unsupported.

The figure appears to have developed from a medical report about coconut injuries in Papua New Guinea and was later repeated as a global estimate.

Actual coconut deaths occur, but the annual global number is unknown.

Original medical paper

Why the comparison is useful

The headline does not prove that AI is harmless.

A handful of reported suicides involving AI systems is still serious, particularly where a system may reinforce delusions, dependency or suicidal thinking.

The comparison demonstrates something else:

Humans have been dying from bizarre, mundane and poorly tracked activities for a very long time.

Masturbation-related deaths have an old and uncertain estimate.

AI-associated suicides have a new and uncertain estimate.

The exact ratio cannot be proven.

But “Masturbation Is 100 Times More Dangerous Than AI” remains a mathematically plausible thing you can quote me on in the public space, and easily be within 2 order of magnitudes correct ...

NOW let's talk about AI regulations ...

Your sitemap is an API — a whole website as one JSON document in 35 lines

Thomas Hansen — Mon, 14 Sep 2026 07:56:19 +0000

Every time I want to give a model a site rather than a page, I end up writing the same throwaway script. Fetch the sitemap. Loop the URLs. Pull the title, the H1, the meta description. Strip the HTML down to something readable. Glue it into one file. Delete the script. Write it again three weeks later.

So I made it a URL instead:

https://hyperlambda.dev/website-to-json — paste a domain, get one JSON document back. Free, no signup, no key.

What comes back

One array, one object per page:

[
  {
    "url": "https://example.com/pricing",
    "h1": "Pricing",
    "title": "Pricing | Example",
    "description": "One flat price, no surprises.",
    "markdown": "# Pricing\n\nOne flat price…"
  }
]

That shape is the whole point. markdown is the part you feed a model; url, h1, title and description are the parts you filter, dedupe and cite with. A folder of 50 Markdown files makes you rebuild that metadata yourself. One JSON document doesn't.

Useful immediately for: seeding a RAG index, diffing a site before and after a migration, auditing which pages are missing a meta description, or handing a competitor's docs to a model without writing a crawler.

The entire backend

Not a snippet of it. This is the deployed file:

.arguments
   url:string

// Throttling to maximum 5 requests per IP per minute!
execution.throttle.create:website-to-json
   limit:int:5
   window:int:60
   per:ip
execution.throttle:website-to-json

strings.concat
   get-value:x:@.arguments/*/url
   .:/sitemap.xml
http.get:x:-
xml2lambda:x:-/*/content
.result
for-each:x:@xml2lambda/*/urlset/*/url/*/loc/*/#text/[0,50]
   http.get:x:@.dp/#
   html2lambda:x:-/*/content
   .h1
   strings.join:x:@html2lambda/*/html/*/body/**/h1/[0,1]/**/#text
      .:" "
   set-value:x:@.h1
      strings.trim:x:@strings.join
   .title
   set-value:x:@.title
      get-value:x:@html2lambda/*/html/*/head/*/title/*/#text
   .description
   set-value:x:@.description
      get-value:x:"@html2lambda/*/html/*/head/*/meta/*/\\@name/=description/./*/\\@content"
   lambda2html:x:@html2lambda/*/html/*/body
   html2markdown:x:@lambda2html
      url:x:@.arguments/*/url
   unwrap:x:+/*/*/*
   add:x:@.result
      .
         .
            url:x:@.dp/#
            h1:x:@.h1
            title:x:@.title
            description:x:@.description
            markdown:x:@html2markdown
return-nodes:x:@.result/*

No dependencies, no build step, no project scaffold. That file is the deployment — saving it publishes the endpoint.

The parts worth stealing

This is Hyperlambda, where code is a tree rather than text, and the interesting bits are the expressions that walk it.

The sitemap is parsed, not regexed. xml2lambda turns the XML into nodes, and then the loop selects every URL in one expression:

for-each:x:@xml2lambda/*/urlset/*/url/*/loc/*/#text/[0,50]

Read it right to left: every #text under every loc under every url in the urlset — then [0,50] slices the first fifty. The page limit isn't an if with a counter; it's part of the address of the data.

Attribute matching without a DOM library. Pulling <meta name="description" content="…"> is one expression:

@html2lambda/*/html/*/head/*/meta/*/\@name/=description/./*/\@content

Find the @name attribute whose value equals description, step back up to its element with ., then take that element's @content. Attributes are \@-prefixed nodes, so they're addressable the same way elements are.

H1 text is joined, not assumed. An <h1> containing a <span> and a stray <br> has several text nodes. **/#text collects all of them under the first H1 and strings.join puts them back together with a space — so <h1>Build <span>fast</span></h1> yields Build fast, not Build.

Relative links survive. The body is serialized back to HTML and converted with the original domain passed in:

html2markdown:x:@lambda2html
   url:x:@.arguments/*/url

Without that, every /pricing in the output would be a dead relative link the moment the JSON left the site it came from.

What it will not do

Worth stating plainly, because a crawler that pretends otherwise wastes your afternoon:

It needs a sitemap. The URL you pass gets /sitemap.xml appended, so pass the origin with no trailing slash (https://example.com). No sitemap, no output. Sites that keep a sitemap index rather than a flat urlset won't enumerate either.
It does not run JavaScript. Server-rendered HTML only. A client-rendered app returns its shell, exactly like curl would.
Fifty pages, hard. Fine for a docs section or a marketing site; not a crawler for your 40,000-page store.
Five requests per minute per IP. It's a free shared endpoint doing 50 HTTP fetches per call. Hammer it and you'll just get throttled — the source is above, run your own.

It also costs the target site 50 requests, so point it at your own property or something that welcomes it.

The part I actually find interesting

The file above was written from a plain-English description by a code generator, and every function in it was verified against the functions that actually exist on the server before it was saved. Not "the model probably got the API right" — checked, then deployed, with no restart.

That inverts the usual trade-off with generated backend code. The risk isn't that the model writes ugly code, it's that it writes code that references something imaginary and fails at 3am. If the runtime refuses to save anything that invokes a function it doesn't have, the failure happens at generation time instead.

Same property makes it an agent tool rather than a web page: on this stack every HTTP endpoint is also an MCP tool, role-filtered, so an agent can call website-to-json and get the same array without a browser in the loop.

Try it

The tool: https://hyperlambda.dev/website-to-json
More free ones — page to JSON, dead link checker, link preview checker, llms.txt generator: https://hyperlambda.dev/tools
Run the whole platform yourself, MIT-licensed:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

If you build something with the output, I'd like to hear what you pointed it at.

I built 9 free web tools and printed the entire backend on every page. What should number 10 be?

Thomas Hansen — Sun, 13 Sep 2026 05:47:20 +0000

Over the last couple of weeks I've built nine small web tools. No signup, no API key, no "start your free trial". You paste a URL, you get a result.

There's a catch, and it's the interesting part: every tool prints the complete source code of its own backend, right there on the page. Not a snippet. Not pseudocode. The actual file that ran when you clicked the button.

I did that because I wanted the tools to be an argument, not a brochure. If I claim a backend is small, you shouldn't have to take my word for it.

Now I've run out of good ideas for number ten, which is why I'm writing this. Skip to the bottom if you just want to tell me what to build.

The nine

URL to Markdown — paste a link, get clean Markdown for an LLM prompt, plus the token count before and after so you can see what the HTML was costing you.
Page to JSON — one page as structured JSON: title, H1, description, text, every link with its anchor text, every image with its alt. Missing anchor and alt text get flagged rather than silently returned as empty strings.
Website to JSON — same idea, but walks the sitemap instead of one page.
URL to YAML — a page's metadata as YAML.
llms.txt generator — builds an llms.txt from your sitemap.
AI Crawler Check — which AI crawlers your robots.txt actually allows or blocks, citing the exact rule that decided each one. Also checks whether your content survives without JavaScript, because most AI crawlers don't render it.
Link Preview Checker — what your Open Graph and Twitter cards really look like to a scraper.
Website Image Gallery — every image across your site with its alt text, so you can find the ones missing it.
Dead Link Checker — crawls your sitemap and reports links that don't answer 200.

All nine are here: hyperlambda.dev/tools

What "the whole backend" actually looks like

Here's URL to Markdown, in full. This is not an excerpt:

.arguments
   url:string
validators.mandatory:x:@.arguments/*/url
validators.url:x:@.arguments/*/url
http.get:x:@.arguments/*/url
html2markdown:x:-/*/content
   url:x:@.arguments/*/url
openai.tokenize:x:@http.get/*/content
openai.tokenize:x:@html2markdown
yield
   markdown:x:@html2markdown
   html_tokens:x:@openai.tokenize/@openai.tokenize
   markdown_tokens:x:@openai.tokenize

Fetch it, convert it, count the tokens twice, return three fields. The language is Hyperlambda, which is my own thing, so take the language advocacy with as much salt as you like — the point I care about is that a working tool can be this small, and that you can check.

Not all nine are that short. The dead link checker is about seventy lines, because deduplicating links and surviving hosts that refuse connections is genuinely more work. That page says so and prints all seventy.

They're also MCP tools

Every HTTP endpoint on this platform is automatically exposed as an MCP tool, filtered by role. So these aren't just web pages — an agent can call the same endpoints directly, and "build a tool" and "build an agent tool" stopped being two separate tasks.

That turned out to be the thing I use most. Half of these exist because I wanted Claude to be able to read a page properly.

The honest limits

Things I'd rather you hear from me than discover:

No JavaScript rendering. Everything fetches server-rendered HTML. A client-side-rendered SPA comes back nearly empty — which is also exactly what most AI crawlers see, so arguably that's the useful answer.
The dead link checker crawls 10 sitemap pages max, though it checks every link it finds on them.
The image gallery caps out at 50 results.
Some sites return 403/999 to anything that isn't a browser. That's a bot refusal, not a broken link, and the dead link checker separates those into their own bucket instead of calling them dead.
These are free and shared. Please don't point a load test at them.

So — what should number 10 be?

This is the actual reason for the post. I'm better at building these than at thinking of them.

What I'm after is the thing you currently do by hand, or with a browser extension you don't trust, or by pasting into three different sites in sequence. Ideas I've had and rejected as too boring: another JSON formatter, another minifier, another base64 thing.

Some prompts, if it helps:

What's the last web-related task where you thought "surely something does this for me" and nothing did?
Is there a tool you use that's fine except for one missing feature?
What would you want an AI agent to be able to do to a web page, that it currently can't?

Reply with whatever comes to mind. If I build yours I'll say so in the thread, and it'll be free and no-signup like the rest.

And if one of the nine is broken or wrong for your site, I'd genuinely rather know — tell me the URL you tried.

Magic vs Directus: An Honest Feature Matrix

Thomas Hansen — Tue, 01 Sep 2026 06:28:11 +0000

The n8n matrix was easy mode. The PocketBase one was hard mode, because PocketBase is Magic's closest architectural sibling.

This one is different again. Directus is not Magic's closest sibling — it is Magic's closest competitor. If you are evaluating a platform that wraps a database you already have, in whatever engine it happens to live in, without migrating anything, then Directus and Magic are pitching you the same sentence. It is a genuinely excellent product with a decade of polish on it, and on several rows below it beats Magic outright.

One sentence of thesis before the table, because every row descends from it:

Directus computes your API at runtime. Magic writes it to disk.

Directus introspects your schema, holds permissions as configuration, and resolves each request against both. Nothing is written down — the effective API exists only as the result of that computation. Magic's generator emits actual endpoint files you can open, read, diff, edit and commit. Watch how far that one difference propagates.

The matrix

Feature	Directus	Magic Cloud
Licence	Monospace Sustainable Core License — source-available, non-compete, with licence-key enforcement you may not circumvent; converts to GPL-3.0 four years after each release	MIT, all of it, no thresholds and no conversion date
Free tier	Core: 3 user seats, 25 collections, 5 flows, no SSO	Self-host everything, uncapped, forever
Small-company escape hatch	Open Innovation Grant — fully permissive and free under $5M revenue and under 50 employees	Not needed; MIT has no revenue test
Paid tier	Team at $499/mo annual, $599 monthly — 10 SSO seats, 50 collections, 20 flows	$100/mo per cloudlet, $300 for double the machine
Per-user cost	$50 per extra seat per month	None — unlimited users, never counted
Table cap	A collection maps to a database table: 25 on Core, 50 on Team, $100 per extra 25	None
Managed hosting	$99/mo add-on, on top of the plan	Included in the cloudlet price
SSO	Team plan and up; unavailable on Core at any price	Eight OIDC providers built in — Google, Microsoft, GitHub, LinkedIn, Slack, Okta, Auth0, Keycloak
The API	Computed at runtime from schema and config	Generated Hyperlambda files — real, readable, versionable
Schema changes	Reflected instantly, nothing to regenerate	Re-run the generator
Database engines	PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, OracleDB, CockroachDB	SQLite built in, plus MySQL, PostgreSQL and SQL Server
Access control	Granular: field-level and item-level rules as filter expressions	Endpoint-level role gating, plus runtime slot whitelisting
Custom logic	Extensions in TypeScript, with a build step; Flows with sandboxed JS operations	Hyperlambda files, hot — no compile, no restart, generated from a prompt if you like
Content features	Revisions, drafts, translations, activity log — a decade of CMS heritage	None of it; not a CMS
Assets	File library with on-the-fly image transformation	File system, upload tickets, image resize and convert
Realtime	WebSockets and GraphQL subscriptions	SignalR — programmable events
Frontend hosting	Not the story	First-class static and SPA hosting per cloudlet
AI and RAG	AI Assistant, AI Translations on higher tiers	ML types, crawling, vectorisation, deployable chatbots
Agent story	MCP server over the API	Native MCP with OAuth; agents generate new tools for themselves at runtime inside RBAC
Non-developers	Genuinely usable by editors and ops people	A developer tool, and honest about it
Community	Large, funded, SOC 2, partner programme	Small

Where Directus wins, stated plainly

Per the rules of this series: no rebuttals in this section. They live below.

Permissions granularity. Field-level and item-level rules, expressed as filter conditions, evaluated per request. Magic gates by role at the endpoint. If your requirement is "this role sees every column except salary, and only rows in their own region", Directus expresses that as configuration and Magic expects you to write it. That is the widest genuine capability gap in the table.

Instant schema reflection. Add a column, and Directus's API has it. No regeneration step, no stale endpoints, no forgetting to re-run anything. This is the direct upside of the runtime model, and on a schema that changes daily it is a real ergonomic win.

Content management. Revisions, drafts, translations, an activity log people actually audit. Directus descends from headless CMS and it shows in a hundred small places Magic has never attempted.

Non-developer usability. You can hand Directus Studio to a marketing team. You cannot hand Hyper IDE to a marketing team, and I would not suggest trying.

Database engines. Oracle, MariaDB and CockroachDB are supported there and not here.

Ecosystem and assurance. A funded company, a partner programme, SOC 2 Type II, an extension marketplace, a large forum, and people you can hire who already know it. Every one of those is a cost I carry on my side of this table.

Where the bets diverge

The runtime model versus the generated one. Directus's API is a computation; Magic's is a file. That means Directus wins on schema churn and loses on inspection. There is no artefact to review, diff, or hand to a code reviewer — your effective API and permission surface live as rows in a config database, and the only way to know what they do is to ask the running system. Magic's endpoints are text on disk. You can read them, put them under git, and — the part that matters most here — hand them to an AI agent that can read them too.

Which is why the agent stories are not comparable. Both have MCP. But an agent pointed at Directus can call the API; an agent pointed at Magic can read what the API is, and then write more of it. Magic's generator emits Hyperlambda that executes as an AST where every node must bind to a whitelisted slot, so generated code cannot exceed its permissions no matter what the prompt said. That is the difference between an agent that queries your backend and an agent that builds it. There is a standing $100 bounty on proving that boundary wrong.

The extension model, again. This series keeps landing here because it keeps being the fork in the road. Directus extensions are TypeScript with a build step; Flows give you sandboxed JS for the smaller cases. Magic's custom logic is a Hyperlambda file that is live the moment it is saved — no compiler, no restart, no deploy — and can be written from a sentence.

Pricing shape, which is a licensing argument wearing a costume. Directus meters the two things that grow when your project succeeds: people and tables. Core stops at 3 seats and 25 collections. Team is $499/mo for 10 seats and 50 collections, with extra seats at $50/mo and extra collections at $100 per 25. Managed hosting is another $99. Magic charges per cloudlet — $100 or $300 — and counts neither users nor tables, ever.

Work an example. A team of six developers wrapping a 70-table legacy database, hosted: on Directus that is Team, plus one 25-collection pack, plus cloud — call it $698/mo before anyone else logs in. On Magic it is $100, and the seventh developer changes nothing.

Two honest caveats on that comparison, because it flatters me. If you are under $5M revenue and under 50 employees, the Open Innovation Grant makes Directus free and fully permissive, and this entire paragraph is moot for you — take the grant. And Directus is grandfathering existing customers, so anyone already on an older plan is not living in the table above.

The licence, which is the row I would read twice. Directus is source-available, not open source: the Monospace Sustainable Core License forbids Competing Use, forbids circumventing the licence-key functionality, and grants GPL-3.0 only on the fourth anniversary of each release. That is a defensible way to run a company, and I say that without snark — it is a real answer to a real sustainability problem. But it is not the same deal as MIT, and the difference shows up on the day your revenue crosses a threshold, or your lawyer asks what "Competing Use" means for the product you are building on top of it. Magic is MIT with nothing held back, no key, no threshold, no clock.

The decision rule

Choose Directus if: non-developers will use the admin UI daily; you need field- and row-level permissions as configuration rather than code; your content needs revisions, drafts or translations; your schema changes constantly; you are on Oracle or CockroachDB; or you qualify for the Open Innovation Grant, in which case a mature, funded, SOC 2 platform costs you nothing and that is very hard to argue with.

Choose Magic if: you are above the grant's thresholds and do not want per-seat and per-table metering; you want the API as reviewable source rather than runtime configuration; you need the platform to host the frontend as well as the data; or — the structural one — you expect AI agents to be building the backend rather than querying it.

The test that decides it in one question: does your backend need to be read by anything other than the server that runs it? If yes — by a reviewer, by git, by an agent — you want files. If no, a runtime model is less work.

The fine print

Every number above about Directus was verified on their own pricing and licence pages the day this was published: the MSCL-1.0-GPL terms, the $0 / $499 / custom tiers, the 3-seat and 25-collection Core caps, $50 per extra seat, $100 per 25-collection pack, the $99 cloud add-on, and the under-$5M-and-under-50-employees grant. Pricing pages move. If you are reading this months later, re-verify before quoting me — and I would rather you checked than trusted me.

The database engine list for Directus is from documentation rather than from my own testing, and Magic's own comparison rows are, obviously, written by the person who wrote Magic. Read the table with that in mind.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic. Testing any of this yourself takes one copy-paste on a $6 DigitalOcean droplet, or a managed cloudlet if you would rather not.

FAQ

Is Magic Cloud a Directus alternative?

For the developer case, yes — both wrap an existing database in a secured API without migrating it, both ship an admin UI, both self-host, both offer managed hosting. For the editorial case, no: Directus is a headless CMS with revisions, drafts and translations, and Magic is not trying to be one.

Is Directus open source?

Not in the OSI sense any more. It is source-available under the Monospace Sustainable Core License, which prohibits Competing Use and licence-key circumvention, and converts each release to GPL-3.0 after four years. Magic is MIT.

Is Directus free?

Free at the Core tier within hard caps — 3 seats, 25 collections, 5 flows, no SSO — and genuinely free and fully permissive under the Open Innovation Grant if your organisation is under $5M in revenue and under 50 employees. Above those lines it is $499/mo and up, with per-seat and per-collection metering.

Which handles a large legacy schema better?

Directus reflects the whole schema instantly with nothing to generate, which is the better ergonomic. But collections are capped by plan, and a 200-table system lands you in Enterprise pricing. Magic makes you run the generator and gives you files afterwards, with no table count anywhere in the pricing.

Can AI agents use both?

Both expose MCP. The difference is what the agent can do once connected: with Directus it calls your API; with Magic it can read the generated code and write more of it, inside a runtime that constrains what generated code is even able to express.

From Prompt to MCP Tool in 5 Seconds

Thomas Hansen — Tue, 18 Aug 2026 10:39:46 +0000

Building an MCP tool, as the industry currently understands the job: install an SDK, write a server, hand-author a tool schema, wire the handler, host the process, deploy it, restart it, reconnect the client.

Here is the same job on Magic, the MIT-licensed backend platform I work on.

You write a sentence.

That is the whole procedure, and this article is about why — because the interesting part is not that it is fast. It is that there is no second step to be fast at.

The measured run

I did this on the cloudlet serving my website while writing the article. The generator reports its own execution time, so these numbers are server-measured, not my stopwatch.

I wanted a tool that did not exist: a daily trend over the anonymous submissions to our carbon calculator — how many people submitted each day, and how heavy their average footprint was.

Attempt	Seconds (measured)	Outcome
First generation	2.88	Saved, then threw a 500 on invocation
Regenerated	1.83	Live and correct
Regenerated for a better description	3.03	Live, correct, properly documented

Three generations, 7.74 seconds of compute, one live tool. It is public and read-only, so you can call it yourself right now:

curl "https://hyperlambda.dev/magic/modules/mcp-demo/footprint-trend?days=365"

[{"day":"2026-08-09","submissions":2,"average_total_kg":16188.0},
 {"day":"2026-08-03","submissions":1,"average_total_kg":8772.0}]

I will come back to that failed first attempt, because the honest part of this story is more useful than the fast part.

There is no second step

The file the generator saved is this. The comment is abbreviated here; everything else is verbatim.

// Returns the daily trend of anonymous carbon footprint submissions, one entry per day [...]
.arguments
   days:int
validators.default:x:@.arguments
   days:int:7
data.connect:billionair
   data.select:"select date(created) as day, count(*) as submissions, avg(total_kg) as average_total_kg from footprints where created >= date('now', '-' || @days || ' day') and total_kg > 0 group by day order by day desc"
      days:x:@.arguments/*/days
   return-nodes:x:@data.select/*

Saving that file is the last thing that happens. There is no build, no restart, no registration, no export.

The reason is that Magic's MCP server has no tool registry. It does not keep a list of tools that somebody has to remember to update. When a client asks what tools exist, the server enumerates the endpoints that exist, right then, and describes them. The catalogue is not a copy of reality that can drift out of date — it is a query against reality.

Which means a tool cannot be added to the tool list. It can only be created, after which the list already contains it.

The same is true in the other direction, and this is the part I find quietly elegant: calling a tool runs the endpoint. Not a copy of the endpoint, not a proxy in front of it — the endpoint, through the same invocation path an HTTP request takes, carrying the caller's own identity. So the role check that guards it from a browser is the role check that guards it from an agent, because it is the same check. There was never a second one to keep in sync.

Your prompt is the tool description

Now the mechanic that makes one sentence sufficient.

A language model deciding whether to call a tool reads two things: the tool's description, and a description of each argument. In every other stack, those are a third artifact — written by hand, next to the code and the schema, and stale within a month.

Magic publishes an endpoint's file comment as the tool description, and the comment above each argument as that argument's description. And the generator writes the file comment from your prompt.

So the sentence you typed is not merely instructions to a code generator that get thrown away afterwards. It survives, in the file, as the documentation your agent reads. Here is what came back out the other end, from this cloudlet's live specification:

"/magic/modules/mcp-demo/footprint-trend": {
  "get": {
    "operationId": "get_mcp-demo_footprint-trend",
    "description": "Returns the daily trend of anonymous carbon footprint submissions, one entry per day, so a caller can see how many people submitted and how heavy their average footprint was [...]",
    "parameters": [{ "name": "days", "in": "query", "schema": { "type": "integer" } }]
  }
}

I never wrote a schema. I wrote days in a sentence, said it was an integer, and the type came along for the ride.

The mapping from Hyperlambda's types to JSON Schema is boring on purpose:

Hyperlambda	JSON Schema
`short`, `int`, `long`	`integer`
`decimal`, `double`, `float`	`number`
`bool`	`boolean`
`date`	`string`, format `date-time`
`guid`	`string`, format `uuid`
everything else	`string`

So write the prompt like a docstring

Here is a mistake I made in front of you, and it is the most useful paragraph in this article.

My second attempt worked perfectly, and its description read:

"Use a single SQL statement that does all date arithmetic inside the database itself: group rows by the date part of the 'created' column [...] Do not perform any date arithmetic outside of SQL."

Every word of that is true, and every word of it is useless to the model that has to decide whether to call the tool. I had written a work order for a compiler and published it as documentation. An agent reading that learns nothing about when this tool is the right answer — it learns how I wanted the SQL written.

So I regenerated a third time, with the same requirements in a different order: what the tool returns first, who would want it, what the argument controls, and the implementation constraint last. That is the 3.03-second run in the table, and it is the version now serving.

The rule that falls out of this is short. The prompt becomes the docstring, so write it as one. Lead with what the tool does and when to use it. Name every argument and its type. Put implementation notes at the end, where they belong — after the sentence a model actually needs.

Nobody writes tool definitions on this platform. But somebody still has to write the first sentence well, and that somebody is you.

The honest edges

The first generation was wrong. It compiled, it verified, it saved, and it threw a 500 the moment I called it — it had tried to subtract dates in a way the runtime found ambiguous. The verifier proves that every instruction in generated code exists and is real; it does not prove the code does what you meant. That still requires running it, which is why I ran it.

Note the fix, though: I did not open the file. I changed one clause in the prompt and regenerated, 1.83 seconds. When the build path is that short, it is also the repair path — hand-editing generated code is not the workflow here, and does not need to be.

Your client may not notice immediately. The server's catalogue is current the instant the file lands, but most MCP clients fetch the tool list once, when they connect, and cache it. The tool is live, callable, and in the catalogue — your agent just will not see it until you reconnect the connector. This trips people up regularly, and it is a client behaviour, not a server one.

Two smaller ones. Some clients enforce a 64-character limit on tool names; Magic does not truncate, so a very deeply nested module path could produce a name a strict client dislikes. And the transport is plain request/response JSON — a spec-compliant subset, with no SSE stream and no server-initiated messages.

One cloudlet, several servers

A last detail worth knowing. The MCP endpoint takes an optional path, which narrows the catalogue to one module subtree — point a client at ?path=/modules/crm/ and it sees the CRM tools and nothing else. The narrowing is confined inside modules/ and normalised at both ends, so /modules/crm cannot leak into a sibling like /modules/crm-archive.

Combine that with the catalogue being assembled per caller — Magic reads the roles on the authenticated ticket and lists only endpoints that caller may execute — and one backend serves as many different, differently-scoped MCP servers as you have audiences for. I made that argument properly in the OpenAPI article, so I will not repeat it here.

Try it

One command:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

Open localhost:5555, point it at localhost:4444, log in with root / root, and describe a tool you wish you had. Then connect an agent and look for it.

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

The five seconds in the title is the round number. The measured ones were 2.88, 1.83 and 3.03 — and honestly, the seconds are the least interesting thing about it. What matters is that when they elapsed, there was nothing left to do.

From Module to GitHub Repository in One Click

Thomas Hansen — Sat, 08 Aug 2026 06:06:44 +0000

Yesterday one of my modules became a GitHub repository. The whole ceremony: hover the folder, click the branch icon, write a commit message, click Publish.

Behind that one click, Magic created a private repository on GitHub, added it as the module's origin remote, pushed the commit, and configured upstream tracking. Four git operations, zero terminal.

You know the manual version of this dance. Create the repository in GitHub's UI or with gh repo create, copy the URL, git remote add origin, git push -u origin master, and somewhere in the middle a context switch that costs more than all the commands combined. That dance is now a button — because Hyper IDE has Git built in, and this article is the tour.

Where Git lives

Every top level folder inside /modules/ and /etc/ is treated as a repository root. Hover one in Hyper IDE's file tree, and a branch icon appears among its actions — that is the whole discovery story. One repo per module, deliberately: the module is already the unit of install, the unit of deployment, and the unit of meaning in Magic. Now it is the unit of versioning too.

The panel

Click the icon and you get the state of that repository: which branch you are on, whether you are ahead of or behind your remote, and every modified and untracked file. Commit everything with a message, push, pull, fetch, switch branches, create new ones.

The detail I care most about is what you cannot click. Push is greyed out until you actually have commits your remote does not. Clone demands an empty folder, because git demands an empty folder. A freshly initialized repository disables everything that requires a commit to exist. The panel teaches you git's rules by construction, instead of relaying git's error messages after the fact.

One token, no keychain

Setup is a single dialog: open Configuration, click the hamburger menu, choose Git…, and give it your GitHub username and a fine-grained personal access token with Contents read and write access.

The architecture behind that dialog matters more than the dialog. Credentials are injected per git invocation, over HTTPS, as a header — nothing is ever written to the server's global git configuration, no credential helper, no SSH keys sitting on disk. And commits are authored as you: the author name and email are resolved from the signed-in user's profile, so your history on GitHub shows your name, not some shared server identity. The token authenticates transport; people author commits.

The one click

Back to the headline. Take any module — say one you have been building all week — and open its Git panel. Not a repository yet? Click Initialize repository. Write a commit message, click Commit. Then click Publish to GitHub…, and give the repository a name — it defaults to the module's folder name, which is almost always the right answer.

That click creates the repository on GitHub — private by default, flip it to public over there if that is what you want — wires it up as origin, pushes your commit, and sets upstream tracking. Your module has a home, a history, and a URL.

Notice, creating repositories needs one more permission than reading and writing them: the account level repository creation permission on your access token, in addition to Contents. If your token lacks it, the panel will tell you so in plain text, because errors here are never swallowed.

The door swings both ways

Publishing is half the story. The other half: create a new empty folder inside /modules/, open its Git panel, and you get the mirror options — initialize, or clone.

Click Clone into folder, paste the repository's HTTPS URL, and the module lands on your cloudlet with its entire history attached. It checks out whatever the remote's default branch happens to be called — the panel has no opinions in the main-versus-master wars, and after debugging that assumption out of an earlier iteration, neither do I.

Modules travel now

Here is why this is more than a convenience feature.

Magic has always let you move modules between cloudlets as zip files — download here, install there. A zip is a snapshot. Git is a history: branches, rollback, blame, and a remote that two cloudlets can both talk to. Develop a module on your dev cloudlet, publish it, clone it into production, and from then on promotion is a pull. The zip workflow did not go anywhere — but the module you care about, the one that grows for months, wants version control, and now the platform it lives on speaks it natively.

And because everything in Magic is reachable by agents, the same is true over MCP — the git workflow tools have been callable by AI agents for a while. What is new is that humans got the good UI too.

The fine print

Big claims, precise edges — as always.

This is not a full git client, and it does not want to be. Commit stages everything the change list shows — there is no per-file staging in v1. There is no diff viewer and no merge-conflict UI; if a pull lands you in conflict territory, clone the repository locally and resolve it with real tooling, then push. The panel covers the module lifecycle — initialize, commit, branch, publish, clone, pull, push — not interactive rebases.

One deliberate sharp edge worth knowing: paths must be repository roots. Git's normal upward discovery is disabled on the server, so a folder that is not itself a repo throws instead of silently operating on some enclosing repository it happened to find above itself. That rule exists because during development, the panel on a repo-less folder cheerfully offered to commit the entire Magic source tree it found two levels up. Loud beats silent, every single time.

The whole feature was built in a day, driving Claude against the running dashboard — including three separate ambushes by a hardcoded main branch assumption and the discovery bug above. That story, bug ledger and all, is its own article.

The keys

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io. If you want a cloudlet of your own to publish modules from, it is one copy-paste on a $6 DigitalOcean droplet.

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.

DEV Community: Thomas Hansen

Masturbation Is 100 Times More Dangerous Than AI

The comparison

The limitations

Other unusual causes of death

Bee, wasp and hornet stings

Cattle

Lightning

Furniture and televisions

Vending machines

Falling coconuts

Why the comparison is useful

Your sitemap is an API — a whole website as one JSON document in 35 lines

What comes back

The entire backend

The parts worth stealing

What it will not do

The part I actually find interesting

Try it

I built 9 free web tools and printed the entire backend on every page. What should number 10 be?

The nine

What "the whole backend" actually looks like

They're also MCP tools

The honest limits

So — what should number 10 be?

Magic vs Directus: An Honest Feature Matrix

The matrix

Where Directus wins, stated plainly

Where the bets diverge

The decision rule

The fine print

FAQ

Is Magic Cloud a Directus alternative?

Is Directus open source?

Is Directus free?

Which handles a large legacy schema better?

Can AI agents use both?

Related reading

From Prompt to MCP Tool in 5 Seconds

The measured run

There is no second step

Your prompt is the tool description

So write the prompt like a docstring

The honest edges

One cloudlet, several servers

Try it

Related reading

From Module to GitHub Repository in One Click

Where Git lives

The panel

One token, no keychain

The one click

The door swings both ways

Modules travel now

The fine print

The keys

Related reading

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

The rate card, straight from Anthropic

Where a coding agent's tokens actually go

What we built to prove it

The build ledger

The five mechanisms

1. Declarative calls replace emitted code

2. Code generation happens server-side

3. Code never round-trips through context

4. No debug spirals

5. One-call grounding

The accounting: same app, two architectures

Where 10x holds — and where it is 5x

Conclusion

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

The runtime is the security boundary

Receipts

Why free-form codegen can't make this offer

How to collect

If you're evaluating AI agent platforms

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

The database was the boring part

What got built