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.

if your prompt is not specific enough, many decisions are a coin flip.

If you are using AI, you still have to know what you want it to do. If you are a project manager and give your team incomplete requirements, the result may not be unlike this.

If I'm tired, yep I'm going to write more sloppy code, I'll put less thought into it and be more tempted to tell the AI 'just do it'. That hasn't changed. I'm not sure where this new breed of "don't read the code" is coming from when it's actual software engineers making the statement; maybe it's just over-excitement and it'll die down (hopefully).

Or it's just over-simplification -- I don't read ALL the code either anymore, but at the same time I'm reading SOME of the code. Tell your AI agent you're doing a code review workshop, ask it to select ten files at random and then go through them with you one at a time. Ask it to review common anti-patterns and put them in your coding standard. Then you can start asking it to review and fix code against your standard as a first pass. You'll still need to manually review the code to keep it in check, but at least you can make it a bit less daunting and a little more fun by actively collaborating on the AI with the review.

I'm learning it's just a 'different kind of tired'. AI has made some stuff much more efficient, including the choice between efficiency and carefulness. You can make that choice at a micro level and very quickly now if you want. There's still fatigue though, it's just a different kind of fatigue. You still get tired from all the thinking. You can still choose to put the work in or not and it still makes a difference. It's just a different kind of difficult. Doesn't mean that the thing to do is to throw your hands in the air and declare that your job shouldn't be difficult or include hard work anymore.

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.

He favorite axe to grind was how my generation put too much trust into the compiler. "Just because it compiles doesn't mean you're done. You need to look at the actual assembly. Compilers can be VERY inefficient."

This was in the 90s. There was some merit to his claim.

But today? How many people who write Javascript look at the actual assembly code that is run? Not many.

I can't help but wonder if this current "you need to understand the code" is the same thing all over again. And if in a few years, almost nobody will look at the generated Python, Ruby, etc.

If it were me, I would start by getting a summary of what problems the existing solution solves. I would also make sure that summary had the non-functional requirement. Maybe write a test suite that opens the page and does all the stuff.

Then ask the LLM to implement in another language, with those solutions in mind, but first coming up with reasons why the target language might not be as good, and where it might have useful features that the original language didn't. Use the test suite to check if things are working.

I honestly don't think you would land far away. You would have to answer a few questions along the way, but it would mostly be plain sailing.

I would expect to be able to do this with very little human attention, whereas a language rewrite two years ago might take a whole month, not including learning the new language.

I think the main problem is that most people pushing for heavy AI delegation either

1. Don’t really care about system reliability or 2. Don’t understand the difference between code and system, and assume that a system must be reliable if some automated checks pass

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?

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

We got strictly better version of application for cheap. What is there even to complain about?

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

Clanker code is no exception. Slop is slop because it's low effort.

There are projects I've put most of my career into (necessarily pre-AI), and those I definitely care about the code quality. I look at every line and I don't take clanker code without going around the mill a few times with it. There are lots of things in the code I like and things I don't like and want to refactor. I care about the code quality. But there are projects I've put only weeks or month into, and some only minutes. For most of my vibe-coded projects, I've only cursorily glanced at the code. For these projects I don't care about code quality as much as the architecture and interaction. The ones where I consistently tweak it to work how I want are...just better.

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?

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.

Life, eh?

Not a good look tbh

"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