From idea to implementation in 24 hours. Served on localhost.

My brother called on Friday morning. I’ve been busy and rescheduled the conversation. And since my plans went exceptionally well, I reached him back a couple of hours later.

What I heard in the next 30 minutes changed my plans for the rest of the day and upcoming weekend.

And I must confess: I did that. I’ve been vibe-coding for many hours.

And that’s a mix of feelings, yet I can’t say I’m disgusted, and I’m not in love like I used to be. Probably that’s the most beautiful part. It’s just another project. One that is meant to solve specific problems.

But let me tell you everything step by step.

We’ve been discussing opportunities for using AI-generated content for ads. Since my brother has been doing video editing for around 20 years, I knew there would be a moment when he started looking for a way to get into GenAI.

A previously assembled TTS solution was never actually used at full pace, but that was a super-simple setup with Telegram as a UI and n8n as a backend. After all, TTS over an established API is easy.

But this time—oh, this time—we need an entire asset factory. Specific scenes, specific scenarios, specific requirements, and a real-life use case.

After brainstorming our opportunities, I decided: I’m in. And I started thinking about something professionals like him might be missing.

The context of the problem

Many professionals evolve with their tools. Those tools become their bread and butter, and just like we, developers, have a hard time giving up our lovely and cozy IDEs, other professionals might not be eager to trade a tool they’ve known and used for years.

In this case, I mean a non-linear video editor.

I understood immediately: he doesn’t need anything fancy. The closer it is to his existing flow, the better.

Ideally, it should be a plugin. But that might become a non-trivial path. So the most straightforward way to get this thing working is to build a web platform.

A web platform that allows working with prompts, models, and existing assets. Where LLMs and GenAI are the core engines. But the platform must exist around them and become a pipeline and a harness.

This is how aigen-bench started.

The building blocks

The best friend of a data engineer and ML specialist is Python.

I stopped resisting it earlier this year, when I was preparing for the Trading Arena Hackathon by DevClub & Gravity Team. My concern has always been the fact that one missing or additional invisible symbol—a space—can ruin the entire script and bring syntax errors into otherwise fully legit code.

As a guy who’s been using whatever editor was available on whatever server to debug and recover production systems, I had enough problems writing PHP code without assistance. It has semicolons, but at least those are visible.

But hey, I think you know what changed this year.

Code is rarely written manually. Nobody does it. An LLM does it. And validates and fixes it most of the time.

So I don’t care anymore.

If I have to build something long-term, I’ll pick Go, Swift, maybe Node or Rust—depending on the specific needs. But for the prototype? I don’t care anymore.

And Python has tons of code, tons of libraries, and tons of ways to reduce the amount of generated code through reusable components, especially considering the variety of ML tooling available. Working with APIs is also easy and may often end up with using a dedicated library, like I did for Replicate.

So I went with Python, despite having spent maybe slightly over 10 hours in total in my career staring at Python.

But it matters less than ever these days, taking into account my overall experience.

At any point in time, I can dig into any area of the code with LLMs at my fingertips and learn new things. That’s why it makes this thing at least a bit more fun.

Deciding what matters

The project has two main goals:

a) serve as a GenAI platform for the specific project and actually deliver useful results;

b) collect enough data so I can assess whether my approach is good enough to be scaled up and extended to public use.

A quick brainstorm structured this into specific requirements for the first version.

1. I need to collect costs.
2. I need to be able to debug and fix issues if they happen.
3. I need to be able to re-run the creation pipeline.
4. It must be possible to determine the specific input, process, model, and output.
5. Prompts might be reused and slightly changed.
6. GenAI models need English, while the initial input and final output are non-English.
7. It would be nice to be able to trace the full chain of work and repeat it with some adjustments.

Even with this plan in mind, it wasn’t easy to stay on top of it.

Ideas were appearing one after another. Features, improvements, and “oh, this would be nice” moments.

And I decided to take all of these seriously. With cheap and fast execution, that’s not a big deal anymore.

So I kept getting back to the main goal each time and validating: does it stick?

The simplest possible solution

I ended up with a Python app with a loop inside that is able to check upstream and update the process while waiting for results.

I honestly hadn’t planned it. The model included it in the plan. I left it untouched.

Works surprisingly well at this point.

All the files are local, and the database is SQLite. It holds the history and details of the requests and maps produced outcomes and assets back to each request.

Deployment is also simple.

Docker and Docker Compose. Set up in minutes. A zip file with all the content under 50 MB and a local build for a single-container app.

Running on localhost:8321.

What were the trickiest parts?

Precisely two.

First: waiting for the initial bootstrap and the first version of the app to appear. Around an hour with a CLI harness and Markdown docs. Boring, repetitive, yet effective.

The second one was particularly tricky: remotely guiding my brother through what to download, where to click, and which files needed to be copied.

Summary

It is easy to execute. It is fast. It is cheap.

I purposely picked a technology I had never used commercially.

However, none of that cancels out more than a decade of building and debugging software, building platforms, and designing systems for humans.

That is still what matters.

And this is something we don’t have a direct way to teach, learn, or assess.

This is much more than execution.

It’s being human.