I know this scares many people, but you can control things with QA, evals, ship quality gates and so on... I know we might have more bugs in the short term, but is not looking at the code the right direction we should go for the long term?

Several important developers switched to this new idea, the ones who work in production grade stuff (one example is Antirez, who just wrote some tweets that inspired this post)

I work in hardware development, and without the ability to release updates after something has literally shipped, embedded software has to follow the the opposite philosophy.

I've found that the forced do-it-once-and-do-it-right philosophy requires so much less total development time than the break-things-and-release-often philosophy that I've adopted it on software that I could update after the fact.

The biggest impediment is that you may be relying on a software stack adopting a different philosophy. No matter how good your software is, if the underlying OS or libraries are buggy, there may still be poor reliability.

Using standard C libraries is a pretty safe bet, whereas relying on Python or Node.js libraries means you'll need to issue constant patches, even if your software works fine, and the fixed libraries might even break compatibility.

Given the option, running your software on OpenBSD can give extremely high uptime as critical updates are rare. They have a philosophy of not only looking at what they write, but looking at it again later, even when they haven't changed anything, just in case they made a mistake.

Slowing us down from what?

In the context of many other measures I think speed is an important measure. Maybe even the key measure. I’ve even written a blog post entitled “reading code is an anti-pattern.”

But if the metric is, slowing us down from having more lines in production then the answer is unequivocally yes.

If the answer is providing customer value, or having a sustainable engineering culture. Then I’m not so sure. I’m not saying I believe the opposite, but it feels like excessively optimizing on the wrong thing.

Ultimately I think this asks the wrong question, I think most other surrounding questions is the right one which is - how do you safely and quickly deploy the right code to production that delivers customer value.

I think that will continue going forward involve doing so in an automated fashion, but then the right question isn’t, “should we stop reading code”. But something like “what is the right way to ship intent to production”

Because if you do the first without the second…

Looking both ways before crossing the street slows you down too, but it's done for good reasons. Ignore reading code at your own peril.

Speed has never been my number one goal. I’m not sure why I’d start to optimize for that now.

The issue is long-term code quality. These things are not good at it. They locally optimize, reimplement (inconsistently), and are overly defensive. You can only observe this by looking at the code they produce.

How perfect is your QA?

I'll answer for myself: At no organization I have ever been at was it perfect enough that devs didn't have to worry about the quality of what they produced. So I think you're asking QA to bear a burden that it has not been able to bear at any place I have ever been.

Second question: What is your time frame? Are you building for the next six months, or the next 20 years?

It is an open question whether AI will produce stuff that is maintainable in the long term. (I know, you have to survive the next six months in order to get to the long term...) But if you don't look, you don't know what kind of headaches are being written.

> I know we might have more bugs in the short term, but is not looking at the code the right direction we should go for the long term?

Would you drive without looking at the road (or blindfolded) because we now have autonomous vehicles?

Not looking at where you are driving and also never looking or understanding what the code does, makes no sense in the long term. Especially in the event of a disaster.

Both have something called "liability" and it gets expensive when it goes wrong.

> Several important developers switched to this new idea, the ones who work in production grade stuff (one example is Antirez, who just wrote some tweets that inspired this post)

Does that mean we should blindly follow them? Just because someone else is doing it does not mean you should too.

A better questions is...have we lost the ability to think for ourselves because we have LLMs doing all the thinking instead?

With respect, you may not have the experience to recognize the cost tradeoff you're suggesting here.

If you're choosing to rely on a strict, exhaustive validation process to approve your work product without concern for how it's produced, you shifting focus to several critical cost centers:

1. Exhaustive validation is not free and its cost grow super-linearly as your work product gains complexity -- both on its tested surfaces and in what inefficiencies it develops internally. As you invite more frequent commits of more uncoordinated code, you're running your QA process ever more often on ever more heavy code, covering ever more work surface area. This is non-trivial cost and potentially catastrophic risk.

2. AI costs scale with token requirements and project complexity. As you allow uncoordinated code to accumulate within your product, you super-linearly increase the token consumption required by AI agents attempting future commits and analyses as they digest the increasingly chaotic/uncoordinated code base, both in raw input tokens and the reasoning tokens used to strategize plans. Even if you believe that your AI agents will be able to keep up with this expanding burden indefinitely (a questionable assumption!), you're incurring another growing, super-linear cost.

3. If you're relying on frontier models to make this workflow feasible at all, you're at risk of uncontrolled cost ratcheting if and when your code grows so speghettified that only those models can maintain it. You may have economics that work today, but the model providers you use are positioned to squeeze your margin aggressively once you trap yourself within their ecosystem.

Now, it's possible that an adept team can figure out how remediate some of these concerns by appropriately tasking agents to reduce project complexity and efficiency independent of new feature development. But the overall workflow here remains uncharted territory, where few people are going to be getting it right, and many will find themselves being painted into a very expensive dead end.

TLDR; do what you want, but all the traditional concerns of technical debt management and vendor exploitation risk are at play here. They've just shifted around in a way that makes it easy for inexperienced or myopic people to think they've somehow escaped them because the underlying technology itself is so novel and unfamiliar.

In general, what you're talking about here is something that businesses have been able to do for decades by delegating their tasks to outsourced suppliers. The lesson, then and now, is that it works until it doesn't and that once it stops working, you're screwed.

So be careful -- the revolution you've promised is not what you imagine it to be!