[radicality]

Similarly for me. I have a recent example too. I run a bunch of eps32 devices at home, using esphome. Pre-AI I wrote all the yaml myself and understood what’s happening and didn’t have any very bespoke hacks.

Recently I asked an agent for a feature where the screen will get dimmer after some time, and eventually after a day the screen will turn off and then turn back on if I tap, which should be pretty easy in esphome.

But: some past agent decided what it wanted wasn’t in esphome, so it made its own custom module in c++ for the display, spelunking in pdf datasheets; then the weeds were so deep the new agent decided to add on to that, and to read the power controller and display controller spec sheets and somehow implement my dimming feature by writing raw values to some nondescript registers.

The contraption worked until it didn’t and once every so often my esp32 would just completely hang with black screen and no connnectivity and needed a power cycle, presumably because whatever low level register writing the agent implemented eventually breaks something. I told the agent to get rid of all custom stuff and wherever possible just use default esphome yaml, now it’s been working fine. I don’t really have a point with the anecdote, just that I’m also getting tired of such scenarios like the OP.

[Gigachad]

I've been hit with the team manager trying to clear tickets on the jira board with entirely AI generated code, and what I've observed is they always make the system more complex, usually absurdly complex. The AI code never looks at things from a higher level, or reconsiders the requirements, it just layers on a load of crap until the tests pass.

[rowanG077]

It does that, yeah. But my experience mostly in codex with gpt 5.5 and 5.6 is that if you micromanage it enough you can get clear code. It just gets really annoying to repeatedly do that.

[shepherdjerred]

IMO this points to two things:

- You didn't have the agent plan and de-risk/experiment beforehand

- You didn't glance at the output

Working with agents is not very different from working with other engineers.

You write a design doc, share it with others, divvy up the work. You get to review some % of the code and make sure the implementation is reasonable. You leave comments for the important issues rather than trying to obtain pure/perfect code.

One of the biggest difference IMO is that you cannot really mentor an agent (other than prompting e.g. with AGENTS.md/skills)

Agents, just like engineers, can create needlessly complex code/systems. If you want a good result, you need to ask why did they do it X way and consider alternatives.

[radicality]

True, I didn’t do those in detail. I vaguely looked at the output and thought “let’s see if that works at all”.

I do such more careful planning and AI handholding at work where it’s important the thing doesn’t break in prod, or doesn’t forget about some important use case.

But this was just purely for “fun” / homelab style type of vibe coding where I don’t want it to feel like work and write intricate specs and handhold the agent - point being the current SotA models still currently do need a bunch of guidance to not devolve into a code spaghetti, and it does end up feeling like ‘work’.

[yhjc2692]

This is an extremely good advice - thank you

[theshrike79]

For some reason some harness/agent combos are deathly allergic to adding more dependencies unless you explicitly allow it.

Then you'll get shit like custom JSON parsers or config parsers made from scratch instead of importing an industry standard library.