Don’t listen to people telling you not to post your age on the internet. This is solid work and you did this instead of being stuck in one of the hundreds of +1 dopamine traps in Roblox or yelling at other (often times much younger) kids in Fortnite like many of your peers did.
You did something meaningful, you even waited to share it with the world until version three, and you learned a ton doing it. Well done, dude!
There’s no need to put down others to raise up OP. We can praise merit in one pursuit without acting like we are objectively better than others for it. How folks choose to spend their time is a fundamental part of personal freedom.
> nobody would even bat an eye because you can just vibe code this without effort.
To me, this is implying that software engineering in 2026 is less impressive than 10 years ago because "you can just vibe code this without effort". Having used AI a fair bit for both business and pleasure I can assure you that you can't always "just vibe code" something useful. Discrediting software engineering because a power tool was popularized in the field is... eh. I don't agree with that.
It sounded like you thought that with AI anyone, even children, can solve literally any problem with ease and therefore it's not very impressive (...and "perhaps we don't need 20+ software engineers building that app if 5 can do it with AI").
I'm going through this. It's demoralizing. I want to spend weeks coding something cool. The idea of asking an AI to do it in 30 minutes is like... what's even the point. I know I can, so why bother. I'd rather go get a beer.
It's like getting all the cheat codes and then the game isn't fun anymore.
You learn much more by doing the actual grunt work. Some people enjoy learning for the sake of learning.
We can learn assembly even though compilers exist. We can learn OpenGL even though 3D engines exist. We can learn to write a relational database even though SQLite/MariaDB/Postgres exist. Et cetera.
You can also play games for which you have all the cheat codes and simply choose to not use them.
Yeah, I'm this way. The best is when I have a job that gives me an opportunity to learn something new, or create a reason to learn something difficult along the way... but I'll try difficult things in my spare time for pleasure, too.
On the other hand, I'd also say there's one type of satisfaction you get from learning a new language, instrument or paradigm, toying around to see if you can write something difficult that proves to yourself that you understand it, and there's a different satisfaction from using your knowledge to make something truly large and impressive in scale and scope. And the large/impressive stuff does require a lot of boring boilerplate or rehashing things you already know how to do, with little creative flourishes along the way. But historically this would be when I would really discover the flaws and corner cases, too. And polish the end product.
So, like, you build some demo engine you think is amazing. Now you want to share it with people, so you have to write a bunch of UI. As you go along you get new ideas to add to the engine and you spot performance flaws or logical flaws, because the work of polishing it is meticulous, and you're actually using what you made the way someone new would use it for the first time. Seeing it through their eyes. This is where most of my projects would always fizzle before AI. But AI short circuits everything you'd get from this process because, for one thing, it feels like cheating. And for another, it disengages you. That core change to the kernel you realize you want to make, suddenly you let AI make the change and there's one less thing you actually own or understand perfectly in your code. It's no longer your hand crafted ninja blade. And yet the temptation to let it happen is very strong... so strong that I actually find it paralyzing. I neither want to write the UI myself nor let AI help me. I get depressed and stop caring.
I'm a musician, too. And I paint. What you get when you play music or paint is 100% yours, comprised of your knowledge and skill and whatever spirit happens to be inside you at that moment. Code was that way for me. It was art, part technical and part inspiration. But it's been robbed of some essence, the satisfaction of not only solving something but also materializing some piece of yourself out of sand for the whole world to enjoy. Some piece of thought that was completely yours. Nothing coded with AI completely belongs to its prompter. And honestly, losing that sense of craftsmanship is devastating to me and I think it's a huge loss for humanity.
I get the most satisfaction out of building small solutions that work really well. Problems that are beyond the scope of an individual to solve are not really as motivating. At that point you are just one of a group who slings code at the problem and hopes some of it sticks.
Exactly. Or you can go physical and do some HW+SW project, there is no AI (yet) for the physical world, at least at a price point for hobbyists. Although you can already go a long way 3D-printing
Instead of spending weeks building a new wall in your house, you spend a week building a new house. With AI mundane problems are solved easily and effectively, giving you time to go bigger.
Or a pilot of an aircraft rather than a "Wing Engineer" responsible for controlling the flaps or a "Flight Reliability Engineer" responsible for keeping the beeping noises and flashy lights to a minimum?
I've been vibe coding a large project the last couple of days and while it is pure magic, I have little understanding of the actual code (yet!) and the output is probably worse than if a team of Software Engineers spent a few months on it, but I still get to have sane discussions with Mr. Claude Sonnet about software design patterns and code coverage. And like I said: days, not months. My "role" in this project has of course shifted from "developer" to "overseer" or "architect" even, but if I hadn't have a Software Engineering background my LLM would have produced a rather poor result.
2) a form of the possessive case of singular they used as an attributive adjective, before a noun.
a) (used to refer to a generic or unspecified person previously mentioned, about to be mentioned, or present in the immediate context): A parent should read to their child.
> Why this matters: Modern infrastructure uses too many execution engines — Docker for dev, containerd for production, Firecracker for isolation, CRI for Kubernetes, MCP agents for AI.
It is my understanding that Docker Engine adds capabilities (such as network stack) on top of Containerd (which is a project maintained by the same people), and "CRI for Kubernetes" is a Container Runtime Interface which COULD be something other than Containerd but often is just Containerd. So in essence the reason why yet another runtime exists is that we have a runtime for containers (Docker/Containerd, Containerd and, for example, Containerd as the CRI in K8s), a runtime for isolation and a runtime for AI agents.
That seems like an unnecessary argument on its own, which makes me wonder why it's listed as the first argument.
Not to mention that a webserver can be configured to show one sh file when a regular browser visits and another when curl etc. gets it. Show one thing, install another.
This is helpful to know, but also pretty general security practice. If you are auditing an artifact, only use that audited artifact after, don't assume that a network endpoint can never change what it serves. If you must use a newly downloaded artifact, verify it matches whatever you audited by comparing some sort of hash or derived value.
The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash. I don't remember the magic by heart, but the blog post conclusion was essentially that you can't / shouldn't blindly trust which scripts you pipe straight into bash from the internet, because even if it looks correct in a browser, the script you might end up running could be different.
It's more of a "this is possible" than "this is a real concern", of course.
> The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash.
Maybe I’m not that clever but I can’t imagine at all how that would even be remotely possible. How would curl even know it’s being piped into something else? And if curl can’t know, how would the remote server know?
Send different response to browser vs curl, sure, that’s easy. But I’m saying download it to your local disk first, read it from there, then run your local copy, that you read. Don’t read it in the browser.
The Way Back Machine link works again, go read the blog post. :P
From the blog:
> Execution in bash is performed line by line and so the speed that bash can ingest data is limited by the speed of execution of the script. This means if we return a sleep at the start of our script the TCP send stream will pause while we wait for the sleep to execute. This pause can be detected and used to render different content streams.
> Unfortuneatly its not just a simple case of wrapping a socket.send("sleep 10") in a timer and waiting for a send call to block. The send and receive TCP streams in linux are buffered on a per socket basis, so we have to fill up these buffers before the call to send data will block. We know the buffer is full when the receiving client to replies to a packet with the Window Size flag set to 0 (Win=0 in wireshark).
> The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash
I think you must be mixing something up here. At least i would be very surprised to learn how pipes are that leaky over the wire. It would be very interesting. But i can't imagine how a remote would differentiate between curl and curl piped. And the article doesn't load unfortunately.
(Ps: yes, I'd rather have two passionate, eager interns under my wings than one burnt-out senior by my side.)