A meta-trend i find interesting is lots of serious infra being rewritten. Bun, Flow, Ladybird, pnpm pacquet, tsz, and I've made a rust rewrite of postgres that passes 100% of the regression and isolation tests[0][1]
I think AI changed the economics of these projects even more than it has the economics for software engineering work in general. Though direct AI code translation is usually slop for me.
One of the many things I did to deal with this was an audit skill that would:
1. Find a small chunk of code to rewrite
2. Have a list of things that it was looking for in each piece of code that's being rewritten
3. Place that next to the code being translated
4. If that document didn't exist and/or didn't say the code was passing the audit, code wouldn't be merged
5. As I found problems and anti-patterns I would add those to the skill over time
This by itself still let a lot of slop slip through, but also preemptively caught a ton of issues as part of my overall process.
Complicated old "boring" infra software might actually be the most AI-rewriteable code right now
This is cool. As someone who has authored Kubernetes educational content in a past role, I can definitely see the appeal of building something like this. iirc we first used Katacoda and then used some other similar platform and they were very useful since they spun up a fresh instance on the fly for each user with a specific setup.
Though it seems like right now this is probably better for conceptual/architectural education. The real fun is when you start learning to master kubectl.
Yeah, in a past role this would have been awesome for diagrams to explain how the control plane works, illustrating the degradation and failure modes, or comparing different architectures/ways to deploy onto k8s/
First thing is first, this is really cool.
This feels like the right way to frame LLM-assisted engineering. AI can generate a shocking amount of code, but the actual value is in the review discipline, and tests around it. The browser Kubernetes angle is cool, but what I find more interesting is the workflow, and especially testing behaviour against k8s instead of just trusting “looks right.” I do wonder how many teams are already doing this level of verification for AI-written code. It might be the direction everyone goes in over the next few years.
Perhaps to anticipate the multiple jokes about kube complexity, I think there's an interesting argument to make that something like kube is the necessary complexity level for the kinds of tasks that kube is intended to accomplish, ala Fred Brooks' rule about essential complexity vs accidental complexity.
Kube rapidly becomes accidental complexity when you use it to accomplish things that could be done more simply, of course.
Interesting project and (possibly more) interesting explanation of the development process. I agree with the author that the primary difference between vibe slop and real engineering is just reading the lines of code. However it does feel like we are just on the cusp of only needing to read the tests and _not_ all the lines of code. Maybe a few more model generations and we will be there.
A meta-trend i find interesting is lots of serious infra being rewritten. Bun, Flow, Ladybird, pnpm pacquet, tsz, and I've made a rust rewrite of postgres that passes 100% of the regression and isolation tests[0][1]
I think AI changed the economics of these projects even more than it has the economics for software engineering work in general. Though direct AI code translation is usually slop for me.
One of the many things I did to deal with this was an audit skill that would:
This by itself still let a lot of slop slip through, but also preemptively caught a ton of issues as part of my overall process.Complicated old "boring" infra software might actually be the most AI-rewriteable code right now
[0] https://pgrust.com
[1] https://github.com/malisper/pgrust
This is cool. As someone who has authored Kubernetes educational content in a past role, I can definitely see the appeal of building something like this. iirc we first used Katacoda and then used some other similar platform and they were very useful since they spun up a fresh instance on the fly for each user with a specific setup.
Though it seems like right now this is probably better for conceptual/architectural education. The real fun is when you start learning to master kubectl.
Yeah, in a past role this would have been awesome for diagrams to explain how the control plane works, illustrating the degradation and failure modes, or comparing different architectures/ways to deploy onto k8s/
Investing early in this hn post before it’s a banger. Instant classic
It's Web Scale Technology™
100%
First thing is first, this is really cool. This feels like the right way to frame LLM-assisted engineering. AI can generate a shocking amount of code, but the actual value is in the review discipline, and tests around it. The browser Kubernetes angle is cool, but what I find more interesting is the workflow, and especially testing behaviour against k8s instead of just trusting “looks right.” I do wonder how many teams are already doing this level of verification for AI-written code. It might be the direction everyone goes in over the next few years.
I mean this is a specific case where you literally have a spec to code against. Not all coding endeavors have that opportunity, unfortunately.
For a lot of us, the spec is Product Market Fit and Profit Dollars.
This is awesome. Wish I had the idea first. I see this as a fun learning and experimental tool.
For a while I have wanted to make a web page where you can do service load balancing and queuing simulations so this would be a great basis for it.
Perhaps to anticipate the multiple jokes about kube complexity, I think there's an interesting argument to make that something like kube is the necessary complexity level for the kinds of tasks that kube is intended to accomplish, ala Fred Brooks' rule about essential complexity vs accidental complexity.
Kube rapidly becomes accidental complexity when you use it to accomplish things that could be done more simply, of course.
There's even a blog/article write-up with a more succinct demo of Kubernetes: https://ngrok.com/blog/i-ported-kubernetes-to-the-browser
I wonder if stuff like this will also be created when token costs explode.
Yes, because you can buy infinity tokens for $10,000 with hardware.
And now for a fun game with this: try and delete all the pods!
wasm should be the "image" type for webernetes
This is great!
Interesting project and (possibly more) interesting explanation of the development process. I agree with the author that the primary difference between vibe slop and real engineering is just reading the lines of code. However it does feel like we are just on the cusp of only needing to read the tests and _not_ all the lines of code. Maybe a few more model generations and we will be there.
Please port Kubernetes to common house flies so that they drop dead out of all the unnecessary overhead. That would be helpful.
what will we port to the spiders whose population will otherwise surely explode?