𝗩𝗶𝗯𝗲 𝗖𝗼𝗱𝗶𝗻𝗴 𝗜𝘀𝗻'𝘁 𝗧𝗵𝗲 𝗣𝗿𝗼𝗯𝗹𝗲𝗺. 𝗡𝗼𝘁 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗧𝗵𝗲 𝗦𝘁𝗮𝗰𝗸 𝗜𝘀.

An AI tool once handed me this config file: DATABASE_URL = "postgresql://admin:SuperSecret123@db.internal:5432/app" API_KEY = "sk-live-4f9a..."

It works. That is the trap. The demo runs and the reviewer nods. But that secret is now in your git history forever. Anyone who enters your repo can see it.

I am not a developer. I spent twenty years in systems engineering. I build the ground where applications run. I build the hosts, the network, and the databases.

When I use AI tools, I do not fail like others. Here is why.

Andrej Karpathy spoke about "vibe coding" for throwaway projects. Some people took this too far. They stopped looking at the code. Now, they stop looking at the system. You can ignore code, but you cannot ignore the system. The system is what actually runs.

I often override AI suggestions because the model lacks operational context:

  • Operating Systems: An AI might suggest Windows for a security app. It ignores the cost of licenses. A free Ubuntu box does the same job cheaper.
  • Databases: An AI might pick MySQL. It does not know which engine I can manage at 2 AM a year from now.
  • Security: An AI stops at "login works." Real security requires conditional access and trusted devices. You do not find that through vibes.
  • Networking: An AI often suggests opening ports to the entire internet. I restrict access to specific management networks.

The AI treats the network as someone else's problem. It does not.

The fix for hardcoded secrets is simple. Use environment variables: import os DATABASE_URL = os.environ["DATABASE_URL"]

The model will inline secrets into your files unless you stop it.

Vibe coders fail because they think application code is the whole system. It is not. The application is just one floor of a building. If you did not pour the foundation, the building will fall.

When I use AI, I do not start with "build me X." That creates demos that break in production. I spend thirty minutes talking through constraints and tradeoffs first. I make the model write a spec based on that logic. This prevents hours of cleanup later.

The problem is not the tool. The problem is making changes without seeing what they touch. If you understand the foundation, the vibes are safe to follow.

De scheidslijn is niet hoeveel code je typt. Het is of je begrijpt waar je code op rust.

Welke override blijf jij maken omdat het model het elke keer fout doet?

Bron: https://dev.to/kkierii/vibe-coding-isnt-the-problem-not-understanding-the-stack-is-4kif

Optionele leercommunity: https://t.me/GyaanSetuAi