DEV Community: Thomas Hansen

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

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

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

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

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

The Migration Industrial Complex

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

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

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

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

Prompts are not permissions

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

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

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

RBAC, not prompts. Permissions, not vibes.

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

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

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

The Hyperlambda Generator, or why hallucinations bounce off

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

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

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

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

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

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

The numbers

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

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

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

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

The honest version

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

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

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

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

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

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

Keep the database. Add the agent.

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

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

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

The architecture in one paragraph

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

Now the steps.

Step 1. Create a scoped database user for Magic

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

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

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

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

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

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

Step 2. Connect the database to Magic

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

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

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

Step 3. Generate CRUD endpoints for the tables that matter

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

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

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

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

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

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

Step 4. Connect your agent over MCP

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

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

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

Step 5. Give it real work

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

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

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

What you have at the end

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

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

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

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

FAQ

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

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

Can I do this without allowing any writes?

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

Does my database need to be reachable from the internet?

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

Do I have to write Hyperlambda?

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

The first LLM on earth that cannot hallucinate

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

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

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

What a hallucination actually is when a model writes code

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

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

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

Step 1: Close the vocabulary

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

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

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

Step 2: Statically prove every instruction exists

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

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

The model made strings.reverse up. The verdict:

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

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

Step 3: The model never gets a vote

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

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

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

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

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

The fine print, up front

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

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

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

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

Why I think this is the actual answer

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

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

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

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

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

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

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

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

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

The quick comparison

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

Now the parts a table can't capture.

1. It connects to the database you already have

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

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

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

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

2. Backend logic without a separate runtime

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

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

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

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

3. Sending email is a platform primitive

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

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

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

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

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

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

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

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

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

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

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

6. Nothing is gated

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

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

Where Supabase is still the right choice

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

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

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

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

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

Summing up

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

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

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

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

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

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

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

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

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

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

Creating Full Stack Apps with Mythos and Magic

Thomas Hansen — Wed, 01 Jul 2026 06:58:40 +0000

I wanted to see how far an AI agent could get building a real, deployed full-stack app against Magic Cloud using nothing but MCP tool calls — no hand-written code. Here's what came out of one session.

The Stack

Backend: Hyperlambda, generated entirely via the generate-hyperlambda MCP tool (never hand-written — the platform enforces this)
Database: SQLite, crm database, single contacts table
Frontend: Vanilla HTML/CSS/JS SPA served from /etc/www/
Auth: Magic Auth (built-in RBAC/JWT)
Orchestrator: Claude, via the Magic MCP connector (~105 tools across 14 namespaces)

What Got Built

Schema: a contacts table (name, email, phone, company, notes) via execute-sql
CRUD API: four separate Hyperlambda endpoints — create, read (paged/sorted/filtered), update, delete — each generated as its own generate-hyperlambda call and auto-exposed as an MCP tool the moment it's saved
Frontend: login-gated SPA, JWT stored in localStorage, auto-refreshing the ticket every 10 minutes, classic/corporate visual theme
Seed data: 10 example contacts inserted directly via SQL

Total build time: minutes, not hours.

Two Bugs Worth Knowing About

1. GET/DELETE requests can't carry a Content-Type header.

Hyperlambda's HTTP layer throws if you decorate a GET or DELETE request with a content-type header. You cannot decorate an HTTP GET or DELETE request with content type of headers.

This bit both the MCP invoke-http tool (which defaults to application/json unless you override with an empty headers object) and would have bitten the frontend if I hadn't special-cased it — app.js only attaches Content-Type on POST/PUT.

2. Relative asset paths break without a trailing slash.

/etc/www/crm-contacts/index.html serves at /crm-contacts/. But if a user hits /crm-contacts (no trailing slash), the browser resolves <link href="style.css"> against domain root, not the folder — instant 404. Fix: use absolute paths (/crm-contacts/style.css) in every asset reference. Easy to miss, annoying to debug from a screenshot of a 404.

The Interesting Part

The Hyperlambda generator refuses to be hand-debugged — the platform's own tooling actively pushes you toward invoke-http and the OpenAPI spec instead of trying to read/patch the generated .hl files directly. That constraint, combined with checking log_entries in the magic SQLite database for the actual exception text, was faster for root-causing both bugs above than staring at HTTP status codes would have been.

