Take Five is a game we built at madewithlove. It has seasons, quizzes, leaderboards, sabotages, and a lot of stats. It lives somewhere between pub trivia and internal bragging rights on Slack. It’s competitive, chaotic, but most importantly, it works. People play it. People care about it.

Most of my colleagues are super experienced staff engineers, respected across the industry. I act as the product owner for Take Five, and I’m not a developer. I prototype new features, tweak ideas, and validate game mechanics. I do some redesigns and tweak gaming metrics. Hell, I even managed to set up an OpenAI API integration to generate fake quiz answers based on real answers. All by myself.

Well, not really. I use my Cursor Pro subscription to write new features in the existing, made-by-humans codebase. Not because I think it’s good, but because I think it’s fast. And that’s exactly the part that bothers some of my colleagues.

They review the code, wince a bit, then tell me: we’ll need to refactor this before it can go live. It’s valid. But also, maybe not the point?

Refactoring to me means: this feature is worth keeping.

The code is messy. The product is alive.

There’s a disconnect here.

I’m trying to test whether a sabotage mechanic creates engagement. Whether a new scoring rule makes the game more addictive. Whether the app still feels fun on a Monday morning. I want to experiment directly in the codebase and see features in action. This lets me quickly mock up and discard ideas without disappointing someone who might have spent half a day engineering what initially seemed like a good concept.

Engineers are trying to make sure the code is clean, future-proof, consistent, scalable and maintainable. And most of all: bug-free. (And if possible; well-tested)

Both approaches matter. But in early-stage product work, the emphasis can’t be on code quality alone. That’s like designing the perfect kitchen for a restaurant before tasting the food.

Clean code does not guarantee value. Dirty code does not guarantee failure. What matters is whether the software solves a problem, creates a behaviour or builds a habit.

Founders are already doing this

If you’re a founder building your MVP, chances are high you’re pasting prompts into GPT and wiring together the results with duct tape and Cursor. The code won’t win awards. But it also shouldn’t be exiled. If it helps you validate your idea and attract early users? That’s a win. That’s something to cheer for.

Technical elegance is irrelevant if the product itself lacks purpose. During audits, we’ve seen beautifully structured systems with no traction, and we’ve seen messy ones gaining users by the day. It’s not an excuse to ship garbage. But it is a reason to be strategic about when code quality actually matters.

Engineers should put their energy in understanding how to help these founders with their expertise instead of being annoyed towards crappy-AI code.

AI is the intern. Not the architect.

When I started building functionality myself in Take Five, AI was my prototyping intern. It didn’t know our stack or standards. I never worked with Blade, Tailwind and PHP. But it helped me sketch ideas, ship rough features, and test assumptions. It helped me understand the codebase, also making it easier for me to estimate how complex another feature idea will be.

And once a feature proved valuable? That’s when it should deserve a proper, well-tested implementation. That’s when the intern hands off to the engineer. AI accelerates development but demands human judgment. The key is knowing where that judgment adds value.

The engineering role is evolving

The problem isn’t necessarily the badly written code. The problem is when engineers treat that code as a threat instead of an opportunity. This is where we need a mindset shift. Engineers used to gatekeep what got built. Now, with AI, more people can prototype. That doesn’t make engineers less relevant, it even makes them more important.

They become mentors. Guides. They are the ones who help AI-generated ideas turn into robust products. Just like they do for junior developers who show promising, but not production-ready skills. Junior devs shouldn’t be left alone with production code. But they also shouldn’t be shut out of it. The same goes for founders or non-techies like me “building” with AI.

Don’t mock it. Shape it.

Software creation is becoming more collaborative and asynchronous. AI is just another member of the team. A team that needs proper guidance from a CTO or staff engineer.

That’s the work now. Not to keep the door closed. But to help others walk through it responsibly.