DEV Community: Barnabas Olugbogi

We stopped letting the AI write code. We let it write an AST instead.

Barnabas Olugbogi — Wed, 02 Sep 2026 10:38:30 +0000

Every AI coding tool has the same security model, and the model is "a human will read it."

The model writes source code. You skim it. You run it. Your only real defense is code review, and anyone who has reviewed generated code knows attention collapses somewhere around file four.

That works fine when the output is a React component. It works considerably less fine when the output is server-side code with database credentials in scope.

We took a different route, and I want to describe it because the idea generalizes beyond our product.

1. Constrain the output language, not the model

Hyperlambda is an executable AST. The model does not emit source code that we then parse and hope about. It emits nodes in a tree, and the runtime executes that tree directly.

The important property: only whitelisted node types exist.

There is no node that shells out. Not disabled, not sandboxed, not blocked by a policy layer that someone can misconfigure. The operation is absent from the language.

So the classic failure mode, where a model gets talked into generating something destructive, does not have a landing place. You cannot prompt-inject your way into rm -rf when the grammar has no concept of a shell.

2. Why this is different from sandboxing

Sandboxing is subtractive. You start with a general purpose runtime that can do everything, then you spend the rest of your life removing capabilities and patching the ones you missed. Every escape is a thing that was there by default and got overlooked.

Whitelisting is additive. You start with nothing and add operations deliberately. An escape requires a bug in something we explicitly built, not something we forgot to remove.

Both approaches have failure modes. The difference is what a mistake costs you. Forgetting to remove a capability is a breach. Forgetting to add one is a support ticket.

3. The validation step you get for free

Because the output is a tree rather than text, you can inspect it before execution. Not with a regex over source code, which is a losing game, but structurally.

Which nodes does this use. What does it touch. Does it read from a table it has no business reading from.

That check is deterministic and it runs in milliseconds. Try writing the equivalent for arbitrary generated Python.

4. What we built on top of it

The practical result is that you can describe an application in plain English and get a real backend without a review bottleneck. Database over SQLite, MySQL, PostgreSQL or SQL Server. Secured CRUD REST APIs. Auth including Google, GitHub, OAuth and OIDC. SPA hosting. Scheduled tasks.

Generated in minutes, and safe to execute because the language it generates into cannot express the dangerous things.

5. The test

Architectural claims deserve testing rather than trust, so there is a standing bounty for escaping the sandbox. It has not been claimed.

The runtime is MIT licensed if you want to read it or run it yourself: hyperlambda.dev

Happy to argue about the tradeoffs in the comments. The obvious cost of this approach is expressiveness, and I do not think that objection is wrong.

Why Build ChatGPT Apps Without Coding?

Barnabas Olugbogi — Fri, 10 Oct 2025 08:36:39 +0000

Millions search monthly for ways to build ChatGPT apps. Queries on this topic hit 1.5 million globally in 2025. Development overwhelms non-coders. Time drags. Costs mount. Engagement stays low. Ainiro.io offers an open-source generator. You create ChatGPT apps from prompts.

Understand Building ChatGPT Apps
ChatGPT apps add GUIs to AI chats. Users want forms and buttons. Coders spend weeks on SDKs. Bugs persist. Updates break tools. Access widens. Innovation stalls without skills.

2025 Statistics Show the Scale
ChatGPT reaches 800 million weekly users. 700 million send 18 billion messages weekly. No-code platforms build 65% of apps. Low-code market hits $101.7 billion by 2030. No-code cuts time 90%. Costs drop 65%. ROI reaches 362%. 70% of new apps use no-code.

Real Examples from 2025
Domino’s builds AI chatbots for orders with no-code tools. Process simplifies. Engagement rises 25%. United Airlines deploys GenAI for notices. Satisfaction grows 6%. Motel Rocks handles queries at peaks. Brand consistency holds. Resolutions speed up 40%.

Impacts on Your Business
Coding delays launch 90%. ** **Costs exceed $50,000 per app. Teams overload. Market share slips 25%. You miss 800 million ChatGPT users.

Traditional Fixes and Their Limits
Learn SDKs. Write code. Debug weeks. Tutorials cost time. Updates fail. Skills gap widens.

No-Code Tools Change the Game
Build without developers. Platforms generate from prompts. Automate GUIs. Ainiro.io leads. Magic Cloud creates ChatGPT apps fast.

Ainiro.io Features for Building ChatGPT Apps
Ainiro.io generates forms from prompts. Apps include HTML and APIs. Integrate databases. Edit in Hyper IDE. Open-source adds flexibility. Deploy to ChatGPT.

Case studies show speed. Domino’s cuts build time with similar no-code. United scales agents.

Steps to Build ChatGPT Apps with Ainiro.io

Sign up at ainiro.io. Start free trial.
Prompt generator. Say: “Build contact form for emails.”
Generate app. Get code in minutes.
Test GUI. Fix issues.
Integrate database. Add CRUD.
Deploy to ChatGPT. Use unique IDs.
Monitor engagement. Track user interactions.

Find more information here => https://ainiro.io/blog/open-source-chatgpt-app-generator

You create 50 apps daily. Costs fall 40%.

Launch ChatGPT apps. Visit ainiro.io. Prompt your first app.

Am I just coding or solving problems?

Barnabas Olugbogi — Sun, 22 Sep 2024 09:44:12 +0000

An Interesting point to kickstart this conversation would be a recent happen at Codesmith — a programming school from where a graduate secured a role that required someone who understood how to activate mass audiences.

So, what more delightful match than an engineer who mastered the art of connecting mass audiences with stories and products.

Yes, you could have been amazed at this kind of shocking reality where you learn how to use a tool but end up getting hired, not because of how well you know this tool but how well you can use it to solve problems.

Solving problems should be the priority of developers while learning how to use a tool like Javascript or React.

We should use tools to solve problems and not the other way round.

A problem statement from Mr Garter could be:

“Our business is a fast paced one where customers come to our shops to buy food and drinks but due to a shortage of workers, we created a web app for customers to place order online while the orders are being attended to.

This app lags during weekend when a lot of customers make their orders, how can we achieve a fast and seamless experience for our customers?”

The problem here is not testing how well you know Javascript or any of its framework.

It is testing your problem solving ability with the knowledge of what you know.

Now let’s spot the possiblities for this lag:

1. Shipping too much Javascript to the user in form of expensive Javascript heavy animations.

2. Using Javascript in place of CSS.

3. Unoptimised Images and Font files.

5. Not prioritising the most important web pages and trying to load every page at once.

6. Poor Content Delivery Network, Web Hosting and many more.

As a developer, you will have to sit and find out what the problem is and proffer optimal solution to it.

My Optimal Solution:

If after fixing the bottlenecks above, you cannot still find a solution.

A Progressive web app would be a temporary solution while you envisage building a mobile app for the business.
Thank you for reading!