Takeaway

Framework-enforced constraints (no hand-written Hyperlambda, RBAC at execution time, generator-only codegen) slow down the "just let me fix this one line" instinct — but they're also what made a zero-manual-code CRM buildable in a single sitting without the usual pile of copy-pasted, unreviewed AI-generated backend code.

You can watch me going through the whole process below ...

A practical guide to headless browser automation in Hyperlambda

Thomas Hansen — Thu, 19 Mar 2026 10:56:14 +0000

A lot of browser automation tooling feels like it was designed for its own ecosystem first and for your application second.

You end up learning a separate mental model, a separate lifecycle, and usually some kind of invisible context that makes simple things harder to reason about than they should be.

I did not want that.

When I added headless browser support to Hyperlambda, I wanted it to feel like the rest of the language. I wanted a small set of explicit operations that I could combine in predictable ways. Connect to a browser. Navigate somewhere. Wait for the page to become usable. Click, type, inspect, screenshot, close.

That is basically it.

This article is a practical walkthrough of how I use the headless browser slots in Hyperlambda.

The core idea

The model is intentionally simple.

You start by opening a browser session. That returns a session_id. Then you pass that session_id into every other browser-related slot.

I like this because there is no hidden browser object, no ambient scope, and no guessing about where state lives.

The flow is visible.

Connect
Navigate
Wait
Interact
Read state
Save a screenshot if needed
Close

Here is the smallest possible example.

.session_id
set-value:x:@.session_id
   puppeteer.connect

puppeteer.goto:x:@.session_id
   url:"https://ainiro.io"

puppeteer.title:x:@.session_id

puppeteer.close:x:@.session_id

If you understand that pattern, everything else builds on top of it.

How I start a browser session

The first slot I use is puppeteer.connect.

Minimal version:

.session_id
set-value:x:@.session_id
   puppeteer.connect

That launches Chromium and returns a session identifier.

If I need more control, I can add configuration such as headless mode, executable path, launch timeout, extra Chromium flags, or lifetime settings.

For example:

.session_id
set-value:x:@.session_id
   puppeteer.connect
      headless:true
      timeout:30000
      args
         .:--no-sandbox
         .:--disable-dev-shm-usage
      timeout-minutes:30
      max-lifetime-minutes:120

Most of the time, I do not need anything beyond the default call. But it is useful to know I can tune launch behavior when I need to.

How I navigate to a page

Once I have a session_id, I can send the browser somewhere with puppeteer.goto.

puppeteer.goto:x:@.session_id
   url:"https://ainiro.io"

That is enough for simple flows.

If I want more deterministic behavior, I add timeout and a wait strategy.

puppeteer.goto:x:@.session_id
   url:"https://ainiro.io"
   timeout:30000
   wait-until:networkidle2

The wait-until argument matters more than people think.

Some pages are usable as soon as the DOM exists.
Some keep loading assets after initial render.
Some populate important UI elements after async JavaScript completes.

That is why I usually treat goto as navigation, not as proof that the page is ready for the next action.

How I wait for the page to become usable

In practice, I rarely rely on navigation alone.

If I know I need a specific element before continuing, I wait for that element explicitly.

puppeteer.wait-for-selector:x:@.session_id
   selector:"#name"
   visible:true
   timeout:10000

That makes the automation more stable because I am waiting for the thing I actually care about.

If I expect the page URL itself to change after some action, I can wait for that too.

puppeteer.wait-for-url:x:@.session_id
   url:"https://ainiro.io/contact-us"
   timeout:10000

I think this is one of the biggest differences between browser automation that mostly works and browser automation that keeps breaking in annoying ways.

Do not wait for abstract readiness if your next step depends on something concrete.

Wait for the concrete thing.

How I click buttons and links

For clicks, I use puppeteer.click.

puppeteer.click:x:@.session_id
   selector:"#submit_contact_form_button"

If I need to adjust how the click happens, I can add options.

puppeteer.click:x:@.session_id
   selector:"#submit_contact_form_button"
   click-count:2

It is intentionally straightforward.

Find the selector. Click the selector. Move on.

That is exactly the kind of browser automation API I prefer.

How I type and fill form fields

There are two useful variants here.

