Live data from Hacker News

Writing Code Was Never the Bottleneck

ordep.dev

181–190 of 400 posts

Re: Writing Code Was Never the Bottleneck

#181
post #79
post #53

Earlier quoted context omitted.

> - 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…

I'm expecting to see so much more poor quality software being made. We're going to be swimming in an ocean of bad software. Good experienced devs will be able to make better software, but so many inexperienced devs will be regurgitating so much more lousy software at a pace never seen before, it's going to be overwhelming. Or as the original commenter described, they're already being overwhelmed.

There are ways to fight it though. Look at Linux kernel for instance - they have been overwhelmed with poor contributions long before LLMs. The answer is to maintain standards that put as much burden on the contributor as possible, and normalizing unapologetic "no" from reviewers.

Re: Writing Code Was Never the Bottleneck

#182

My 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…

Could you tell which language they were coding in?

Re: Writing Code Was Never the Bottleneck

#183

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-…

Unfortunately, the micro-methods his clean coding style oroduce ends up doing the exact opposite.

Context is never close at hand, it is scattered all over the place defeating the purpose.

Re: Writing Code Was Never the Bottleneck

#184

Earlier quoted context omitted.

Yes, but some of us have seen this coming for a long time now. I will have my word in the matter before all is said and done. While everyone is busy pivoting to AI I keep my head down and build the tools that will be needed to clean up the mess...

Any hints on what kind of tools you're creating for the inevitable mess?

https://github.com/bablr-lang/

I'm building a universal DOM for code so that we should see an explosion in code whose purpose is to help clean up other code.

If you want to write code that makes changes to a tree of HTML nodes, you can pretty much write that code once and it will run in any web browser.

If you want to write code that makes a new program by changing a tree of syntax nodes, there are an incredible number of different and wholly incompatible environments for that code to run in. Transform authors are likely forced to pick one or two engines to support, and anyone who needs to run a lot of codemods will probably need to install 5-10 different execution engines.

Most people seem not to notice or care about this situation or realize that their tools are vastly underserving their potential just because we can't come up with the basic standards necessary to enable universal execution of codemod code, which also means there are drastically lower incentives to write custom codemods and lint rules than there could/should be

Re: Writing Code Was Never the Bottleneck

#185

Earlier quoted context omitted.

Yes, but some of us have seen this coming for a long time now. I will have my word in the matter before all is said and done. While everyone is busy pivoting to AI I keep my head down and build the tools that will be needed to clean up the mess...

Any hints on what kind of tools you're creating for the inevitable mess?

A faster command to recursively unlink files.

Re: Writing Code Was Never the Bottleneck

#186

A bit more interesting is slightly inverse to this. What will win in the next 10 years? IMO expectations are now so high from users that you need to create websites, apps, auth, payment integration, customer supoort forums and chats. And this is to break the ice and have a good footing for the business to move forward. You could see how this is a problem for a non technical person. Nobody will hire someone to do all…

I can’t get over the idea that I won’t ever trust my data to a product made entirely by AI; one with no or limited human oversight.

Re: Writing Code Was Never the Bottleneck

#187

In 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.

Agreed fully, if I have 1-2 hours a day with Claude code I end up the week with a personal project I can actually use. Or spend like half a weekend day to see if an idea makes sense. But I think that makes them invaluable in professional contexts. There is so much tooling we never have the time to write to improve stuff. Spend 1-2h with Claude code and you can have an admin dashboard, or some automation for something…

we specialize in "don't ask engineering for SQL" at https://www.definite.app/.

we spin up a data lake, load all your data and educate an agent on your data.

Re: Writing Code Was Never the Bottleneck

#188

My 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…

Thanks for this insides. I am curious and want to know: Is it also a 'good catch, I'll fix that' when you pair program or mob? Or better, did you notice any differences in behavior and issues while pair or mob programming with juniors (instead of using pull requests)?

Re: Writing Code Was Never the Bottleneck

#189

My 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…

> - 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 "good catch, I'll fix that" (also reminiscent of an LLM).

Would you mind drilling down into this a bit more? I might be dealing with a similar problem and would appreciate if you have any insight

Re: Writing Code Was Never the Bottleneck

#190
> The marginal cost of adding new software is approaching zero, especially with LLMs. But what is the price of understanding, testing, and trusting that code? Higher than ever.

I’m not sure about that: the code LLMs generate isn’t categorically worse than that written by people who no longer work here and that I can’t ask anything to either. It’s also not much better or worse than what you’d find online but has a more broad reach than my Google-fu, alongside some hallucinations. At the same time, AI doesn’t hate writing tests because it doesn’t get a choice. It doesn’t get breaks and doesn’t half ass things any more or less depending on how close to 5 PM it is.

Maybe my starting point is viewing all code as a liability and not trusting anything anyone (myself included) has written all that much, so the point doesn’t resonate with me that much. That said I have used AI to push out codebases that work, albeit that did take a testable domain and a lot of iteration.

It produces results but also rots my brain somewhat because the actual part of writing code becomes less of a mentally stimulating activity compared to requirements engineering.

Post reply on HN