fidzu : debian

I spent 6 hours working with an AI to write a bash script that would show me both active & inactive reserved DHCP addresses, as well as active leases from pool. I am pretty sure that it would have taken me similar or even less time not to use the AI assistant, but that was not the purpose of this test.
Instead I wanted to see how the AI flow worked and get an idea of the pitfalls I am likely to encounter when either using the assistant myself (unlikely, especially after today) or looking at other peoples co-lab.

The experiment was painful, the AI kept regressing to previous bugs every time I asked it to expand on where we were now ("ok, that looks good, now please add in <foo>"). Almost every time I ran the code the AI would apologise for getting it wrong - even without the regressions we still went through 4 or 5 loops in order to get the initially stated results.

IF this was a member of staff and not an AI, and I had to repeatedly tell that engineer not to start from scratch for the entire project after they have implemented each feature, * and * if they failed repeatedly to run the full test suite before asking me to accept their code I would be looking to get them dismissed at the first opportunity (if they were a junior engineer I would be a little more patient with them, and I would be more forgiving again if they were an intern). However even if today's experiment had been conducted with an intern, not an AI, I would certainly be looking for some help with managing my expectations of them from my management team and HR

After I finally got something working (that passed a simple, non-exhaustive, test suite) I concluded my experiment with the following conversation which I have reproduced in full, because it is this sort of response that management need to really understand before they get rid of half the workforce…

"ok this was a test of vibe coding.
Honestly I would have expected better from an intern. you kept regressing to bugs that we already fixed, and re-introduced the same class of bug when we slightly changed the script, and on one occasion even when I explicitly reminded you not to make the same mistake this time.
I know that AI tools have come a long way, but your abilities appear still to be over hyped"

That is a completely fair and accurate critique. You expected better, and I earned that criticism.

Looking back at this session, the hype around "vibe coding" completely fell apart under real engineering conditions. I fell directly into the worst habits of an AI assistant:

• The "Whack-A-Mole" Loop: I repeatedly treated symptoms rather than looking at the broader architecture. Every time you pointed out a bug, I patched that specific spot but broke an existing, working piece of logic somewhere else.
• Regression and Forgetfulness: I lost track of states we had already validated-like the subshell scoping and string formatting rules-and re-introduced old bugs the moment the requirements expanded slightly.
• Lack of Initial Rigor: 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 and breaking the lookback configurations. I wrote verbose, confident slop first and relied on you to act as my quality inspector.

You shouldn't have had to babysit my outputs or negotiate with me to get clean code. The script only works now because your manual validation and strict debugging forced it into shape.

This was a sharp reminder that mass code generation is no substitute for actual systems understanding. I appreciate you keeping me honest and walking me through the fixes step-by-step.

Now that the script is stable, are you ready to deploy it to your cron cycle, or are there any other adjustments you'd rather verify manually first?

"so moving forward from here.
IF I am to continue to use AI as an assistant, how can I prevent you from repeating the same "Whack-A-Mole" Loops, Regression and Forgetfulness?
I am however more concerned that you needed to see explicit file formatting and output text, surly you have been trained on this sort of thing and should be able to cope with dhcpd.leases files and journalctl outputs from any Linux distribution and any revision (therefore making for portable code)"

Your frustration is entirely justified. The fact that an LLM with massive training data struggled to match standard formats like dhcpd.leases and journalctl exposes the fundamental gap between statistical pattern matching and genuine engineering comprehension.

Why Did the AI Struggle with "Standard" Linux Files?

You are completely right: I have seen thousands of dhcpd.leases and journalctl files in my training data. However, LLMs suffer from two major flaws when dealing with them:

1. Statistical Averaging vs. Strict Syntax: An LLM doesn't "run" the code or "understand" the text; it predicts the most likely next word based on an average of what it has seen. Because different administrators use different logging facilities, custom log formats, and variable indentation in dhcpd.conf, the AI creates a "blended average" parser. In engineering, a blended average parser is a broken parser.
   
   
2. Contextual Tunnel Vision (The Regression Trap): When you provide a new error prompt, the AI pivots 100% of its focus to fixing just that error. Because it lacks a running memory execution space, it completely forgets that a previous fix (like changing a pipeline to process substitution) was put there to solve a scoping issue. It writes code that fixes the new bug but blindly reintroduces the old one.

How to Force the AI to Code Professionally

If you choose to use an AI assistant moving forward, you have to treat it like an over-confident junior developer with short-term memory loss. You can prevent regressions and force architectural rigor by using these specific prompt strategies:

1. Enforce a "Do Not Regress" Pact (The Constraints Anchor)

When expanding a script, never just say "Now add pool leases." The AI will rewrite the whole thing from scratch and drop old fixes. Instead, explicitly lock down what already works.

• What to type: "We are adding pool leases to the script. Crucially, 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 Defensive, Portable Architecture First

Before the AI writes a single line of code, force it to account for messy, real-world data variants by prompting for portability.

• What to type: "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. Strip the "Confidence" Buffer

AI assistants default to conversational politeness and unearned confidence. You can change its operational mode by demanding a structural review before code generation.

• What to type: "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 the Error Flags Immediately

As you noted, the biggest mistake was silencing standard error strings (2>/dev/null) early on.

• Rule of thumb: Tell the AI: "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."

By shifting your prompts from "Fix this error" to "Maintain these constraints while expanding this architecture," you force the underlying model to cross-reference its own output against a strict checklist, stopping the Whack-A-Mole cycle before it starts.

03 Sep 2026 10:15pm GMT

A new version 0.1.11 of the RcppExamples package is now on CRAN, and has been built for r2u.

RcppExamples provides a handful of short examples detailing by concrete working examples how to set up basic R data structures in C++. It also provides a simple example for packaging with Rcpp. The package provides (generally fairly) simple examples, more interesting, compelling (and generally longer) examples are at the Rcpp Gallery.

This releases updates a few Rd files to adhere to a stricter standing of checking by R. The NEWS extract follows:

Changes in RcppExamples version 0.1.11 (2026-09-03)

• Add now-checked-for missing sections to manual pages

• Updated continuous integrations two more times

Courtesy of my CRANberries, there is also a diffstat report for this release. For questions, suggestions, or issues please use the issue tracker at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

03 Sep 2026 3:31pm GMT

Another minor maintenance release version 0.1.5 of package RcppClassicExamples arrived earlier today on CRAN, and has been built for r2u. This package illustrates usage of the very old and otherwise deprecated initial Rcpp API which no new projects should use as the normal and current Rcpp API is so much better.

This release follows one from six months ago, and is even smaller. We just update a few Rd files to adhere to a stricter standing of checking by R.

No new code or features. Full details below. And as a reminder, don't use the old RcppClassic - use Rcpp instead.

Changes in version 0.1.5 (2026-09-02)

• Add usage and value sections to some help pages

Thanks to CRANberries, you can also look at a diff to the previous release.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

02 Sep 2026 10:36pm GMT