Built a project with AI. Software engineering showed up anyway.

You can build a working product in 20 minutes with AI.
That part is real — and pretending otherwise would be dishonest.

What’s less discussed is everything that comes after.

Griffoner started for simple reasons. I wanted a new personal project, just for fun. I wanted to see how far a fully vibe-coded project could actually go with AI — how much could be built, how fast, and with how little direct human effort.

And the further it went, the harder it became to ignore the underlying question: at what point does being a developer stop being necessary? Not just as a job, but as an identity. What happens if the thing that has driven you since you were young — the skills you invested years into, often at the expense of other parts of life — can suddenly be brushed aside?

That question didn’t come from theory. It came from practice.
Over roughly 50 hours, I worked on a complete product using AI across every layer: initial idea, design translation, coding, testing, documentation, assets, wording, and iteration. It shipped. It worked. And it was fast — much faster than a fully manual approach would have been.

But speed turned out to be the least interesting part.

When everything felt possible

The first hours were pure enjoyment.

Designing everything from scratch felt empowering. Game mechanics, UI flows, sound design, feedback loops — everything could be shaped quickly, iterated on, and adjusted almost instantly. Ideas moved from my head to something playable with very little resistance.

AI made the creative loop incredibly tight. I could explore visual directions, tweak interactions, generate sounds, and adjust gameplay without breaking momentum. Nothing felt blocked. Nothing felt heavy.

For a while, it genuinely felt like the ideal way to build. No friction, no long setup phases, no waiting. Just ideas turning into something real, fast.

That phase mattered.

It’s important to say it out loud, because this is exactly what makes vibe coding so attractive. When things are small, when everything fits in your head, and when the system hasn’t started pushing back yet, it feels like you’ve unlocked something fundamentally better.

And for a moment, it really is.

The part that didn’t go as planned

From a game design point of view, the project started with clear and reasonable specs. Core gameplay rules were defined early, along with a small number of game modes. At that stage, the scope felt contained and manageable.

Then AI made progress feel effortless.

Because AI made building fast and experimentation cheap, adding new features quickly started to feel like the natural next step. Variants of the original gameplay, a duel mode, and eventually a Wiki Game powered by semantic neural engines all emerged almost organically. Each idea felt small. Each addition felt justified. I was thinking in terms of product possibilities, not technical cost.

That’s where things slowly drifted.

The speed of AI-assisted development removed friction, and with it, the usual moments where you stop and reconsider architecture. Scope expanded faster than structure. Complexity accumulated quietly, while everything still appeared to work.

Until it didn’t.

Instability started to show up. Bugs became harder to reason about. Changes in one place began breaking unrelated parts of the game. Looking at the code became frustrating: files had grown to thousands of lines, logic was tangled, and understanding the system took more effort than adding yet another feature.

This wasn’t an AI failure — it was an engineering one, accelerated by speed.

That was the point where I had to slow down and step back. Design patterns stopped being optional and became necessary. A full refactor followed: shared logic was extracted, a state machine became the backbone of the game flow, WebSockets were reorganized around explicit states, and unit tests were written to make changes safe again.

Where speed stopped helping

At that point, something became very clear.

AI didn’t remove the need for software engineering — it postponed it. The faster the project moved, the faster structural problems surfaced. What felt like progress at first slowly turned into fragility.

Adding features wasn’t hard. Understanding the system was.

The more the product grew, the more experience became necessary. Not to write code — AI was already good at that — but to recognize patterns, manage state, reason about side effects, and decide when to stop moving fast.

This wasn’t something a non-technical person could realistically navigate. Knowing that something is wrong is not the same as knowing why, and fixing it requires more than generating code. It requires context, mental models, and years of accumulated intuition.

AI made the early phase feel almost frictionless.
It also made the cost of missing structure show up much faster.

This whole thing felt strangely familiar

At some point, this project started to feel less like a side experiment and more like something I had already lived through.

The constant push to add features, the short feedback loops, the pressure to keep moving — it all felt very close to startup MVP culture. Shipping quickly became the default answer. If something could be built fast, it probably should be.

AI amplified that feeling.

Iteration was so cheap that saying “no” started to feel harder than saying “yes.” Each new feature felt justified on its own, but taken together, they slowly pushed the system into a fragile state. The product was moving forward, but the foundation wasn’t keeping up.

This is a pattern most startup teams eventually run into. Speed is rewarded early. Structure is postponed. Technical debt quietly accumulates until it becomes impossible to ignore — usually at the worst possible time.

What changed with AI wasn’t the pattern. It was the timeline.
The same problems appeared, just much sooner.

Building fast felt great.
Living with the consequences felt very familiar.

Conclusion

This project didn’t answer whether developers will be replaced. And I don’t think it was supposed to.

What it did was make something very clear: AI dramatically accelerates the early phases of building. Ideas turn into working software faster than ever. That part is real. But the moment a product grows, the same questions show up — structure, coherence, trade-offs, and technical debt.

If anything, AI makes those questions impossible to avoid.
By removing friction, it brings complexity forward.

The skills that mattered in the end weren’t about writing code faster. They were about knowing when to slow down, when to refactor, when to say no, and how to keep a system understandable as it evolves. Those are not shortcuts you can generate.

I’m more reassured than I was before starting this project — not because I believe software engineering is safe, but because I understand better where its value actually lives. Managing a product, its complexity, and its debt doesn’t disappear when things go faster. It becomes more visible.

AI didn’t remove software engineering from the equation.
It just made it show up sooner.