We’ve crossed the rubicon where for many simple tech use cases it’s easier to vibe code exactly what you want than it is to research several existing solutions and test them.

@singe Problem is those vibe-coded tools will rarely get enough testing and maintenance to become really useful so we'll end up crafting (subpar) hammers for each nail, esp. because crafting hammers in this case feels pretty rewarding, see: https://svnscha.de/posts/the-passenger-seat-developer/

@buherator that’s if your goal is to make something globally useful. If your goal is to solve your current problem it’s a different set of incentives.

@buherator but thanks I’ll add that to tonight’s reading list.

@singe even in that case a) I don't like to write a _slightly_ different tool for a similar task (here comes maintenance) b) the fixed cost of vibe-coding (which is very easy to under-estimate) can easily exceed the cost of finding/learning 1 tool that can replace N.

But sure, I also do ad-hoc tools like this, and I actually think your observation is correct, it's just the tendency that is very slippery.

@buherator I hear ya. My knee jerk agreement with you was “don’t rewrite grep” but honestly if it’s learning you want rewriting grep is probably a better approach. If it’s speed you want and a brief search didn’t turn up something close then why not. For context my recent exp was the Burp App Store which didn’t have a simple global sed-like tool. Perhaps an argument for unix philosophy in tooling too.

@singe And my reaction was likely rooted in the fact that I missed so many great tools, only to find them later and redo my toolchain, because the maintained stuff was simply better than my ad-hoc one could be :)