Forem: Thomas Hansen

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 ... 😊

Open Source Vibe Coding tool for Citizen

Thomas Hansen — Tue, 10 Feb 2026 15:38:22 +0000

Magic Cloud is an open source framework, you can run on your own development machine. Kind of like Lovable, only better! With zero lock-in of course! You can basically host it where ever you wish!

The only thing that's proprietary, requiring a key, is access to the Hyperlambda Generator, which is my own LLM that's capable of generating Hyperlambda code automatically.

That makes it arguably the sole solution on earth in this space, that's "enterprise ready", as in secure, cares about privacy, while at the same time making it possible to generate entire CRM systems, full stack apps, databases, APIs, and everything required for the typical Enterprise customer!

You can connect it to SQL Server, PostgreSQL, MySQL, or SQLite, in addition to that it can be integrated into everything else you've got from before, through APIs (that you vibe code), or "whatever".

Anyways, that was it! All I had to say!! 😊

Getting Started with Open Source Vibe Coding

Thomas Hansen — Sat, 07 Feb 2026 13:38:54 +0000

Magic Cloud is 100% open source. In addition, people keeps on telling me it's "better" than Lovable and Bolt42. I wouldn't know since I barely use these tools, but I know what it can do, and what it can do, easily saves me for 90% of my time!

In the above video I demonstrate the entire process of getting started with Magic. Below are its Docker Compose file if you want to reproduce what I did.

services:
  backend:
    image: servergardens/magic-backend:latest
    container_name: magic_backend
    restart: always
    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
    depends_on:
      - backend
    restart: always
    ports:
      - "5555:80"
volumes:
  magic_files_etc:
  magic_files_data:
  magic_files_config:
  magic_files_modules:

Save the above as "docker-compose.yaml" somewhere, run docker compose up, and you're vibe coding on your own development machine, using nothing but open source software.

The last AI agent on Earth

In a way, Magic Cloud becomes "the last AI agent you'll ever need". This is because of its Hyperlambda programming language, that allows for dynamically generate tools on demand, and immediately use these tools to perform some task.

No deployments, no compilations, no "setting up sandbox environment" wait screens - Still, the thing is 100% secure by default!

What can you create?

The above just creates a simple TODO app, but at least in theory, you can create anything you can create with Lovable and Bolt42, except everything is open source of course!

I've used it to create complex CRM systems with RLS and business logic. I've used it to create task management systems, with Kanban boards, and RBAC. I've used it to create rich back office apps, with integrated SSO and OIDC. And everything "just works."

Bugs

Vibe coding is still a new phenomenon, and the process generates bugs every now and then - So you must sanity check the code output before trusting it.

Just a friendly warning ...

Getting started

You can find the repo here.

Vibe code full-stack apps using AI (and keep it open source)

Thomas Hansen — Thu, 05 Feb 2026 12:54:52 +0000

If you build software with tools like Lovable or Bolt44, you’re usually making a trade-off: speed and convenience in exchange for privacy, security, and control.

For hobby projects, that might be fine. For real businesses and enterprise use, it usually isn’t. That’s exactly why I built Magic Cloud. Magic Cloud is:

Open source
Self-hostable (Docker makes it easy to deploy anywhere)
Built around a purpose-made DSL instead of raw chat-generated code

Rather than asking a general-purpose LLM to spit out Python or C#, I designed a system where the model generates code in a language that was explicitly built to be generated by AI.

Hyperlambda and why security actually works

The DSL at the core of Magic Cloud is called Hyperlambda.

Hyperlambda wasn’t designed for humans first — it was designed for machines. That single design decision changes everything.

Most criticism of vibe coding eventually boils down to one word:

Security

Hyperlambda makes insecure code hard to express by design.

Some of the security properties baked into the runtime:

Code executes inside a sandboxed virtual file system
No access to files outside the sandbox
Role-based access control (RBAC) for users and agents
Function-level whitelisting so only explicitly allowed operations can run
Secure defaults for things like password storage (per-record salts + slow hashing)

Instead of trying to “audit AI output after the fact”, the system itself prevents entire classes of vulnerabilities from ever being generated.

Token count matters more than people realize

Token usage isn’t just about API cost.

Lower token usage also means:

less cognitive load on the model
more consistent output
fewer hallucinations
the ability to generate larger and more complex applications

Hyperlambda is extremely compact:

~10% of the tokens required by C#
~20% of the tokens required by Python

In practice, that means an agent can build 5–10× more complex systems before hitting practical context limits.

Hyperlambda also happens to be very AI-friendly:

homoiconic / AST-like structure
declarative style (closer to SQL than OOP)
no classes or inheritance — just functions and files