If I want to type text into a field without clearing it first, I use puppeteer.type.

puppeteer.type:x:@.session_id
   selector:"#name"
   text:"Thomas Hansen"

If I want to replace whatever is already there, I use puppeteer.fill.

puppeteer.fill:x:@.session_id
   selector:"#email"
   text:"thomas@gaiasoul.com"

If I want a more human-looking typing pace, I can add delay.

puppeteer.type:x:@.session_id
   selector:"#info"
   text:"Hello from Hyperlambda"
   delay:25

That covers most form automation I need.

And if I need keyboard-level interaction rather than button clicks, I can use puppeteer.press.

puppeteer.press:x:@.session_id
   selector:"#submit_contact_form_button"
   key:Enter

How I work with selects

Dropdowns use puppeteer.select.

puppeteer.select:x:@.session_id
   selector:"#plan"
   values
      .:basic
      .:pro

That is especially useful when automating admin panels, onboarding forms, or internal tools where select controls are common.

How I inspect the page

Not every browser session is about clicking through forms.

Sometimes I just want to inspect what the browser sees after the page has fully rendered.

For that, I typically use these slots:

Read the title

puppeteer.title:x:@.session_id

Read the current URL

puppeteer.url:x:@.session_id

Read the rendered HTML

puppeteer.content:x:@.session_id

That last one is particularly useful because it gives me the page as the browser sees it after JavaScript execution, not just the original raw server response.

If I need something even more targeted, I can evaluate JavaScript directly in the page.

puppeteer.evaluate:x:@.session_id
   expression:"document.title"

Or:

puppeteer.evaluate:x:@.session_id
   expression:"typeof window.mcaptcha"

That gives me a quick way to inspect runtime state without building a bigger extraction flow.

How I save screenshots

Screenshots are useful for debugging, documentation, and simple verification.

Here is the basic PNG example.

puppeteer.screenshot:x:@.session_id
   filename:"/etc/tmp/example.png"
   full-page:true

And here is a JPEG version.

puppeteer.screenshot:x:@.session_id
   filename:"/etc/tmp/example.jpg"
   type:jpeg
   quality:85

This is one of those features I end up using more than I expect.

If something fails in an automated flow, a screenshot often gives me the answer much faster than logs alone.

How I close the session

When I am done, I close the browser.

puppeteer.close:x:@.session_id

I know that sounds obvious, but I still think it matters to treat connect and close as part of the actual program design.

Open the resource.
Use the resource.
Close the resource.

That keeps the flow readable and avoids unnecessary browser sessions hanging around.

A full example

Here is a simple end-to-end example.

It opens Chromium, goes to a page, waits for network activity to calm down, reads title and URL, takes a screenshot, and closes the session.

.session_id
set-value:x:@.session_id
   puppeteer.connect

puppeteer.goto:x:@.session_id
   url:"https://ainiro.io"
   timeout:30000
   wait-until:networkidle2

puppeteer.title:x:@.session_id
puppeteer.url:x:@.session_id

puppeteer.screenshot:x:@.session_id
   filename:"/etc/tmp/ainiro-homepage.png"
   full-page:true

puppeteer.close:x:@.session_id

And here is a form-oriented example.

.session_id
set-value:x:@.session_id
   puppeteer.connect

puppeteer.goto:x:@.session_id
   url:"https://ainiro.io/contact-us"
   timeout:30000
   wait-until:networkidle2

puppeteer.wait-for-selector:x:@.session_id
   selector:"#name"
   visible:true
   timeout:10000

puppeteer.fill:x:@.session_id
   selector:"#name"
   text:"Thomas Hansen"

puppeteer.fill:x:@.session_id
   selector:"#email"
   text:"thomas@gaiasoul.com"

puppeteer.type:x:@.session_id
   selector:"#info"
   text:"Hello from Hyperlambda"

puppeteer.click:x:@.session_id
   selector:"#submit_contact_form_button"

puppeteer.close:x:@.session_id

What I think makes this approach nice

What I like about these slots is not that they are flashy.

It is that they are predictable.

They do not try to invent a second programming model inside Hyperlambda.
They do not hide the browser lifecycle behind clever abstractions.
They do not require me to guess where state comes from.

Everything important is explicit.

