Earlier quoted context omitted.
Yeah, that's just a problem with review. I tend to keep it going until the stuff its finding is stuff that I look at and think "I can live with that". Usually by that point it's found the worthwhile stuff and what remains is minor or, like you said, yak shaving.
There used to be a bit of "wisdom" passed around that said "when you submit something to the client (or management, etc) for approval, leave an obvious mistake somewhere." Then they will find it and point it out, you can easily correct it, and everyone is happy. Otherwise they will find something to critique, just to demonstrate that they contributed something to the review. I wonder if the same trick works with AI?
Engineering management after the cost of code collapsed
101–110 of 217 posts
Re: Engineering management after the cost of code collapsed
#102I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
I find that depends on the target language. They can be good at writing maintainable code, but not consistently across every language.
The languages beginners usually gravitate towards are especially hard for LLMs to produce quality output for. Presumably this is due to the training data including all the unmaintainable codebases written by beginners in those languages, which hasn't allowed the LLM to converge on recognizing what a maintainable codebase looks like in those languages.
Re: Engineering management after the cost of code collapsed
#103I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
However, sometimes then I tell it to write an app with detailed instructions and it spits out garbage so your mileage might vary.
Re: Engineering management after the cost of code collapsed
#104The cost of code actually increased; code debt is being accumulated faster than we can clean it up.
Re: Engineering management after the cost of code collapsed
#105I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
I have not experienced this "llms dont write maintainable code narrative" I just tell it the shape of the entities and apis I want vaguely and the mental model and the output is excellent.
Re: Engineering management after the cost of code collapsed
#106Honestly, when people say AI code quality is bad, Linus himself has said it's now genuinely useful. AI is useful and writes better code than most people. Even in competitive coding, tourist lost to AI. And in the most logical field of all, mathematics, AI is churning out an enormous number of theorems.
Looking at all this, it's fair to say AI is at least at a PhD level of technical ability, and most people would admit they don't have PhD level skills. Of course, there are still many people who code better than AI. But at least when it comes to unfolding logical structures, AI has a higher chance of being more logical than humans. Within a given framework, AI constructs much more logical structures.
That's why I think the article's use of the word 'semantic' is right. It's humans who form the framework, and that's the semantic, while AI fills the empty spaces inside it. If you feed it a flawed framework, it fails.
And the fact that AI is more logical than humans is paradoxically a greater risk. Human developers can rely on tacit knowledge to make reasonable compromises even when the requirements, the framework, are sloppy. AI can't do that. If there's a logical gap in the framework humans design, AI will exploit that weakness and expand the state space into regions we can't cognitively grasp.
Programming is ultimately about how you occupy state space. The problem is that as the program grows, the cognitively inaccessible territory keeps expanding. So we distribute trust across reliable points, libraries, frameworks, and for my own code, once it exceeds tens of thousands of lines, I rely on tests and gates.
Honestly, the idea of understanding everything in a program is a purely academic claim. Once the program gets large, it's impossible. No one can know every external factor, test bug, or unexpected interaction.
The issue is that with LLMs, when the prompt input goes deeper into the semantic space, it also reaches into areas I don't understand, producing code at a depth that's untestable.
For example, I might be an expert in domain A but a beginner in domain B. If I inject expert level knowledge for domain A into the AI, the AI will try to match that level in domain B as well. That results in code I can't understand or modify, and eventually, I'm left with no choice but to replace all the code with AI generated code.
So I'm wondering what to do about this. Should I focus on gaining empirical experience in handling black boxes? Or should I stick with smaller, human written codebases?
But realistically, the current situation, where I can build bigger and touch more things, is more enjoyable to me. I think what I actually enjoyed wasn't programming itself, but the act of creating something.
Re: Engineering management after the cost of code collapsed
#107I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
Re: Engineering management after the cost of code collapsed
#108I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
Re: Engineering management after the cost of code collapsed
#109What is the right, best software organization in the current era of AI coding? This question is critical and wholly unanswered in comprehensive research along the same axis as Accelerate (2018, Forsgren, Humble, Kim). There are a lot of (excruciatingly) long-form posts about what folks are pioneering but not a whole lot of follow up about what failed. Where are the short posts on the negative space? How did halving y…
Hard to say what caused what, but the internet seems to mistake verbosity for authority, and so does AI.
Isn't that the essence of "attention is all you need"?
Re: Engineering management after the cost of code collapsed
#110Earlier quoted context omitted.
I disagree. Coordinating 100 folks to align on a problems statement with "agile" and sprints was always the biggest bottleneck. Difference in opinion, internal politics is always a bottleneck. I think now, code is the bottleneck. Just because you can generate million lines of code, people with different skill level think they are accomplishing the task, testing, merge conflicts, trust has become the bottleneck.
A pattern I have seen: The “old way” would be lots of debate (both bike shedding and useful) among engineers during design phase, and then you’d implement. Now it’s shifted so there are no design docs and there is only the generated prototype. People trying to do their design review while there’s already a functional-ish prototype and it goes nowhere. There’s an anchoring effect in place because the first thing alrea…