i have read it all hoping to find out what he is talking about... instead, the blog post ended 🤷♂️
this post was submitted on 30 Nov 2025
47 points (85.1% liked)
Programming
24083 readers
158 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I'm guessing he's alluding to a bunch of asserts, data sanitization, and granular error reporting. But yea, who knows.
The word you are looking for is "robust".
Debugging isn't the worst thing in programming. The worst thing is having a task you need to do and a solution already written, but not knowing how to use the solution to solve the task.
The word you are looking for is “robust”.
As Taleb explains in his book, antifragility is fundamentally different from the concepts of resiliency (i.e. the ability to recover from failure) and robustness (that is, the ability to resist failure).
Uh huh. But fragile code is not (just) code that tends towards getting worse
For example, if I’m vibe-coding a quick web app with more JavaScript than I care to read
Ah, please don't publish that code then. It's a experiment and not something juniors should come to learn as "good enough".
The issue is two fold.
First the scope of the project is very important. When I am working on a web app the most complicated project is still 90% boilerplate stuff. You write some RESTful code on some framework using CRUD and make a UI that draws based on data. No matter what you are making, lets be honest, it's not novel. This is why vibe coding can exist. Most of your unit tests can be derived from the types in your functions. Do a little bit of tracing through functions and AI can easily make your code less fragile.
When you are working on anything more complicated making code better requires you to actually grok the business requirements. Edge cases aren't as simple. The reasons for doing things a specific way aren't so superficial. Especially when you start having to write optimizations the compilers don't do automatically.
The second issue is learning matterial. The majority of the code we write is buggy. Not just in range testing but in solution to problems. There is a reason why we don't typically write once and never go back to our code.
Now think about when you, as a human, go back over old code. The commit log and blame usually don't give a great picture of why the change was needed. Not unless the dev was really detailed in their documentation. And even then it requires domain knowledge and conceptualization that AI still can't do.
When teaching humans to be be better at development we suck at it even when we can grok the language and the business needs. That is a hurdle we still need to cross with AI.