You can read the flow from top to bottom and understand exactly what the browser is doing.

That is a huge advantage when the automation grows from a toy example into something that actually matters.

Final thoughts

I think browser automation should feel boring in the best possible way.

You should be able to connect, navigate, wait, interact, inspect, screenshot, and close without learning a separate philosophy just to click a button on a web page.

That is why I like the headless browser slots in Hyperlambda.

They give me enough power to automate real workflows, but they stay small and direct enough that the code remains readable.

And for me, that is usually the difference between a browser automation API I try once and a browser automation API I actually keep using.

If you want to get started with Hyperlambda you can clone Magic Cloud and Hyperlambda here.

Natural Language based DSL AST Compilers

Thomas Hansen — Fri, 13 Mar 2026 16:03:56 +0000

I've tried this 5 times, with 3 different LLMs, and the exercise is as follows.

I go to a publicly available AI chatbot, such as ChatGPT for instance
I explain it what training material I have, what process I'm following, and other details about how I fine tune
I explain Hyperlambda's syntax, by pointing it at articles and code parts

And every single time it comes back and tells me the following ...

You're beyond code-generation, what you're building is an AST compiler, based upon AI, that's almost "deterministic" in nature

Same answer every single time. Interestingly, I don't disagree. To understand why that's such a big thing, let's go through the semantics of how I am working, and with what.

Hyperlambda, the DSL

The DSL is called Hyperlambda, and it's got some pretty unique traits. For one, it's "homoiconic". That's just a fancy word for saying its execution structure is the exact same as the code format, which is true.

To understand why that's such a bloody big deal, you must realise that this implies there is no AST layer in Hyperlambda. Hyperlambda is the AST layer. Hence technically, we're simply removing several layers of complexity from traditional programming language, since Hyperlambda is simply the ability to raise events, combined with the ability to recursively traverse tree structures, passing in dynamically created recursive tree structures to said events.

One simple design pattern! Resulting in an entirely new axiom for software development as a profession ...

Since this structure is recursive in nature, this implies among other things that every complex piece of Hyperlambda, can be broken down by pruning its parent node, and the end result is valid Hyperlambda! For instance, imagine the following code ...

if
   eq:x:@.arguments/*/name
      .:Thomas
   .lambda
      log.info:Thomas was here!

The above is easily understood by most I presume, but it's basically the following in natural language; "If the name argument equals 'Thomas', log the value 'Thomas was here!'".

However, the place where it gets "weird", is that I can take any parts of the above structure, and simply "chop it up" into multiple smaller snippets, and they would all be considered value Hyperlambda. Below is an example.

eq:x:@.arguments/*/name
   .:Thomas

Then I can even modify it, and add stuff such as the following to it ...

