Unfortunately the fact that you can't see (or understand) the quality of the components that make up your car doesn't make it less important. And low quality components can look like they're working fine until they blow up in your face.

Product quality still matters which is a result of code quality rather than the number of features you've shipped in the last week.

The agents are pretty good at documentation too. You can point them at existing codebases and have decent docs generated (way better than you're average dev can produce). You can also very quickly re-generate them from the ground up whenever a round of changes are done.

"An agent wrote the code" is not an excuse for failing to understand how the system works and fits together.

I don't give code quality a consideration at my job, as that is the expectation. I'm on-paper delivering more projects and "more productive".

I also don't think this is the right way. We are giving away practices and lesson learned over decades, in just over 6 months without fully understanding long term implications both technical and non-technical. And that is based on very optimistic bet that models will be able to handle all those potential issues that we might be concerned about in present. All the arguments/counter-arguments are mostly speculative, and I think only time will tell. My speculation is that this all BS will at some point self-correct at some point, it wont be like pre-LLM but it wont be crazy vibe-code don't look at code (or pretend we review code) either.

This view is defeatist, and one hundred percent correct. The programming profession as we once knew it no longer exists. Artisanal programmers will soon occupy the same niche that Emacs users did in the past (with the occasional "Why I still code by hand" blog post). The greybeards will gradually fade away, while new code generators (human or artificial) will get the job done, with no regard for how things were done just two or three years ago.

I think there is more to it than that. Even if we don't read all the code, it is still essential to comprehend the core structures that carry the weight of the program. Wrote something up on that subject some time ago, arguing that agentic code is a little like a fabric, in need of structural support to be practical at scale. In case it interests anyone:

https://epiq.sh/blog/the-soft-fabric-of-agentic-code

Having contracted in a company that tipped over from subscription token pricing to API token pricing recently, there’s still extremely good reason to keep your software a transparent.

The bill for the API usage was _hundreds_ of times higher than the subscriptions. Companies with a few hundred engineers, but without sky-high margins, simply cannot afford not to understand their codebases.

Refusing or being unable to understand the problem does not mean there is no problem.

Software was always a black box to non-coding execs, but quality still mattered to them, at least indirectly via feature velocity, user experience, reliability, and operational cost. That hasn't changed.

We all may end up ignoring the source code most of the time. But for a few years at least, we won't be able to ignore the quality of it, because nobody knows how to use "AI" in a way that has stable high quality over years of changes.

I guess that’s an advantage for engineers who are curious and continue to know how the thing actually works.

Being able to speak to what’s possible or not will definitely be a valuable skill.

Hopefully when the cost of tokens rises and your company can no longer afford to pay for it at the level needed that someone will be willing to keep it running.

https://www.laputan.org/mud/ still applies, even when using coding agents.

Over time the codebase will get more and more bloated, and making changes will take longer and cost more tokens. You'll start losing your grasp on how the codebase works, to the point where you can't even tell if the agent is doing the right thing or not. You'll be lulled into thinking that the code is correct from the tens of thousands of AI generated unit tests and the 100% line coverage, then you'll start noticing bugs pop up when you actually try to use the product. You tell the agent to fix the bug. It makes a patch and adds another dozen regression tests. You re-test the product. The bug has been fixed, but now there's a new bug. This is your life now.

Code quality was a concern maybe at tech companies, in every other industry it was never a concern, in fact you were shunned if you mentioned code quality because then you were not doing Product Thinking™

I've found if the code quality gets bad enough LLMs even get stuck trying to edit it. Can use LLMs to refactor it, but LLM will never suggest that if it gets stuck in loops :)

I've see agents get confused by a human's code comment and muck it up, so just get agent to rewrite from scratch.

I can't speak for commercial software development, but that's very much not true for open source software. Personally, I don't want to use software that is a black box. That's the reason why I'm using FOSS in the first place.

Another note: some software has a history of multiple decades. In fact, I happen to work on such software. IMO it would be irresponsible to turn the code into an incomprehensible slop fest just because some AI boosters want me to believe that "coding is solved" or "software is dead".

how can you confidently evaluate this sort of thing on a 6mo timescale

says person who has never been on a pager

I think we're being set up to be corn kings. A corn king is someone who the tribe makes the king, obey his every command, lavish him with wealth and pampering, all as long as things are going well. As soon as the corn harvest comes in a little bit short, we sacrifice the corn king to the gods in order to regain their favor and fix the harvest. No one cares about code quality and I can spend my days being richly rewarded for telling Claude what to do and then blindly shipping its output til we have a major prod outage or security breach, whereupon I am taken out back and shot.

    Code quality is no longer a concern to almost anyone

What did change? It's always been like this: ship fast, fill your pockets, wait a while, then enshittify. Nothing's changed in this industry.

When was code quality ever a concern?

I remember the "software craftsmanship" movement of the early and late oughts. Refactoring patterns, clean architecture and all that--nobody outside a tiny group gave a single sh*t about it.