This dramatically simplifies generation.

Performance (and why most DSLs fail)

Most DSLs fall into one of three traps:

Too narrow to be useful
Too slow to be practical
Just glorified configuration formats (XML/JSON hell)

Hyperlambda avoids all three. In benchmarks, it’s roughly 20× faster than Python on average. When you combine that with:

sandboxed execution
low token usage
zero compile step

You end up with a system that’s not only secure, but fast enough to run AI-driven logic in real production workloads. Based on those measurements, Magic Cloud ends up roughly two orders of magnitude more efficient than typical LangChain-style stacks.

The real win: convenience without compromise

Security and performance matter — but the biggest advantage is still convenience. Magic Cloud can generate:

the database
the API
the frontend

And when generation is done, the app is already live. There’s no separate “dev environment” versus “deployment environment”. No build pipelines to babysit. No fragile glue code between tools. You iterate directly against the same runtime that serves production traffic. That tight feedback loop makes a huge difference when you’re steering an LLM interactively.

Open source and self-hosted by default

With most closed vibe-coding platforms, you eventually hit the same wall:

unclear data handling
restrictive terms
no real control
“please don’t paste sensitive data” disclaimers

Magic Cloud runs entirely on your infrastructure if you want it to. Private server. Air-gapped network. Internal business systems. Because it’s open source and extensible, it works just as well for:

CRMs
internal admin tools
project management systems
back-office software
custom business workflows

Why I demo it with a CRM

One of my demos shows Magic Cloud building a CRM system with:

companies
contacts
leads
notes
activities
email sending
JWT authentication
RBAC security

CRMs are the perfect vibe-coding target.

Off-the-shelf CRMs try to serve everyone, which usually means they fit no one particularly well. Your actual business workflows are always a little different. A custom CRM doesn’t need 10,000 features — it needs the right ones. And only you really know what those are.

Final thoughts

If you want to vibe code full-stack applications without sacrificing security or ownership, the ingredients matter:

Open source
Self-hosting
A DSL designed for AI generation
Sandboxing, RBAC, and constrained execution
A single loop where build, test, and deploy are effectively the same thing

That’s the problem Magic Cloud is built to solve. If you want the original article, you can find it below.

Vibe coding full stack apps

I just MURDERED Software Development, and I'm not sorry!

Thomas Hansen — Sun, 01 Feb 2026 10:55:48 +0000

For 20+, I've felt that dev heads was "the new priesthood", with their design patterns, acronyms, and theories about abstractions and IoC, holding on to their knowledge as if it was Christian Dogma from "The Witch Hammer"! And for 20+ years, I've done what I can to eliminate these people's "power grabs" on others.

Today, I'm putting the finishing touches on Magic Cloud, with the intentions being to publicly humiliate 45 million software developers, making them realise that they were wrong all the time, by releasing an AI agent that arguably builds better software than 99% of all dev heads!

Zero unit testing, no Git or versioning, just good ol' "saving AI generated code straight to production"!

Do you believe I'm joking? Well, watch this video to understand that I am 100% perfectly serious!

The "code"

Basically, I told it to ...

Create me a CRM system to manage tasks for my outsourcing company

10 minutes later, the finished result, including RBAC, bcrypt-hashed passwords at rest, and a security model that would make the NSA blush.

Hyperlambda, a Web Query Language

Thomas Hansen — Fri, 05 Dec 2025 08:38:04 +0000

We've just launched a new addition to Magic, which is our Natural Language API. The thing is built upon Hyperlambda, so it's "a bajillion" times faster than anything similar built in Python, and a code-gen request probably costs less than 1 cent. In fact, the average request executes in 1 to 4 seconds, allowing you to literally create API methods "on the fly", which again allows you to treat the web as a "queryable database". Examples of things you can ask it are ...

"Scrape ainiro.io and return the first 5 hyperlinks you find"
"Return all links from the sitemap at ainiro.io NOT containing /blog/"
"Invoke Chuck Norris API and return some random joke"
"Invoke Chuck Norris API and return some random joke"

To understand, consider the following request; "Scrape ainiro.io and return the first 5 external Hyperlinks you find" - Which results in the following JSON being returned.

[
  "https://seattleballooning.com",
  "https://github.com/polterguy/magic",
  "https://docs.ainiro.io/",
  "https://www.2xplain.nl/",
  "https://app.fintell.ai"
]

Instant API

Due to its speed, you can literally depend upon it dynamically generating your code on the fly, by semantically scraping web pages for information. In the following video I'm walking you through parts of its implementation.

Implementation