eq:x:@.arguments/*/name
   .:Thomas
return:x:-

Which basically implies; "Compare name argument to 'Thomas' and return true if they're the same, otherwise false." And I can continue "chopping up" Hyperlambda snippets using the above technique, over and over again.

Ignoring the fact of that this has a dramatic effect on my personal ability to produce 100% correct training snippets, partially by even automating the process - LLMs happens to be "a bajillion" times better at understanding recursive structures such as the above, where everything is a function - Touch OOP! FP wins!

Sorry, I don't mean to be touchy here, but it's a known fact! LLMs can deal with functional programming languages a bajillion times better than OOP ...

And Hyperlambda is, you guessed it, FP!

Hence Hyperlambda is an AST layer, or an "Abstract Syntax Tree" - Which also might explain my difficulties explaining it to other members of the homo sapiens branch. However, more importantly, LLMs are "a bajillion" times better at understanding recursive AST layers, such as Hyperlambda, than - "traditional code".

Basically, the recursive nature of functional programming, combined with the recursive nature of Hyperlambda, due to its simple "node structure", which is basically just a graph object - Results in a "double whammy" from a fine tuning perspective and LLM perspective.

Every single time I explain my language to an LLM, they consistently comes back and refers to it as "the 100% correct way to build an AI-based 'compiler platform'" - Also a lot due to its security mechanisms may I add ...

Declarative

Hyperlambda is declarative, in addition to being homoiconic and functional. This reduces token count when dealing with LLMs by a factor of between 95% and 80%. 95% compared to C++ and 80% compared to Python. In addition, there's typically only a handful of correct ways to achieve something in a declarative language. With an imperative language like Python, there's a billion different ways to solve the same problem.

This implies you'll need millions of example of Python code to teach the same you only need 50,000 to teach in a declarative language. Simply because the "knowledge graph" is smaller, and hence the connections are reduced by a lot!

I've got 59,300 Hyperlambda training files, in a ridiculously strict training regime, of superb quality. According to ChatGPT that makes my LLM roughly on pair currently with SOTA models such as Claude Code or OpenAI's Codex.

Basically, 59,300 Hyperlambda examples is equivalent to 10 million Python examples!

Because it's not about sheer size of training material, it's about percentage covered of possible structures. In Python there are easily 20 million different structures, just combining two different concepts. In Hyperlambda that number is reduced down to maybe 100,000.

And assuming you ask it to actually do something it knows how to do, and you don't give it bananas prompts - I can pretty much guarantee you that it's easily on pair with both Claude Code and Codex!

Meta programming

The funny thing was, I started out with an extreme rush towards meta programming about 13 years ago - Realising it was something unique. To have a working meta programming language, you need to be both declarative in nature, homoiconic, and functional. Meta programming rests on these 3 pillars.

Today I don't care about its meta programming capabilities much more, since my LLM is getting so bloody good at generating code, I barely think about it. Hence the 3 bi products I barely cared about in the first place, became its most interesting traits in the long run - And my reasons for originally building it the way I did, is almost completely uninteresting at this point in time ...

Anyways, thx for reading - Both of you ... ;)

Create your Own Private DIY Silicon Valley

Thomas Hansen — Sun, 01 Mar 2026 11:11:30 +0000

It's not exactly a secret that Facebook, Google, Reddit, and others are censoring you and spying on you I presume. Personally, I've got an entire army at Reddit so passionately hating me, they've subscribed to my YouTube videos for 6 years, with the sole purpose of down voting my videos. And of course, anything I post over there, is censored in seconds ...

I got so tired of this, I figured somebody just have to solve it. Since the nature of the web is that who ever owns the box, gets to decide what gets published - I created my own box!

The above MacMini is running out of my living room. You can visit it at home.ainiro.io. I have even created a dummy little app (30 minutes job) that I deployed on to it. You can find my app below.

Dumb CRM system

HOWTO

The process is dead simple.

Get a MacMini
Install Docker on it
Use docker compose up in the same folder you've got the file below saved as "docker-compose.yaml"
Paste the docker compose file below into ChatGPT and tell it to expose both sites using Cloudflare tunnels

The docker compose file can be found here ...

version: "3.8"

services:
  backend:
    image: servergardens/magic-backend:latest
    platform: linux/amd64
    container_name: magic_backend
    restart: unless-stopped

    ports:
      - "4444:4444"

    volumes:
      - magic_files_etc:/magic/files/etc
      - magic_files_data:/magic/files/data
      - magic_files_config:/magic/files/config
      - magic_files_modules:/magic/files/modules

  frontend:
    image: servergardens/magic-frontend:latest
    container_name: magic_frontend
    restart: unless-stopped

    depends_on:
      - backend

    ports:
      - "5555:80"

volumes:
  magic_files_etc:
  magic_files_data:
  magic_files_config:
  magic_files_modules:

All in all, the process took me 30 minutes, after which I had a fully functioning (and secure) web server, serving my own apps, out of my own living room. Get the source to Magic below, or read more about it on my website.

Setup Magic Cloud on your own Development Machine

Thomas Hansen — Tue, 17 Feb 2026 06:55:25 +0000

Magic Cloud is an open source full stack "vibe coding platform". What I mean by that, is that you can create full stack apps using AI without coding. Below is an example of what you can create.

The above is a simple CRM system that was created in about 10 minutes. The system, created my database, my API, and my frontend. 100% without coding. In addition, it added Google SSO, and secured my app 100% automatically. You can watch a video below of how to setup Magic.

Magic's Unique Value Proposition

There exists "a bajillion" similar platforms out there. However, most of these are focused on "citizen". Personally, I love the idea of arming citizen, but for me it's much more interesting solving real problems.

Hence, I created a vibe coding platform for professionals instead. What I mean by that is that Magic Cloud is a vibe coding platform specifically created for the SMB and Enterprise market, and not "citizen".

It's got security built-in as the standard, coming out of the box. It's got zero lockins, allowing you to host it anywhere you wish. It's easily deployed into Kubernetes, allowing you to "scale it to the moon" if required. And it (of course), features everything you'd need from a modern AI automation platform; Such as for instance ...

Git integrations.
Terminal integrations.
100+ functions, for everything from saving files, to creating databases, and to searching your files.
Connect it to PostgreSQL, MySQL, SQL Server, and any database you might have from before.
Run your backend on anything, not only Supabase
Run your frontend from anything, including inside your LAN

And of course, it helps having a platform that's literally so blistering fast and optimal, you could probably deploy it on a Raspberry PI if required ...

If you want to read more about Magic, you can find my website below.

AINIRO Magic Cloud

Why I Built Magic Cloud for Real Enterprise Teams (Not Demo Land)

Thomas Hansen — Sun, 15 Feb 2026 18:27:46 +0000

There’s a recurring pattern I’ve seen for years in enterprise software: We keep piling tools on top of tools, hoping the stack will somehow solve the bottleneck.

But the bottleneck isn’t the stack. It’s the loop: idea, backlog, spec, implementation, deployment, maintenance. I built Magic Cloud to collapse that loop into something radically simpler — without sacrificing control, security, or performance.

The problem isn’t developers — it’s the system around them

I’ve led and supported teams with real constraints: security reviews, compliance, internal policies, and delivery deadlines that don’t move.

In those environments, most “AI dev tools” feel like good demos but bad foundations. They generate code, sure — but the surrounding system is fragile:

Too many external dependencies
Too many leaky integrations
Too little security built into the core

That’s where Magic Cloud is different. It was built from the inside out for enterprise reality, not just a product launch demo.

What Magic Cloud actually changes

Magic Cloud combines two layers that usually live apart:

Execution — the runtime for your app
Development — the AI-driven creation process

By fusing these, you can generate full-stack apps and AI agents using natural language and deploy them with an enterprise-grade security model built in.

No disconnected toolchains.
No vendor lock-in.
No magic “connectors” that break at the worst time.

A different security philosophy

Most platforms hope security can be added later.

I designed Magic Cloud to treat security as the default, not an optional upgrade. Here are a few core principles:

RBAC at the foundation — not as an afterthought
Tool usage constrained by authenticated user permissions
No MCP protocol — Magic uses a custom tool bridge designed to be safer
No hidden data access — sensitive info leaves only if you explicitly allow it

This isn’t a theoretical posture. It’s practical. It matters.

Performance and control, not just AI novelty

I love fast iterations, but I also care about:

Performance under real load
Long-term maintainability
Stack visibility when things break

Magic Cloud is built on modern C#/.NET Core for performance and stability. It’s open source, self-hostable, and designed for long-term operational control.

I built it for teams like mine

This wasn’t built for hype. It was built because I kept watching teams get buried under their own process. Magic Cloud isn’t a “toy.” It’s a system for teams who want real leverage, without losing their security posture or their autonomy.

Read the original article here.

Magic Cloud has Git Support

Thomas Hansen — Thu, 12 Feb 2026 18:45:09 +0000

Magic Cloud is our flagship product. Being a fairly outspoken guy related to Git, most have believed you can't use Git in Magic.

That's not true. I personally use Git on both Hyperlambda projects, and Magic itself (obviously!) - However, I guess I'm to take some blame here myself, if I'm to be objective about it. I have been known to have one or two controversial opinions ... 😂

Anyways, as of today, Magic has 100% perfectly implemented Git support. In fact, there are as of today 10 new slots related to Git and GitHub, and these are as follows;

[git.clone-repo]
[git.create-repo]
[git.delete-repo]
[git.commit]
[git.push]
[git.checkout]
[git.remote.add]
[github.repo.create]
[github.repo.delete]
[github.repo.list]

Git AI Agent

Not only did we implement Git support, but as a bonus we added it to our AI agent - Allowing you to create branches, push, commit, etc, directly from the integrated AI agent. Below is a video of me demonstrating it.

So starting from today, not only can you use Git directly from Hyperlambda - But you can frikkin' vibe code with it ... 😊