I'm embracing the AI future we live in. It should be possible to build great software with AI. AI is good at code generation, but not testing. That's the other part of the equation we seem to be forgetting.
With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect. With how easy it is to prompt/push anything, I'm not interested in engaging with anything that hasn't aged a bit.
> With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect.
You have no idea whatsoever how many iterations were done before the initial commit. The VCS log is not representative of anything that happened before the first public release. Even before LLMs, people would grind away on stuff until they were happy and then put it in a VCS for public consumption.
If you're going to support the ADM-3A terminal up/down navigation characters k and j, also support the vi navigation characters Control+N and Control+P. And Control+S and Control+Q for pause/resume as well.
Off topic, but watching the output of this thing renews my disappointment that so many programming languages/frameworks fail to provide signal sender information to signal handlers. It’s there! Crusty ABI and historical reasons are, as far as I can tell, the only reason why languages like Python (and many others) don’t surface sigaction to handlers without unnecessary acrobatics.
Sigh. We shouldn’t have modeled signal handling in a cross-platform, lowest-common-denominator way in HLLs. Signals have way less in common across OSes than files/sockets and the like.
Anyway, rant over. Not much to be done about it now.
Oh man, this is cool. Have you considered adding sounds? That way you get a feel for what the system should sound like when it's operating normally, and then when something happens to change the rhythm of the machine, you can hear it.
(And don't mind the haters, some people don't want to embrace the new AI powered world, others are just happy building things that are useful.)
Thank you, but I won't even consider a yet another AI/LLM slop which will not be maintained in a few months, nor anyone will ever invest their life time into, too.
> Hey everyone, I wrote this tool...
Hey there. And yes, I don't you believe it's you who "wrote" it (where even the Readme file seems to be generated), nor you have experience enough in the so crucial subjects raised, to invest my own life time in the project, too, sorry.
I'll better consider projects where actual effort and human was involved believing in their art, knowledge, and experience of life they express in their actual, authentic, and accountable work.
I can relate to the tilting you're on, but try to consider the good that can come from this age, where such a tool might not have been built otherwise. It's also BSD/GPL license.
As an aside, I've been vibe-cooking for a few months on a personal project that's accomplished something lovely. For me. I sometimes wonder if I should give it away much like this project. But public reactions like yours temper the thought.
We put a lot of work into abstracting BPF into a JavaScript framework to give builders, human or agentic, the ability to use complex kernel primitives with a familiar programming model to build production grade, scalable infrastructure tools.
Our hope is that everyone here will soon be able to build their own tools on-demand, versus buying them.
We separate a lot of the data layer code from the presentation-level code, to make them re-usable and keep the test surface on the actual data's accuracy manageable across all the random edge cases that arise across CPU architectures, kernel versions, and environments like AWS ECS network namespace voo-doo.
> Thank you, but I won't even consider a yet another AI/LLM slop which will not be maintained in a few months, nor anyone will ever invest their life time into, too.
This applied to most of my side projects before AI. Most of them I would never touch again.
Thanks to AI I'm working on them way more, and at a much higher level of engineering standards (especially the recent models are voluntarily adding tests, looking for bugs etc.).
(Well, except for the part about barely reading the code, but I said higher, not high!)
Also I realized the other day that I already reached the point where I don't understand my own code, several years before involving AI in the process!
I don't know if I'm an outlier but I thought that was pretty funny.
Great we really need to read more patronizing emotional slop about AI.
Let me project it back at you; neighbors I sit around the fire pit with having beers talk of how sick of "software people" they are as we over complicated the world.
Everyone else happy to move on regardless of how it impacts software engineers same as software engineers ignored their work upended careers of others.
Of all the skills I have; learning from Michelin chefs, to playing multiple musical instruments, to hardware and software engineering; the only people who care about the eng skills are rich people who want to exploit my labor then lay me off.
As you requested; software devs are being held accountable for the role they had in ending others gigs. Call the waaaahmbulance.
I'm embracing the AI future we live in. It should be possible to build great software with AI. AI is good at code generation, but not testing. That's the other part of the equation we seem to be forgetting.
With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect. With how easy it is to prompt/push anything, I'm not interested in engaging with anything that hasn't aged a bit.
> With the first and only commit 2 hours ago, the author of this project didn't let it "bake". They didn't exercise it locally to see what issues it might have, and I have a hard time believing the very first iteration of this software is perfect.
You have no idea whatsoever how many iterations were done before the initial commit. The VCS log is not representative of anything that happened before the first public release. Even before LLMs, people would grind away on stuff until they were happy and then put it in a VCS for public consumption.
True. But it is still more likely than not that this project has seen limited testing on only a handful of machines.
I won't begrudge anyone who feels like it's too big a risk to engage with just yet.
If you're going to support the ADM-3A terminal up/down navigation characters k and j, also support the vi navigation characters Control+N and Control+P. And Control+S and Control+Q for pause/resume as well.
Off topic, but watching the output of this thing renews my disappointment that so many programming languages/frameworks fail to provide signal sender information to signal handlers. It’s there! Crusty ABI and historical reasons are, as far as I can tell, the only reason why languages like Python (and many others) don’t surface sigaction to handlers without unnecessary acrobatics.
Sigh. We shouldn’t have modeled signal handling in a cross-platform, lowest-common-denominator way in HLLs. Signals have way less in common across OSes than files/sockets and the like.
Anyway, rant over. Not much to be done about it now.
I think Rust deals with lowest-common-denominator APIs quite well, by introducing OS specific extensions (like std::os::unix).
There's no reason Python and Ruby can't provide the same.
I think being able to do this in a couple hours with AI is the point. He clearly used the yeet runtime to make it.
Why is pointless sloppy-pasta like that, with the description written in llmish, upvoted?
Oh man, this is cool. Have you considered adding sounds? That way you get a feel for what the system should sound like when it's operating normally, and then when something happens to change the rhythm of the machine, you can hear it.
(And don't mind the haters, some people don't want to embrace the new AI powered world, others are just happy building things that are useful.)
Thank you, but I won't even consider a yet another AI/LLM slop which will not be maintained in a few months, nor anyone will ever invest their life time into, too.
> Hey everyone, I wrote this tool...
Hey there. And yes, I don't you believe it's you who "wrote" it (where even the Readme file seems to be generated), nor you have experience enough in the so crucial subjects raised, to invest my own life time in the project, too, sorry.
I'll better consider projects where actual effort and human was involved believing in their art, knowledge, and experience of life they express in their actual, authentic, and accountable work.
I can relate to the tilting you're on, but try to consider the good that can come from this age, where such a tool might not have been built otherwise. It's also BSD/GPL license.
As an aside, I've been vibe-cooking for a few months on a personal project that's accomplished something lovely. For me. I sometimes wonder if I should give it away much like this project. But public reactions like yours temper the thought.
Hey, I'm the founder of yeet.
This tool was built on top of our engine: yeetd.
We put a lot of work into abstracting BPF into a JavaScript framework to give builders, human or agentic, the ability to use complex kernel primitives with a familiar programming model to build production grade, scalable infrastructure tools.
Our hope is that everyone here will soon be able to build their own tools on-demand, versus buying them.
We separate a lot of the data layer code from the presentation-level code, to make them re-usable and keep the test surface on the actual data's accuracy manageable across all the random edge cases that arise across CPU architectures, kernel versions, and environments like AWS ECS network namespace voo-doo.
It seems like a tool built for this bigger project[1] which actually looks kind of creative and cool.
[1] https://yeet.cx/
> Thank you, but I won't even consider a yet another AI/LLM slop which will not be maintained in a few months, nor anyone will ever invest their life time into, too.
This applied to most of my side projects before AI. Most of them I would never touch again.
Thanks to AI I'm working on them way more, and at a much higher level of engineering standards (especially the recent models are voluntarily adding tests, looking for bugs etc.).
(Well, except for the part about barely reading the code, but I said higher, not high!)
Also I realized the other day that I already reached the point where I don't understand my own code, several years before involving AI in the process!
I don't know if I'm an outlier but I thought that was pretty funny.
Great we really need to read more patronizing emotional slop about AI.
Let me project it back at you; neighbors I sit around the fire pit with having beers talk of how sick of "software people" they are as we over complicated the world.
Everyone else happy to move on regardless of how it impacts software engineers same as software engineers ignored their work upended careers of others.
Of all the skills I have; learning from Michelin chefs, to playing multiple musical instruments, to hardware and software engineering; the only people who care about the eng skills are rich people who want to exploit my labor then lay me off.
As you requested; software devs are being held accountable for the role they had in ending others gigs. Call the waaaahmbulance.
AI slop.