The way it works, is as follows.

A natural language request comes to the server
Magic checks its database to see if it's previously succeeded in generating code for the request
If it finds cached code, it executes the code and returns the result of the execution
If it does not find a cached result, it generates the code, stores it in its cache, executes it, and return its response

This means that on the first invocation it takes between 1 to 4 seconds to generate the specified code. Consecutive requests executes in 150ms, implying it's faster than Python. In fact, it's got roughly 10 better performance and throughput than Python according to tests we've conducted previously.

Wrapping up

If you want to play with this, you can clone Magic, install the "natural-language-api" plugin, and test it from Hyper IDE. If this is too much hassle, you can also purchase a cloudlet from us.

Hyperlambda is 17 times faster than Python with Flask

Thomas Hansen — Mon, 24 Nov 2025 07:35:19 +0000

I just measured the performance of Python with Flask, and compared it towards Magic with Hyperlambda, and the results should shock you. Hyperlambda and Magic is on average 17 times faster than Flask. I did the same test where I measure Fast API versus Hyperlambda, except of course I used Flask instead of Fast API, and the results was as follows.

Flask executed between 2,324 and 3,616 HTTP requests, an average of 4,778
Hyperlambda executed between 78,000 and 83,361 requests, an average of 80,680

The test creates 50 async tasks or threads, and basically just hammers a CRUD read endpoint that's returning Artist items from my chinook database. The database was copied and pasted from the Hyperlambda solution, so it's the exact same database. The machine is the same, a MacBook Pro M3, and you can find the code below if you wish to reproduce what I did.

Code

To test you can use the code from my Fast API article, but instead of creating a Fast API endpoint you use the following code.

from flask import Flask, jsonify
import sqlite3

app = Flask(__name__)

# Helper function to query SQLite
def get_all_artists():
    conn = sqlite3.connect("Chinook.db")
    conn.row_factory = sqlite3.Row   # Enables dict-like rows
    cursor = conn.cursor()

    cursor.execute("SELECT ArtistId, Name FROM Artist")
    rows = cursor.fetchall()

    conn.close()

    return [dict(row) for row in rows]


@app.route("/artists", methods=["GET"])
def artists():
    return jsonify(get_all_artists())


if __name__ == "__main__":
    app.run(debug=False, port=5001)

The above is a standard solution returning database items using Flask. In case you don't want to check out my previous blog, you can find the "stress testing" code below.

import asyncio
import aiohttp
import time

URL = "http://127.0.0.1:5001/artists"
#URL = "http://127.0.0.1:5000/magic/modules/chinook/artist"

async def worker(session, stop_time, counters):
    while time.time() < stop_time:
        try:
            async with session.get(URL) as resp:
                if resp.status == 200:
                    counters["ok"] += 1
                else:
                    counters["fail"] += 1
        except Exception:
            counters["fail"] += 1

async def main():
    duration = 30  # seconds
    concurrency = 50  # number of parallel workers

    counters = {"ok": 0, "fail": 0}
    stop_time = time.time() + duration

    async with aiohttp.ClientSession() as session:
        tasks = [
            worker(session, stop_time, counters)
            for _ in range(concurrency)
        ]
        await asyncio.gather(*tasks)

    total = counters["ok"] + counters["fail"]
    print(f"Requests sent: {total}")
    print(f"Successful:     {counters['ok']}")
    print(f"Failed:         {counters['fail']}")
    print(f"Req/sec:        {total / duration}")

if __name__ == "__main__":
    asyncio.run(main())

To test the Hyperlambda endpoint, change the URL variable you're using, run the test 3 times towards each endpoint, and calculate the average of each run. This should give you a representative average value for each example. To generate the Hyperlambda code, I simply used the CRUD generator to wrap my chinook database. Remember to turn off authorisation requirements before generating your CRUD endpoints to get the equivalent code, and make sure you either pass in limit=1 as a query paremeter to the endpoint, or edit the endpoint manually to return all records. Otherwise the Hyperlambda code will only return 25 items.

Interestingly, Flask seems to be able to accept more throughput than Fast API, but it of course becomes equivalent to "nothing" compared to the amount of throughput Hyperlambda can deal with.

Wrapping up

A Volkswagen Beetle can probably do 120KM per hour. Multiplying that number by 17, and you get 2,040KM per hour. That's about the same as the maximum speed of a modern fighter jet. Implying ...

Hyperlambda versus Python and Flask, is like trying to race a fighter jet with a Volkswagen

As in, yes, the performance difference between Flask and Hyperlambda is the same as the performance difference between a 20 year old Volkswagen and a modern fighter jet!