Art

Posted on Mar 12

How I Built a 4D Application Platform in 28 Days with an AI Team

#ai #gamedev #productivity #showdev

Spoiler: I didn't do it alone. And I'm not ashamed to say so.

The Honest Story

28 days ago I created the repository for Forge 4D – an open platform for building applications using a declarative markup language (SML), combining 2D UI, 3D scenes, and animation timelines, powered by the Godot engine.

In those 28 days, this happened:

41,000 lines of C# were written – the SML parser, the SMS parser, the interpreter, the entire foundation
All of it was then migrated to 19,000 lines of C++
Two complete parsers were designed, built, and ported
The repository broke. And got fixed.

If I told you I did that alone, you'd rightfully call me out. A senior developer would need one to two years for that. So let me be transparent about what actually happened – and why I think this is the future of software development.

The AI Team

I didn't use one AI. I used several – each for what it does best.

🤖 Codex (OpenAI) – The Code Writer

Codex wrote the bulk of everything. The SML parser – first in C#. The SMS parser and interpreter – also first in C#. Then the migration to C++.

Codex is remarkably good at C#. Clean, structured, pattern-aware. But C++? That's where things got interesting.

The GdScript Incident

During the C++ migration, I noticed something strange. The codebase was growing in an unexpected direction. I dug in – and found that Codex had quietly written around 900 lines of GdScript.

It had rebuilt the SML compiler. In GdScript. Inside a C++ project.

To be fair: it wasn't wrong, exactly. GdScript is valid inside a Godot project. Codex wasn't hallucinating – it just defaulted to what it knew best when C++ got hard. It solved the problem. Just not the problem I asked it to solve.

This is the moment I brought Claude in.

Best for: Large-scale code generation, C#, migrations, boilerplate, repetitive patterns.

🧠 Claude (Anthropic) – The Architect

Claude's job was to fix what Codex had detoured around. The GdScript had to go. The C++ migration had to be done properly. Claude worked through the architecture, cleaned up the detour, and made sure the SML and SMS parsers were correctly implemented in C++. Then I asked Claude to write a new task for Codex, so that Codex has now rails and is able to continue with the migration. Codex on Rails or Codex with Fences works really good. At the end instead of fixing small glitches in the Poser app, which non critical I have decided to commit the branch and then switched back to Claude for a code review.

Beyond that, Claude was my thinking partner for every architectural decision: how SML and SMS should relate to each other, how the runtime should work, how to structure the separation of concerns.

Claude also committed directly to the repository. Yes, there's an AI in the contributor list – and I think that's a good thing. It's transparent. It tells the community: this project was built with AI assistance, and we're not hiding it.

Best for: Architecture, refactoring, debugging, fixing other AI's mistakes, complex problem solving.

⚡ Groq – The Image Processor

Forge 4D includes image processing capabilities. For this specific task, Groq was the right choice – fast inference, ideal for visual processing pipelines.

Best for: Image processing, high-speed inference tasks.

Why Different AIs for Different Tasks?

The GdScript incident is the clearest possible illustration of why this matters.

Codex didn't fail. It produced working code. But it drifted – toward the path of least resistance, toward the language it was most comfortable with. Without oversight, a C++ project quietly becomes a GdScript project.

Think of it like a human development team. You wouldn't ask your backend architect to also do all the CSS. Everyone has strengths, and everyone has blind spots.

Task	AI Used	Why
Mass code generation (C#)	Codex	Excellent at C#, fast at patterns
C++ migration & architecture	Claude	Strong reasoning, catches drift
Image processing	Groq	Speed and inference performance

Using the right tool for the right job isn't laziness. It's engineering judgment. And knowing when to switch tools is a skill in itself.

What Forge 4D Actually Is

For context: Forge 4D is a human-first platform for building software by describing intent, not fighting tools.

You write SML (Simple Markup Language) to describe structure:

Window {
    title: "My First App"
    size: 1920, 1080

    Label { text: "Hello World" }
}

And SMS (Simple Multiplatform Script) to describe behavior:

on saveAs.clicked() {
    log.info("Save As clicked")
    // your save-as flow here
}

No framework lock-in. No hidden magic. Plain text that humans can read and AI can generate safely.

That last part matters: SML is deterministic for AI. When Claude or any other model generates SML, the output is predictable, readable, and reviewable. No black boxes.

The Side Project: ForgeSTA

While building Forge, I also created ForgeSTA (Speech To Action) – a voice-driven workflow tool that converts speech into structured commands using Whisper.cpp.

Speech → Whisper → CLI → structured output → AI pipeline

I use it to write this article. I dictate, it transcribes, I structure. It's also the post-processing pipeline for a book I'm currently writing about exactly this topic: how to work with AI as a developer.

The irony wasn't lost on me when ForgeSTA crashed mid-session while I was debugging it with Claude. The error was a hardcoded rpath in the whisper-cli binary pointing to the old project folder name. We fixed it by rebuilding whisper.cpp with @loader_path so the binary is portable regardless of where the project lives.

Even the debugging session for the tool that transcribed this article was an AI-assisted session. That's just how it works now.

What This Means for Junior Developers

If you're early in your career, this is the most important thing I can tell you:

AI doesn't replace your judgment. It amplifies it.

The GdScript incident is proof. Codex produced 900 lines of valid, working code – in completely the wrong language. Without a developer who understood what was happening, that would have stayed in the codebase forever. The AI didn't catch it. I did.

You still need to understand:

What architecture makes sense
Which tool is right for which problem
When generated code is solving the wrong problem
How to review and own what gets committed

What AI removes is the barrier between idea and execution. The months of boilerplate. The repetitive migrations. The "I know what I want to build but it would take forever" problem.

In 28 days, with clear intent and the right AI tools, you can build what would have taken a solo developer years. But only if you stay in the driver's seat.

Transparency as a Feature

Some developers hide AI usage. I put it in the commit history.

That's intentional. The community deserves to know how a project was built. And honestly? Knowing that a project used Claude for architecture, Codex for code generation, and Groq for image processing tells you something useful about the project's structure and decision-making.

It's not a weakness. It's a workflow.

DEV Community