Don't let AI think for you

This week, while talking with friends in the industry, I found myself thinking about how easy it is these days to hand over your thinking and judgement to AI without even realising it. That raised a question: if you stop practising certain skills, how will you keep improving, or at least avoid getting worse?

In fact, this happened to me over the past few days while working on a few projects with OpenAI’s new model, GPT-6 Astra, which came out last Thursday.

My first idea was to recreate a retro game from 1988 that I know my dad used to enjoy and hasn’t had a chance to play again since. Since it was a fairly simple project for personal use, I decided to try vibe coding: asking AI to build it without going into too much technical or architectural detail. I only asked it to use Three.js and keep the game engine logic separate from the rendering. And it pretty much built the whole thing with a single prompt.

The game is relatively simple: you claim parts of the screen while dodging enemies… and this is where I realised that AI had made many of the design and architecture decisions without my input: how the enemies move, their speed, the algorithm for expanding your territory…

I tried the prototype in the browser and, after a few prompts to fine-tune the details, it looked pretty good. But something was missing when I played it, so I gave it another prompt: “Add retro 8-bit music.” Just like that, it had a soundtrack. My musical contribution had been typing a sentence 😂.

And so, after a few prompts, I stopped to think. What have I actually done here? What have I learned from this?

On the one hand, I’d acted as a “Product Manager” by deciding on some of the features the game needed. But in this case, I hadn’t acted as a “Product Engineer”, because I’d delegated everything to AI.

In other words, I’d made some decisions about what the game should include, but I’d barely thought about how it should be built.

What’s the problem here? A few months ago, I would have followed a different process: researching how WebGPU/Three.js works, trying it out, understanding how music is generated and sent to the synthesiser… And as you can see, what matters here isn’t the programming itself, but the mental process of research, decision-making and design.

Of course, vibe coding a prototype is enough to test an idea. To take it into production, I’d need to review the design, architecture, tests… in other words, understand it.

My conclusion is that what matters is being aware of what you delegate to AI and which skills you want to keep developing yourself.

That’s why, in this newsletter, I’d like to suggest two things to try:

• Choose a part of a system or project that you want to understand and ask AI to walk you through its architecture and design.
• Think of a system or feature you want to design and work it out “on paper”. Then ask AI to evaluate it, offer suggestions or explore alternatives, and write a second version of the plan yourself. Finally, let AI implement it however it likes within the boundaries of your design.

I haven’t analysed the quality of the generated code in this post. That’s a topic for another weekly newsletter, where we’ll look at the difference between vibe coding and agentic engineering, which is closer to the exercises I’ve suggested here.

If you found this article interesting, I encourage you to subscribe to the newsletter: in future editions, we’ll keep exploring how to use agentic AI to bring services into production with confidence.