I'm sorry, but you still have to think

indrex

I had to google “clanker”.

Ozzie_osman

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.

tomrod

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.

IshKebab

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.

as1mov

I dread for the future where "you have to think" is considered a controversial statement.

thomascountz

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? This comment shouldn't be read as advocating for this; it's a thought experiment about pragmatism and trade-offs, and reflects what I'm witnessing companies (and "programmers") asking themselves. I personally care a lot about understanding systems and 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 our systems are doing, going to increase their shareholder value?

discreteevent

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.

variety8675

This article just reminds me that workslop is so hard to counter because it takes no effort to produce and immense effort to debunk

stephbook

With all these ports, I always wonder: Who implements new features, and in which code base? 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?

wuhhh

Really appreciate the time taken to dig into this with solid improvements to boot, great work

sergiotapia

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. Not a good look tbh

tripleee

My suspicion is DHH is intentionally creating controversy to drive interest to Omarchy If he truly believed in the idea of never reading the code, he'd fire all his developers and have the designers do it all - create very high level feature descriptions and iterate on them. Put your money where your mouth is

wilg

I think attempting few-shot agentic ports of an app as an exercise and having the results not be perfect is really a referendum on thinking or using AI in coding in any particularly meaningful way.

RobRivera

smokes cigarette Life, eh?

Mawr

Oh wow, he's actually delusional: "I didn't do anything. I asked two frontier agents to make the most of Elixir and this is what they came up with. Please do send a PR to speed things up! But also realize that it's not exactly extra points for Elixir if frontier agents can't find the magic "go fast" switches." https://x.com/dhh/status/2106864061832991134

tiemster

Or as someone in 2025 said..."it's better to be competent".

duncangh

My preference is to not think, then act and then perpetually think about what I should have done instead

royal__

"If you looked at the code, and yeah, I know, we should not be reading code anymore" I'm pretty sure this is sarcasm, but it's also a major factor in what differentiated slop from non-slop AI work: did a developer actually take the time to review and clean up generated code. Which is, itself, an extremely time consuming process

adventure331

Yes I agree thinking is still needed off course, but it has never been easier to ship 'half baked' things that don't actually matter and just works. What I mean is, if something has little proven business value, why waste time making sure it is correctly implemented? I'd rather spend time thinking about things that has actual proven business value, otherwise I'm not opposed to shipping something that I understand only 60 or 70% and save energy. ie: how it works at a high level. If we are going to the moon, then by all means I think we should probably scrutinize every single line of code, but most business aren't going to the moon.

softwaredoug

These articles IMO suffer from good data. It seems we could probably at this point study open source projects longitudinally and see what we learn depending on their AI policies. Are there patterns in stability? Bugginess? Performance? Readability? Etc.