Live data from Hacker News

AI demands more engineering discipline. Not less

charitydotwtf.substack.com

121–130 of 234 posts

Re: AI demands more engineering discipline. Not less

#121
post #55

Earlier quoted context omitted.

I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC. LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.

The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.

We had a library written by a former employee who was a prolific producer of code. He insisted we needed it and spent over a year developing it in company time.

The library was a masterpiece of what if driven development. It was about 50k LoC, and it had 300k LoC of dependencies. It was a nightmare to modify. And no one wanted to take over maintenance so people would submit PRs to the former employee when they did modify it.

I wanted to change something in the library to support a large migration I was in charge of. When I went digging it turned out that we were barely using any of the features in the 2 years since he’d finished it. I replaced the 50k LoC library and 300k LoC of dependencies with 300 lines in less time than it would have taken me to modify the library (a few days).

Re: AI demands more engineering discipline. Not less

#122
I just spent a week reviewing this ~200 LoC PR: https://github.com/ncruces/wasm2go/pull/37

It was submitted by a seasoned user, who probably asked a frontier LLM. It still felt… wrong. I didn't understand it, and I wouldn't merge it without understanding it.

I also suspected it was wrong, in a way that would cause issues in the future.

So I reviewed it 4 different ways: (1) try to understand/improve it; (2) do it with better algorithms; (3) avoid it by fixing the issue upstream; (4) rewrite it from scratch probably just to match my brain.

I expected either (2) or (3) would be the answer. (2) didn't work, rather it's the correct answer but I need to redo the project from scratch to use it; (3) I wanted really bad to work, but didn't.

So I got to a blend of (1) and (4). I'm still not entirely convinced, but now I understand the issue/solution. I obviously think my approach is better.

Still, I still stripped both of comments, and asked my LLM to review.

The LLM came back and said the original one was clearly better. I explained why not, it then answered I was correct.

If I try it with comments, LLMs say the mine is better. Because I found a real issue (one that I pointed at in the original comment thread). But is it saying mine is better because I coerced it to say so?

Re: AI demands more engineering discipline. Not less

#123
post #84

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

Simplification usually requires the most effort and results in simple and elegant systems easy to understand and maintain with reduced error surface.

So overall increases productivity by a lot

Re: AI demands more engineering discipline. Not less

#124
post #84

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

non-coding manager spotted

Re: AI demands more engineering discipline. Not less

#126

Wrong! AI demands more of your hours cranking out the same discipline, due to the volume of stuff that needs to be verified. Normally the term "more discipline" is understood as increased rigor, not simply more work at the same level of rigor.

Chatbots enable unskilled developers to go in way out of their depth with little resistance. This creates problems of a new nature, not just more problems of the same nature as before.

Previously in my career, a junior making a mistake and being told why it was a mistake would learn from that and improve. The junior-chatbot duo will not. The junior will feed my comment into the chatbot, and the chatbot will superficially give the impression of having learned from the mistake and fix the code while introducing the same problem somewhere else, and the junior will have learned nothing.

This all requires that I review code as though it was created by some kind of cursed monkey's paw with an endless number of fingers that each grants a wish of the operator with a devastating caveat through idiotic interpretation.

If you give a toddler who can otherwise not operate a chainsaw -- for the simple reason that they don't have the strength to start it using the starter rope -- access to a robot who will turn on the chainsaw for them on command, you've created a problem which didn't exist before.

Re: AI demands more engineering discipline. Not less

#127

Earlier quoted context omitted.

I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC. LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.

I really can't agree with this. Sure pure LoC is a bad metric. But there is a correlation between output and LoC. Outside of a very senior developer, maybe a Principal or Lead that is spending all day in architecture meetings and reviewing PRs, most high performers are also outputting code.

"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".

Re: AI demands more engineering discipline. Not less

#128
We don't even have to go that deep: If anything accelerates our rate of code change, but doesn't lower our incidents per change, we are still stuck in a larger pile of incidents, and that's if the code quality is exactly the same as before.

Without more, better testing, hopefully more invariants stored in type systems that are easy to reason about, and more recording of the reasons why we change things, we get a more unstable system in practice. One were fewer people can work at once.

Re: AI demands more engineering discipline. Not less

#129

> Those are not code problems. They are evaluation problems. > Code becomes precious when it is the only place knowledge lives. Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable. Manual programming has this really productive and gratifying feedback loop, where you read the code, write the code, and fix it until it comp…

It almost seems like the juice might not be worth the squeeze. If you want verifiable code that conforms well to a well-designed plan, you have to basically write pseudocode and have the AI translate it for you. At that point why use the AI to write the code at all? And then, personally, I find that I just have more fun planning, writing, and debugging myself. I think its kinda the part of programming that I fell in love with in the first place.

Re: AI demands more engineering discipline. Not less

#130
post #127

Earlier quoted context omitted.

I really can't agree with this. Sure pure LoC is a bad metric. But there is a correlation between output and LoC. Outside of a very senior developer, maybe a Principal or Lead that is spending all day in architecture meetings and reviewing PRs, most high performers are also outputting code.

"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".

Most of us work for business and on teams where performance matters.
Post reply on HN