This reminds me of the quote by Robert C. Martin[1]: "the ratio of time spent reading [code] versus writing is well over 10 to 1". If programmers spend 90%+ of their time reading code rather than writing it, then LLM-generated code is optimizing only a small amount of the total work of programming. That seems to be similar to the point this blog is making. [1] https://www.goodreads.com/quotes/835238-indeed-the-ratio-…
Writing Code Was Never the Bottleneck
391–400 of 400 posts
Re: Writing Code Was Never the Bottleneck
#392In a professional setting, I agree 100%, no notes. Where LLMs have helped me the most are actually side projects. There, writing the code is absolutely the bottleneck - I literally can't (or perhaps won't is more truthful) allocate enough time to write code for the little apps I've thought of to solve some small problem.
LLMs help me at work writing one-off scripts where I can verify they're behaving correctly. Or I'll give it a few lines of code where I don't like how they read and ask it if there's a cleaner way to write it, i.e. if there's maybe an API or method on a class that I'm forgetting/didn't know about, and I can understand its suggestion for a rewrite. But getting it to spit out hundreds or even thousands of lines of code…
Re: Writing Code Was Never the Bottleneck
#393Earlier quoted context omitted.
Basically the juniors just ask the LLM for an explanation of what the problem is and then fix what the LLM interprets your review to be talking about. The way that you solve this is that you pull your junior into a call and work them through your comments one by one verbally, expecting them to comprehend the issues every time.
If my boss is ok with AI, why bother and make the junior hate you? The codebase will go to shit regardless.
Re: Writing Code Was Never the Bottleneck
#394My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…
> - Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be. This reminded me of a quarter million dollar software project one of my employers had contracted to a team in a different country. On the face of it - especially if you go and check by the spec sheet - everything w…
So is this going to kill the demand for offshored code ? If you can get the same needs-babysitting code quality in no-time and no-budget ?
Re: Writing Code Was Never the Bottleneck
#395Earlier quoted context omitted.
This almost seems to be a weird artefact of capitalism. Ive worked on several projects which at some point became obviously doomed to almost everybody in the trenches but management/investors/owners kept believing. Perception of reality did not permeate the class divide. I wish I could make $$$ off this insight somehow but im not sure it's possible.
> This almost seems to be a weird artefact of capitalism. I don't see how this would be causally linked to capitalism in any meaningful way.
Many people use capitalism to mean the system of multinational corps and their secretive, hierarchical, and morally offensive ways, rather than anything to do with free market economics (which are predicated on the free flow of information in the market).
Re: Writing Code Was Never the Bottleneck
#396Re: Writing Code Was Never the Bottleneck
#397“The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication”
AI can dramatically speed up testing and code reviews. Generating unit tests is a major application of AI.
Code reviews can be accelerated too: “please quickly explain what this code is doing” to give you a foothold; “please check this code for any obvious mistakes” enables you to quickly bounce if a new review will be needed. And better yet - the submitter can ask the AI to do that, and also to suggest refactoring that will make code review easier and faster for someone else.
As for understand code and communicating it, well that is going to less and less necessary as the abstraction level we work at is lifted.
This objection is just cope. It’s moving the goalposts because we’re scared AI is going to take out jobs.
In truth, it will simply accelerate our work until we hit AGI. And at that point (which I think is probably a way off) we’ll have much greater concerns than the job market.
Re: Writing Code Was Never the Bottleneck
#398Re: Writing Code Was Never the Bottleneck
#399Earlier quoted context omitted.
>LLMs write a lot of bad code that cannot be realistically reviewed. It can be reviewed. The job descriptions I have encountered so far, (thousands of them), not one of them mentions reading fast as a skill even more important that writing/typing. Put it another way, I have yet to go to an interview with the sole purpose of reading code, and writing code as an insignificant detail. For example: 5 years of reading Pyt…
Donald Knuth never said that. It's from the preface to SICP, by Abelson and Sussman. I've edited the quote on Goodreads (though I don't know how long it will stick).
> Our design of this introductory computer-science subject reflects two major concerns. First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.
I've updated the quote on Goodreads again, but it seems like a losing battle to stem the tide of careless/misattributed quotes (it's even found its way to books and papers by not-too-meticulous authors).
Re: Writing Code Was Never the Bottleneck
#400I'm going to skip the obvious answer about how LLMs can actually improve code quality and reviewability and focus on a different argument: why engineers even care about code quality.
Most code is not written as a work of art but as an important functional piece to achieve return on capital. Programmers get paid by companies to produce code. The payment ultimately is driven by expectation of a return on investment of the code. Ultimately business owners and owners do not really care about code quality as long as it can deliver on return on capital. There are plenty of profitable businesses run on spaghetti code and old technology. However, engineers realized that bad code resulted in costly downstream consequences including consequences that affected ROI. Tech debt had to be paid not just in developer hours but also dollars and cents. Thus this obsession with code quality, code reviews, and this current debate.
Many including Andrew Ng at YC startup school recently are realizing that writing bad code is now a two way door instead of the one way door that it used to be. With LLMs you can deploy some bad code, realize it's bad, and rewrite that entire codebase tomorrow with near negligible cost. The fact that LLM can write some very very bad code is less important than the return on invested capital of that code especially when taking into account the speed at which that code can be fixed / completely re-written in the future, and especially when that in that future, LLMs will be even more capable than it is now.
Here's my advice: give in the shitty code and merge it. Claude 6 will refactor all of it to your liking very soon.