upvote
> An over-engineered solution (complete with CLI, storage backend, documentation, unit tests) for a trivial problem which that person would've solved by an elegant bash one-liner only 3 years ago.

Importantly, I think AI companies are motivated towards the overengineered solutions as they increase the buyer's token spend. I'm not sure how we can create incentives that optimize for finding the 'right' solution, which may be the cheapest (the bash one-liner). Perhaps a widely recognized but not overly optimized for benchmark for this class of problems?

reply
> Importantly, I think AI companies are motivated towards the overengineered solutions as they increase the buyer's token spend.

Yes that, and also, the more complicated the solution, the more likely no one reads or reviews it too carefully, and will instead depend on an LLM to ‘read’ and ‘review it’

Even ignoring token costs, there’s a high incentive for LLMs to generate complex solutions, because those solutions generate demand for further LLM use. (You don’t really want to review that 30,000 line pull request by hand, do you?)

reply
I think the model space is too competitive. People will switch if another model is significantly better.
reply
Perhaps the experts have decided that, for this specific instance, the thing we need to do is ad-hoc and throwaway, and is simply not worth paying the extra cost to make it tasteful.
reply
How can a bash one-liner be more expensive to build than a full-blown CLI tool with the maintenance burden that comes with it?
reply
What expert would build a cli tool to avoid writing a bash one-liner?
reply
I cannot judge without more context. Depending on the one liner, the problem at hand, and overall situation that can be justified. A CLI is straightforward to create.

A bash oneliner can be a chain of 5+ programs, each buffering the stdin/out, what if the CLI is doing the same operation via streams instead? Just a random example but that can easily be worth it

reply
Sure, then there's a point where the extra taste isn't worth its cost.

I just don't like the fictional straw man where an expert has somehow been brainwashed by AI into forgetting everything they ever knew.

reply
Perhaps the ones that were experts before letting their brain rotten by AI.
reply
I'm sorry but "extensive documentation, scalable, high test coverage, perfect code style" seems to me to be the opposite of throwaway.

It sounds like the kind of thing people will think surely must be very important and in use, because why go through all those hoops instead of doing a quick hack?

But I guess we can just throw AI at the maintenance burden anyways..

reply
I agree, so you should ask yourself "why would the expert do this?"

I decided to go for the charitable interpretation of "the alternatives are close enough in functionality that writing by hand is not worth it", instead of the uncharitable interpretation of "these examples are completely made up".

reply
Because the expert has forgotten. Skills that we don't use are forgotten, and there's nothing new in that. Except for the proverbial bicycle.
reply
Ok, if you think the expert has forgotten that a problem can be solved by a bash one-liner and instead think they need a whole extensive CLI with documentation, our viewpoints are too far apart for fruitful discussion.
reply
The bash one-liner might be hyperbolic but with the advent of AI everything is artificially longer, stuffier, more complex and convoluted for no reason other than because the AI allows this increase in volume with little to no extra effort.

It used to be the proverbial one-liner with zero documentation because that was the best ratio of effort to results. Now the effort is on the AI and the results look more impressive. Today that will still impress a lot of people, bosses, colleagues. Very soon everyone will see through it and anything overly stuffy will have the opposite effect of looking low-effort.

reply
Sure, I agree, but now longer/stuffier things cost half as much as shorter things. In most cases, that cost isn't worth it.
reply
and here I am reading an interaction and thinking you two are saying exactly the same thing. Language be, what it is I guess: open to interpretation.
reply