Earlier quoted context omitted.
If a coworker dumped a 5k-line code review on you, you'd tell them to come back when it's broken down into smaller, reviewable chunks. Large dumps of code are basically unreviewable by humans, but it seems like a lot of people have forgotten about that when it comes to LLMs.
Breaking up a giant PR can be a tedious, time-consuming hassle, and in the past I could sympathize in practice if someone had a giant PR they didn't have time to decompose once they got it working. But it's also the exact sort of thing that LLMs are literally perfect for in my experience so there's really no excuse anymore. I've never seen Claude fail to turn a 5k PR into a well-decomposed Graphite stack.
AI demands more engineering discipline. Not less
111–120 of 234 posts
Re: AI demands more engineering discipline. Not less
#112Rather than dismissing humans for quality control, we should take an asymptotic approach, where humans verify less and less as more verifications are automated, but are never out of the loop. Get down to 1% of the things, then 0.1%, then 0.01% and so on.
Automate all the linting you can before the agent is allowed to make a PR, make sure it passes the tests, add custom linting for dumb AI-isms you’re sick of telling the agent not to do - yes, you can lint for that fallback & backcompat code you never asked for, you just have the agent generate a script that walks the AST and flags the problem by line and file, then put that in your pre-commit checks - the agent treats it like just another lint error. Now you never have to review for that thing again.
But you still have value!
Even when you automated everything you can think of, there’s still tremendous value in human review. It’s your last chance to fully understand the implementation before it melds with the codebase. You also pick up more antipatterns to add to your automated reviewer (the automated reviewer is just a long prompt with an ever growing list of bullet points)
And the asymptotic nature of QC extends to observability and production. You cannot really ever automate a loop directly from observability to code fixes? Even when the agent presents a fix to an unhandled exception in production - if it was bad data, should you clean it in a backfill? If a key business metric dropped off a cliff because of a bug, should you add an alert once you fix the bug?
Re: AI demands more engineering discipline. Not less
#113Earlier quoted context omitted.
"Open AI claims that its model disproven an Erdős conjecture, therefore my crappy way of arguing about software quality is valid." I really don't know how I'm supposed to reply to stuff like this.
> Open AI claims You undermine your own point when you misrepresent the situation like this. Real human mathematicians, including at least one Fields Medal winner, have validated and complimented the result.
The claim made by Open AI has two necessary components. The first one is that the conjecture had been disproven. (This is what had been verified by "real human mathematicians".) The second necessary part of their claim is that the work to disprove the conjecture was done mostly by their AI model rather than by people employed by Open AI.
Funny thing is that even the explainer on OpenAI's own website points out the issue:
"This result does not show us all the times AI has claimed to have a proof of something and been wrong."
"I believe if the level and type of human expertise that is represented on this note had been assembled to find a counterexample to this conjecture a month ago, and those people put in similar amounts of time working on it than they did to reading and thinking about Chat GPT’s solution, the mathematicians would have found a counterexample."
[1] https://cdn.openai.com/pdf/74c24085-19b0-4534-9c90-465b8e29a...
Re: AI demands more engineering discipline. Not less
#114Earlier quoted context omitted.
If a coworker dumped a 5k-line code review on you, you'd tell them to come back when it's broken down into smaller, reviewable chunks. Large dumps of code are basically unreviewable by humans, but it seems like a lot of people have forgotten about that when it comes to LLMs.
You aren't allowed to block PRs for being too large anymore. The objective that every engineer should be 2x/3x/5x more productive can only be achieved if you go totally lax on code reviews. Because if all your SWEs produce 5x more code, it also means they have to review 5x more code. But LLMs don't really help with code reviews. Then it becomes a Metcalfian paradox unless you just rubberstamp PRs, which is what is ex…
if youre being asked to rubberstamp prs thats a management skill issue
Re: AI demands more engineering discipline. Not less
#115Earlier quoted context omitted.
Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC. High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.
Rewriting code to be more compact is orthogonal to productivity.
Re: AI demands more engineering discipline. Not less
#116I did not enjoy reading this article. The writing was fine, and each individual paragraph was fine, but the whole thing together was meandering and dare I say pointless. It was so many words and yet so little seems to have been said.
I'm not sure this article had enough thought put into it. For example: What happened in 2025 was this: the economics of code production were turned upside down. Instead of being very hard, time-consuming, and expensive to generate code, it became effectively free and instant. Lines of code went from being treasured, reused, cared for and carefully curated, to being disposable and regenerable, practically overnight. I…
Re: AI demands more engineering discipline. Not less
#117Re: AI demands more engineering discipline. Not less
#118I liked this article, and I see a lot of other commenters didn't, so I'll give my take: When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, readi…
I liked the article. It was a long (and entertaining) build up to the conclusion, but I'm scratching my head how the author got there. AI needs more discipline, yes. But theoretically that discipline can be learned much easier than becoming a good engineer. Think of it this way... 20 years ago, to write good, scalable C code - you needed to 1) either be a genius, or 2) dedicated to the craft. You need to learn dozens…
Are you referring to this part:
> I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)
She's saying, "the amazing thing about LLMs isn't that they generate lots of code fast, so don't worry about people using LLMs for that taking over the industry"
She's making two points:
1. Before infra-as-code, people would be afraid to touch parts of production due to lost knowledge about how and why it got that way. Now that we have infra-as-code, you aren't allowed to change infra the old way (ad-hoc changes via dashboard/CLI), even if doing so would be faster and easier. Experienced SREs were required to abandon lots of their old skills with CLIs and dashboards and start working in a completely new way, because the knowledge captured in a terraform repo's commit history is so valuable.
2. In the past, the way code got written was through people making changes in ways that are specific to their current knowledge, the org's current problems, the current users, etc, some or all of which is not written down. Eventually, everyone is afraid to change certain things because they don't know or remember all the considerations that went into them (not just afraid to touch parts of the code, but afraid to delete seemingly-unused features, or migrate the schema, or whatever).
Charity is saying that problem 2 is a hidden/lost-knowledge problem like problem 1, and the amazing thing about LLMs is you have to write down all the knowledge you want them to have, which may lead to a better solution to the "lost knowledge" problem in software development, which would be so valuable that experienced software engineers have to abandon lots of old skills and start using it.
(Not only writing down all the knowledge you want the LLM to have, since they're flaky enough to ignore instructions and miss implications sometimes, but building test suites and tools and so on that adequately guide their solution. This is the "more discipline" she's referring to.)
Re: AI demands more engineering discipline. Not less
#119Earlier quoted context omitted.
Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC. High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.
Rewriting code to be more compact is orthogonal to productivity.
Re: AI demands more engineering discipline. Not less
#120> People do not want to wake up every day and log in to Slack and find the buttons and menus all subtly moved around. People do not want financial transactions that complete most of the time. Determinism is not going anywhere, my friends.
Well, I can't reconcile people not wanting things moving around and determinism with the promises of acceleration made by AI. The way I see it either AI makes "massive, discontinuous returns on investment" by way of changing things or we get a sustainable rate of change; these seem like contradicting goals to me.