Own Your Codebase or It Will Own You

Someone needs to speak about the elephant in the room, The $61 billion technical debt crisis.

Even though the AI didn't bring that elephant, it's definitely feeding it protein bars.

Here is the common narrative: Companies rushed to adopt AI coding tools, focusing 100% on speed, and speed they got.

That's understandable from a business point of view, seeing the potential of added value that AI can bring. Also, companies have the impression that that's what needs to be done, or else they will be left behind.

But there is a potential issue when adopting AI: it can be disastrous if it's not done correctly or safely, let's say.

Speed without understanding creates what we call now "slop code", code that works, passes tests, and looks reasonable in the pull requests. But it accumulates merge after merge, small chunks of code that slip in hidden underneath hundreds of lines of code logic.

Then one day you open a file, maybe you want to refactor something, and you look at it like, "What is this junk?" The file looks so ugly u almost feel sorry for it.

The problem is not the AI, its the illusion.

Ai generated code looks clean in isolation. But the reality is it lives in a system with hundreds of interconnected files, business rules, and requirements that can change every 2 to 4 weeks.

And after 6 months, you need to change something fundamental, and u wake up to the fact that no one in the team understands 100% what's really going on in the codebase.

Recent industry analysis found that ai-generated code requires nearly double the fixes and reverts compared to human-written code. One in five security teams reported production incidents from AI code that slipped through review.

The issue isn't whether AI can write code.

It's whether anyone can maintain it and how much it can cost if we need to keep it running or scale it.

At Tinkerview, we use AI differently.

We use it as it is: a tool, not a founding member or a CTO. We use it to handle boilerplate code and repetitive tasks.

Before we discuss our approach in Tinkerview, let me clarify that we have tried AI driven developpement for our internal toolings.

And before I hear someone saying, "It's a skill issue, bro," first, I'm not your bro. Second, we tried many AI techniques: MD features structuring, using Skills, MCP, BMAD method. And no matter what we did, slop content was inevitable.

The phase will often be like this if we tackle new features: We discuss the approach with LLM, we provide our approach for logic, and let LLM try to poke holes in it.

We discuss solutions; we can even let LLMs suggest some code snippets in MD files, but not a full solution or other format. However, we don't let it alter the code base.

Once we are set on the approach, we start implementing the solution manually, and we build it block by block, old school. Of course, to speed up the process, we can use Copilot or Avante in nvim for my case.

We check the logic, we add parts of the code we like manually, and we alter parts we don't like. Our developers check if it fits well in the current code base, and this way, they own their code base. Also, they learn, gain experience, and progress.

We are not against using AI, but we know its limitations and the cost of its misuse. And in a world where noise and slop keep growing every day, we choose to be on the right side of the story.

We want to take responsibility and choose to build products and ship code in a way we are proud to do.