Soulaymane - Passionate Software Engineer and Tech Enthusiast

Everyone’s talking about letting AI write their code and how it made them 10x more productive. Or how they shipped a vibe-coded system, which more often than not causes harm more than it helps. Here’s why I don’t.

Putting the AI in the driver’s seat is a recipe for disaster, the context collapses, you get more hallucinations and mistakes, and it sets you up for a loss of ownership, fast. It gets to a point where you don’t really know your code base and can’t debug it yourself, which in turn hurts your output and confidence when shipping to your end users who, like before, don’t care about how you built it but rather how reliable and trustworthy it is, especially if you are handling their personal and sensitive information.

, AI tools amplify your habits and knowledge, good or bad, present or absent, which means AI is bad at guessing features or design decisions. That is our job as professionals.

For me, AI, at least for the foreseeable future, is a tool that should be treated the way we treated LSPs: use it for precise and scoped tasks triggered by the developer. You direct it like a tool rather than treat it like a teammate.

In my experience, letting the AI go wild in a codebase unsupervised leads to imminent disasters; instead, I get the best results when I use it to fulfil these roles:

When I want to work on a new feature, I figure out myself what I need and how I want to do it, such as adding structured logging that reports to a service like Loki. Then I tell the AI to find me logging libraries for the tech stack I am working in (say NodeJS) and write a report detailing each one it finds: their versions, usage metrics, performance benchmarks, user feedback, and maintainability (when it was last updated and how significant that update was). This saves me time on the mundane task of searching and compiling the information myself, while keeping the important parts of decision-making out of the AI’s hands.
The second use is more hands-on: I direct it into a specific function or module, tell it exactly what change or refactor to make, and more importantly, what not to touch or alter. I do the thinking and planning, it does the labor.
Another use I find helpful, albeit one I reach for rarely, is to ask it questions based on the codebase or tools I am currently operating in, or using it to navigate a new codebase I am not yet familiar with.
During debugging, instead of letting it drive, I mostly bounce ideas off of it after I do the thinking and planning myself. So I end up using it as a refining tool and “a rubber duck” rather than a peer.

These use cases can be summed up into a few things AI is genuinely great at:

Making small compartmentalized changes and committing often.
Executing an implementation after I do the planning.
Bouncing ideas around and aiding in debugging, rather than driving either.

With that, a few rules I adhere to keep things grounded:

Be hyper-specific in your prompts: state the requirements in detail, and provide references to docs or technical details about your stack.
Instruct the AI on what not to do.
Utilize tools like llm.txt or MCPs for up-to-date access to documentation.
Use AGENTS.md (or any adjacent file for your specific tool of choice) to anchor it to the project context.
Provide it with a way to verify its work, such as TDD.
Deny it access to critical systems or sensitive information.

For the foreseeable future, my AI use will be limited to the aforementioned aspects of my day-to-day work, and I will refrain from giving AI the ability to make any architectural decisions or do any of the critical thinking for me, and most definitely will prevent it from accessing any sensitive information or doing any security-related work.

AI in building software systems is still in its infancy, and the landscape is moving fast, so there is much for all of us to learn. If you have any tips or ways you have tried these tools and found useful, feel free to share and discuss them.