AI can be a great help in doing the wrong thing well
Posted in Knowhow on
I would not have started my Greenhouse side project last month if I weren’t able to delegate most of the coding to an LLM while I focus on product vision and engineering guidance. This week, I got to experience what can happen when that guidance is missing.
After shipping the Twitch integration for Greenhouse, my coding agent suggested a follow-up item to make it more resilient. As an old operations engineer, resilience is something I can always get behind. The agent’s stated goal was:
Replace the ephemeral EventSub ID on a Host connection with one durable subscription ownership record that persists through credential cleanup. It establishes one Workspace/broadcaster owner, a safe cleanup tombstone, independent EventSub operation fencing, and migration/backfill from deployed #53 [the previously shipped ticket] connections.
I don’t know about you, but I did not understand a single word. I knew nothing about the OAuth and EventSub mechanisms involved, so I trusted that the LLM understood them. I approved the follow-up ticket, which finally led to a day of wasted time and effort.
The first implementation round took hours and ended with an isolated agent review concluding that the result had too many flaws to salvage. Wow. I initiated a second attempt, but instructed the agent to break the task down into smaller chunks that it could implement in a more focused way. I did not yet know that this was a big mistake. A few hours later, the apparent success seemed to vindicate my intervention. There was a lot of new code with accompanying test cases, and it appeared to account for every situation Twitch and the application could conceivably encounter. But its complexity was far greater than a simple interactive website should need. As an example, there even was a code path for recovering from the case that Twitch issued a token, but the application couldn’t store it successfully. Overengineered much?!
I requested a critical review of whether the everyday usefulness of the new code warranted the added maintainability burden. The answer amounted to “Heck no”.
When I asked where it had gone wrong, the LLM said that its own use of distributed-systems language had sent it towards protocol optimisations far beyond what Greenhouse needed. It knew that Greenhouse was not safety-critical, but did not let that constrain the design.
Ultimately, I failed to recognise after the first failed attempt that it was building a castle where I needed a house. I could not read the blueprint well enough to stop it.
The lesson I learned from this is that it’s not enough that I review the results when the agent is done. Before a single line of code is generated, I need to understand what the agent is setting out to do. Even if it means admitting that I have no clue what that is. Especially then.
As Peter F. Drucker once said:
There is nothing so useless as doing efficiently that which should not be done at all.