“Never outsource understanding to prompts. Use AI to sharpen your thinking.”

There’s a growing narrative in dev: “Describe the app. Let AI generate the code. Ship it.” It’s fast. It’s impressive. But if you’ve ever operated systems handling money, data, or risk, you know what’s missing: Control.

I’ve worked in a few start-ups as app developer and tech lead. Last year, I began developing a new concept. PyLog is an app that reads firewall and system events, filters out the noise, and feeds events to a cybersecurity-trained AI. The personal challenge is that I’m an army of one. Writing the Python code was reasonable, but getting into machine learning and training an LLM was new territory.

I had played around with ChatGPT but found that the app had limited understanding of security. Enter the concept of ‘vibe coding’:

Prompt → Generate → Accept.

It’s fast until something breaks in production, and you don’t know why. This was never going to work for me. So, I had to adapt to the AI being my partner or buddy.

Buddy-coding is a human-in-the-loop AI development workflow where the engineer maintains architectural control while treating AI as a peer collaborator rather than an autonomous agent. The workflow works like this:

1. Define the problem and architecture (Human)

2. Write a small, controlled piece of code (Human)

3. Run and test locally (Human)

4. Ask the AI for input on edge case, performance and alternatives: “What edge cases am I missing?” or “How would you evaluate this?” (AI)

5. Refine the implementation (Human)

6. Commit to Git (Human)

In cybersecurity and infrastructure, blind trust isn’t a strategy. By keeping the “human in the loop,” I’m not just getting working code, I’m getting understood code. (Tip: Proton’s Lumo is great at commenting code, something I’m bad at.)

The result is fewer hidden dependencies, better mental models, and actual learning. AI becomes a multiplier, not a crutch. AI isn’t going away, but we do have a choice:

Outsource our understanding or use it to sharpen our thinking.

I’m choosing the latter.

A friend suggested that the “the amount of vibe coding in a system should be inversely proportional to the importance of that system. For example, if I building a quick-and-dirty tool that I want to use, I don’t care how the code is written. However, if I’m going to try build a Linux competitor, I better know what each line of code does.”

Are you vibe coding, buddy-coding, or something else entirely? How are you balancing speed with deep understanding in your workflow?

#AI #SoftwareEngineering #DevOps #BroCoding #TechLeadership #Coding