Rise of the planet of the AI'pes

For a while, I was lucky enough to be surrounded by:

• Open-minded developers who were not stubborn and were willing to unleash the power of AI in their work, and
• Technically aware product and business people who experimented with AI, but understood that AI-generated solutions were by no means production-ready.

I was naive enough to think this was the norm across the industry.

LLMs go beyond code generation, and everyone goes bananas

That assumption was challenged when I embarked on a new project, where I was the first technical lead with substantial real-world industry experience. It was also around the time LLMs started moving beyond code generation and into business applications.

Tools like Claude Design emerged, and suddenly non-technical consumers started building applications without any clue about the underlying technology. The more non-technical people joined the project, the more amazement and hype around AI there seemed to be. It began to feel cult-like.

Part of me was happy for them, because technically, we could iterate on the product faster. But another part of me felt left out, as I was being misunderstood as a stubborn, old-generation developer simply for not hyping it up:

“Just because I’m not running around like an ape who has just discovered fire doesn’t mean I’m not cooking.”

Teach a man to fish. Prompting is not understanding

The whole cult-like AI worship wouldn’t have been a problem. Let people have fun! We all love building things. But eventually, their prompt-born “solution” ended up on my desk, and it became increasingly difficult to explain why it wasn’t production-ready, scalable, or maintainable.

I am a fan of the “teach a man to fish” philosophy. So, I tried to teach the non-technical people to ask themselves a simple question: “How do you know this solution is any good? How do you know it’s actually working as expected?” Also, I was a bit tired of hearing that AI would make us grow faster, with no measurable proof behind it.

In software development, you’d justify that with tests, a well-defined architecture, and coding conventions. All of these help you, as a developer, understand the solution and assess its quality.

Even if the solution consists of aggregated data charts, you can assess its correctness by examining the formulas used to generate the data. Obviously, it would not prove that the results are correct, but at least one could follow the logic behind them.

I was hoping for a response like “Well, I’ve checked the formulas, and they’re correct.”

Unsurprisingly, my approach was not well received. Some took it as an insult, and others simply didn’t understand the point I was trying to make.

How to know what they don’t know

My bad! I pushed too hard. Let’s meet in the middle.

So, for the next attempt, I asked for the solution to be built using our company’s tech stack and provided guidelines on how to structure it. At least this way, I could give constructive feedback and back up my claims with concrete examples and comparisons.

A weekend later, the solution was built, and I looked under the hood. It was still a mess. It was better than the previous one, but I still wouldn’t merge it into the main branch.

I knew it would be humanly impossible for me to describe engineering culture and processes in a way that would make sense to someone who has never experienced it. And even if I could, it would end up being used as a prompt on the other side without getting the full picture (missing the “understanding” part).

So I suggested that the person join the engineering team for a week or two, just to understand the processes of good engineering. After all, they had already put a lot of effort into the prompt, and it was emphasized a lot that a huge amount of time was spent on priming and describing the requirements.

That’s when I realized something…

The feature development cycle hasn’t changed

From a product perspective, it makes little difference whether a feature is built by a team of developers or by AI. Someone still is writing big ass documentation of a feature beforehand.

Let’s say a product person named Bob needs a clickable button.

Previously: Bob writes a feature request and hands it to the development team. Two weeks later, the feature is delivered. Bob is happy. The button works as expected.

Nowadays: Bob writes a prompt, and AI generates the feature in minutes. Bob is amazed. The button works as expected, and no development team was needed to produce it.

So far, so good.

And this is where the Rise of the Planet of the AI’pes begins -> Bob tells the board he can deliver features in minutes without a team of developers. The board is skeptical, so they try it themselves. And guess what? They also manage to build the button.

They’re convinced. Suddenly, it seems that anyone can build software without technical knowledge.

But only developers can see that the code is shit. So why is that?

Why do only developers see it?

The image below is a popular example from 2021 (before raise of the AI) of how product people are often perceived as struggling to come up with clear requirements, while developers fill in the gaps, address edge cases, and make sure the solution is production-ready.

Product people never saw how the solutions were built, so now they don’t know what to actually ask for.

And since the AI is built to follow instructions, try to please the prompter, and burn as many tokens as possible, it is highly unlikely that together they will be able to build a solution that is production-ready, scalable, and maintainable.

I believe devs (including myself) are partially to blame for this. We have been filling the gaps and making things work instead of bringing these issues back to the product people. Because of the “time constraints”, you know… ;)

On the other side of the coin, product people haven’t always bothered to understand what happens under the hood.

So, who’s the ape now?

That’s more of a rhetorical question. But I’m glad I found where the gap is, and why someone may think their solution is amazing and working, while in reality it only works for this particular prompt and will belly-flop on the next feature.

Play with the fire, but don’t get burned

Use AI as a productivity tool, not as a solution generator. Let it handle the tedious stuff, speed up your workflow, and help you explore ideas. But don’t offload the responsibility of understanding the solution to AI.

And if you do use it to build entire solutions, that’s fine too. Just bear in mind that the next generation of AI might not need a prompter either.

On the other hand, if you refuse to use AI altogether, you’ll eventually lose the velocity race. Even if you type at 210 words per minute, a developer who knows how to manipulate the Copilot (auto-completer) will still be faster than you.

The fire of AI is impressive. Knowing how to cook is still a different skill.