The focus on "code" is sometimes too strong. This isn't just a code/quant issue. All of this applies too to any "answer" the LLM gives. Experts very often track their lineage - what teachers they had - because the details and slant of what they were taught guided their way of thinking and defined the "handle" they use to grab a problem. There is no "right way" to do most things - there are ways of approaching. Imagining that you are free-flowing and not in a channel is a rookie mistake! Encouraging this way of thinking is like the uptight enforcer of minor social mores: "Elbows!" no elbows on the table is how things are done and this is reified. Like you said "it takes no effort to produce and immense effort to debunk" and sometimes the stakes are high. I'm convinced that racism, for example, operates exactly like this: 0 friction go-with-the-flow insist it is natural...
If AI does anything, it amplifies asymmetries. Hacking, scamming, reducing code quality... its really good at making defending against those hard problems even harder.
The Bullshit Asymmetry Principle, a/k/a Brandolini’s Law: “the amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it".
It's worth noting that the context here is a system that was translated by an LLM which is the ideal use case for it. 90% of the thinking had already been done by developers of the existing system.
That's a really great point, and you can often start with documenting current behavior with tests and then carefully going through to figure out what bugs you've just enshrined in test cases…
Or an alternative: The whole background why in Dune thinking machines are outlawed and how it came to pass, that humanity had to fight the Butlerian Jihad.
At work, all thinking has basically become discouraged.
If you are not using AI agents for everything, you're doing something wrong, and wasting company time. It has been emphasized that no one should be writing code by hand and if you think an AI has implemented something wrong you need solid reasoning to show why or else people just label you as some anti-AI troublemaker, who just becomes an obstacle standing in the way of things getting done.
If your human generated opinion is in any way wrong or simply not a true homerun then you get snubbed in future reviews, people stop listening to you.
And more than anything, it doesn't take away the trade-offs of what to build to deliver value for customers, what to make the business improve, what avoids paging you on a vacation.
You need to understand the system you're working on enough to make well-informed decisions about its current and future states.
In some cases you can get away with not reading the code. And maybe in the future that will be more common. But for now, I personally prefer to read (or skim) the code, and not abdicate to AI.
Informative thought process here. Pre-committing benchmarks to measure real efficiency gains might have helped, but hands-off complex rewrites are still not shovel ready.
> hands-off complex rewrites are still not shovel ready
...which is a bit disappointing, actually. I mean, if you give an AI agent the complete code for a working application (ideally including tests), it should be able to translate it into an equivalent application in another language. I can understand if it makes mistakes because of ambiguous prompts etc., but for this task you shouldn't even need a prompt, any information it might need is right there in the code?
This post resonates a lot with me and my approach to counter the idea that an LLM (as amazing as a tool it is) gives programmers permission to stop engineering. To me, executing a decision in the face of trade-offs is what the job is all about.
So, I want to keep pulling the thread: is it worth reading—meaning, understanding—the code in order to prevent p95 latency from skyrocketing, avoid OOM death, and keep our apps reliable for customers?
The cost of understanding the code is ostensibly very high relative to just using a clanker (citation needed), so does paying that cost translate to value—what is it worth? Concretely, if vibe coding increases bugs and enshittification, but decreases spending without decreasing revenue (read: customers suffer, but they don't leave), do we still need to pay the cost of reading code? Is it better to invest in stickiness, lobbying, and market capture?
I hope this comment isn't read as advocating for this; it's more of a thought experiment about pragmatism and trade-offs. I know that I personally care a lot about understanding the code, and I believe I'm paid to do exactly that (I very much enjoy understanding code and nobody is paying me to run a business, so I may be biased in this). In everyday SaaS-land—not talking about critical safety systems—we've seen production databases destroyed, personal data leaked, platforms unwittingly exploited, and UX bugs creep into our operating systems, and yet the companies involved keep on keeping on.
Is thinking, meaning taking the time to actually understand what these systems are doing, going to increase their shareholder value?
I dunno. You still have to test, but in my experience if I noticed unreliability during high load I could just tell Claude "I noticed unreliability during high load" and it would easily have set up a high load benchmark, discovered this broadcast channel issue and fixed it.
It definitely improves the results if you do think but I don't think "you still have to think" is a safe space that's going to save us from unemployment.
Author is saying that some decisions aren't as obvious as "my code should be reliable under high load". Some decisions are tradeoffs that require you to have domain/technical expertise to answer.
I feel a bit sad DHH did the elixir one so dirty. It's the only language with the rule to follow rails to the T and of course Elixir can fly and be incredibly powerful without redis and other bullshit. It feels deliberately hamstrung. Almost maliciously because heavy hitters like Jose Valim have told him about this and he just ignores it.
It’s ideological in that it’s generally used by people that are anti-AI, or are trying to call out some perceived problem with AI.
In my experience, as I alluded to, it’s not commonly used by people who are thinking seriously for themselves about the benefits, risks, and consequences of AI and the economic activity surrounding it.
remember this timeless Agent Smith quote
If you are not using AI agents for everything, you're doing something wrong, and wasting company time. It has been emphasized that no one should be writing code by hand and if you think an AI has implemented something wrong you need solid reasoning to show why or else people just label you as some anti-AI troublemaker, who just becomes an obstacle standing in the way of things getting done.
If your human generated opinion is in any way wrong or simply not a true homerun then you get snubbed in future reviews, people stop listening to you.
However, it doesn't take away the concern of architecture, design, etc. and questioning if the current solution is well designed or not.
In other words, if you can't question the AI and refute it in a topic, you aren't expert enough to use AI in that area in a engineering manner.
Granted, not everything needs an engineer behind it. A shack to store some tools will survive long enough probably
In some cases you can get away with not reading the code. And maybe in the future that will be more common. But for now, I personally prefer to read (or skim) the code, and not abdicate to AI.
It's easy to port a codebase (at least, if you have automated tests), but once you've done that, do you
- Implement features in the old code and port again?
- Implement them in the new, unfamiliar codebase?
- Just write a Jira ticket and let the agent YOLO it?
...which is a bit disappointing, actually. I mean, if you give an AI agent the complete code for a working application (ideally including tests), it should be able to translate it into an equivalent application in another language. I can understand if it makes mistakes because of ambiguous prompts etc., but for this task you shouldn't even need a prompt, any information it might need is right there in the code?
So, I want to keep pulling the thread: is it worth reading—meaning, understanding—the code in order to prevent p95 latency from skyrocketing, avoid OOM death, and keep our apps reliable for customers?
The cost of understanding the code is ostensibly very high relative to just using a clanker (citation needed), so does paying that cost translate to value—what is it worth? Concretely, if vibe coding increases bugs and enshittification, but decreases spending without decreasing revenue (read: customers suffer, but they don't leave), do we still need to pay the cost of reading code? Is it better to invest in stickiness, lobbying, and market capture?
I hope this comment isn't read as advocating for this; it's more of a thought experiment about pragmatism and trade-offs. I know that I personally care a lot about understanding the code, and I believe I'm paid to do exactly that (I very much enjoy understanding code and nobody is paying me to run a business, so I may be biased in this). In everyday SaaS-land—not talking about critical safety systems—we've seen production databases destroyed, personal data leaked, platforms unwittingly exploited, and UX bugs creep into our operating systems, and yet the companies involved keep on keeping on.
Is thinking, meaning taking the time to actually understand what these systems are doing, going to increase their shareholder value?
It definitely improves the results if you do think but I don't think "you still have to think" is a safe space that's going to save us from unemployment.
Not a good look tbh
[0] https://xkcd.com/1053/
In my experience, as I alluded to, it’s not commonly used by people who are thinking seriously for themselves about the benefits, risks, and consequences of AI and the economic activity surrounding it.
It's much more nuanced, after all. Example:
https://lucumr.pocoo.org/2026/5/26/clankers/