The Bloat
5 points by milkandcigarettes
5 points by milkandcigarettes
I look at that screenshot with the ifs, and can't help but wonder why...
for key in ["description", "generatorType", ...]:
if key in song:
payload[key] = song[key]
...would be hard? Collect all the keys with a grep and some sed, throw them in an array, loop over them, and you have a couple of hundred lines less. No tokens necessary. And with a few hundred lines less, maybe the rest would be easier to clean up too - also token-less. Having maintainable code makes me warm and fuzzy inside, and I'm happy to spend five minutes to clean a large block of ifs up at least.
Perhaps I am missing the point, but if the code is indeed throwaway because "we just need it to work", why does it matter if it's bloated/ugly if it gets the job done?
If you expect the code to be changed in the future and you don't personally have time to debloat it by hand, you could ask the same LLM that generated it do simplify it for you.
It’s not throwaway yet not essential enough to force attention. There’s no security risk and there’s no direct impact to user experience. Verification is direct and automated enough to make it an easy target for an agent to build and maintain end-to-end. The only cost is horrendous code quality.
There's no security risk ...
yet
There's no direct impact to user experience...
yet
It seems as if developers can/could/should/used-to add a lot of value to codebases by anticipating foreseeable failure modes and preventing them early, ie cheaply. This is not something my AI's care about.
I feel like the conclusion is wrong here? Or, at least, I disagree with it.
From the context, i'm assuming that this is some personal, homegrown app primarily for yourself and/or some users.
If you don't like the code, just... fix it? why can't it be a priority? it doesn't seem like this is some large corporate app with tight deadlines for new features, so i'd say, just set aside some time to improve the code.
start reading all the diffs (at least skimming). ask the agent to identify top 5 simplification opportunities/stuff that can be moved to 3rd-party deps, like serialization and validation. start having it create a plan every time and have it explain anything you don't understand, iterate on the plan until you're happy...
regardless of whether you're typing the code or not, developing a mental model of the codebase will help you more easily reason about whether some new change is entirely too bloated/in the wrong direction.
however, all of this only applies if you care about the app. if it's some one-off script you use once a month, who cares. however, imo, if you use it regularly & keep extending it for longer than two weeks, it might be time to sit down, do a clean up to the best of you understanding, and then have the agent explain the rest of the stuff you don't understand (i sometimes like to have it create a "primer", which goes over the architecture, the layers, and the structure of the codebase).
fixing/changing some (even small) things by hand also helps, because it has you working directly in the codebase, speeding up your understanding of it.