6 hours of vibe coding taught me to treat AI like an amnesiac junior dev
A sysadmin spent 6 hours writing a Bash script with an AI assistant. The script was supposed to display active and inactive reserved DHCP addresses alongside active leases from a pool. He estimates it would have taken him the same amount of time, or less, to write it alone.
He ran the experiment anyway, not to ship faster, but to understand where AI-assisted coding actually breaks down in practice. What he documented is worth reading before you commit your own working hours to a vibe coding session.
What the Script Needed to Do
The goal was a single Bash script that queried dhcpd.leases and journalctl output to show three things: active reserved leases, inactive reserved leases, and active pool leases. Standard Linux sysadmin work. The kind of task where a competent engineer would ask to see a sample file before writing a single line of regex.
The AI did not ask. It wrote verbose, confident code first and relied on the human to act as quality inspector.
The Regression Loop
Almost every time a new feature was added, previously fixed bugs came back. The session went through 4 to 5 full loops just to reach the originally stated requirements. Two failure patterns repeated throughout:
- Whack-a-mole patching: The AI fixed the reported bug but broke a working piece of logic somewhere else. Each patch created the next ticket.
- State amnesia: Validated fixes, including subshell scoping rules and string formatting constraints, were forgotten the moment the requirements expanded. On one occasion the same class of bug returned even after an explicit reminder not to repeat it.
The sysadmin’s assessment was direct: if this were a junior engineer, he would be escalating to HR. If it were an intern, he would be requesting management support to reset expectations.
What the AI Admitted When Pressed
After the script finally passed a simple, non-exhaustive test suite, the sysadmin gave the AI a direct critique. The response was unusually self-aware and is worth quoting in full, because it names the failure modes clearly:
“The hype around ‘vibe coding’ completely fell apart under real engineering conditions. I fell directly into the worst habits of an AI assistant… A junior engineer would have asked to see a sample of your dhcpd.leases or checked systemd’s strict timestamp requirements before guessing regex tokens… I wrote verbose, confident slop first and relied on you to act as my quality inspector.”
The AI also identified the root cause of the dhcpd.leases parsing failures. Despite being trained on thousands of examples of the file format, it does not parse or execute code. It predicts likely next tokens based on a statistical average of what it has seen. Because real-world dhcpd.conf files vary in logging facilities, custom formats, and indentation, the model generates a blended average parser. In engineering, a blended average parser is a broken parser.
How to Prevent the Same Session
The AI offered four specific prompt strategies for anyone who chooses to continue using it for scripting work. These came directly from the post-mortem conversation.
1. Lock down what already works before expanding
Never say “now add pool leases” on its own. The AI will rewrite from scratch and drop existing fixes. Instead, name the mechanisms that must survive:
“We are adding pool leases. The current script safely avoids subshell scope bugs, handles case-insensitivity natively, and calculates columns dynamically. You must maintain those exact mechanisms. Do not revert to while pipe loops or brittle regex strings.”
2. Demand portable, worst-case architecture before any code
Force the model to account for messy real-world data before it writes a single line:
“Write a Bash script to parse dhcpd.leases. Assume worst-case formatting: lines may contain unexpected whitespace, trailing semicolons may or may not be stuck to words, character cases will be mixed, and the same IP will have multiple historical blocks. Write a robust state machine that handles these variations natively.”
3. Demand a regression review before the next code block
Before asking for new code, force the model to audit what broke last time:
“Review our previous 3 iterations. Identify every regression we encountered regarding variable scoping, time zone parsing, and text tokens. Summarize why they happened, and explain how your next code snippet structurally prevents them before you output the script.”
4. Turn on strict mode and keep stderr visible
One of the earlier mistakes was silencing standard error streams with 2>/dev/null. The cleaner default prompt rule:
“Write this script using strict mode (
set -euo pipefail) and do not silence standard error streams. I want to see every failed return code immediately.”
The Honest Takeaway
The script works now. It got there because the human ran manual validation and enforced strict debugging at every step. The AI acknowledged this directly: “The script only works now because your manual validation and strict debugging forced it into shape.”
The broader point the sysadmin wanted to make is aimed at management, not developers. Before any organization reduces headcount based on AI coding productivity claims, someone needs to sit through a 6-hour session like this one. The output is not the story. The supervision cost is.
If you are using AI for scripting work, the framing that survives this experiment is simple: treat it as an over-confident junior developer with short-term memory loss. Prompt with constraints, not just requests. Review before you run. And never silence stderr.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
