Live data from Hacker News

AI demands more engineering discipline. Not less

charitydotwtf.substack.com

71–80 of 234 posts

Re: AI demands more engineering discipline. Not less

#71
post #24

It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under…

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.

• LoC/LOC = Lines of Code

• sloc = Source Lines of Code

.. so I suppose nloc would mean Net LoC

Re: AI demands more engineering discipline. Not less

#72
post #55

Earlier quoted context omitted.

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.

> 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. Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them. The idea that "I would have written a shorter letter, but I did not have the time" also applies to code, and som…

> Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them.

Huh? If LoC weren't needed then adding them was unnecessary and a waste of time. Someone who is known at an organization for removing unnecessary code screams inefficiency to me. It's paying one person to create a mess then another to clean it up.

Re: AI demands more engineering discipline. Not less

#73

I 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 of tools like the back of your hand.

* ASan

* LSan

* UBSan

* TSan

* GDB

etc... God forbid if you needed to manually read DWARF files. Unless you're a pure genius, this is not feasible to master in a short amount of time. And in parallel, you need to learn how to design systems, too, otherwise, you're still not very good, and that's an almost completely orthogonal skillset.

Now, you simply need to be aware of the hazards in your language/framework, tell your LLM to test for them, have the infrastructure set up to see if they've adequately tested for those hazards, and maybe read the actual tests and implementation.

It is pretty easy to be able to read and understand Rust compared to debugging all the sorcery-like errors that come during Rust development... It is easy to see that you need a Loom test for certain scenarios, and to write a tool to detect if you did it.

Even if you're still working in C or Zig, it far easier to know and detect when you need to use those tools then to learn to use them all individually.

It is not hard to learn to read SQL. Almost ~50% of business professionals can. Python is barely harder. Rust can look like sorcery if you don't read a 50 page guide to understand to read it, but that's a VERY small price to pay compared to spending ~10 years learning the craft painfully by trial and error.

I'm not sure how you get from "LLMs work in mysterious ways" to "So we need more discipline" to "everything is fine."

I agree that everything is fine. I just don't think this is the clear path and thought process.

Anyone who has the determination to get things to actually work, and takes a little bit of time to understand what makes them not, should be able to leverage LLMs to work wonders.

In my opinion, LLMs are going to make things far more complicated, because the cost of building something complicated is becoming almost free.

Engineering was always about discipline and getting things to work. But you needed a set of prerequisite skills to have much value. Most of those are gone now.

It is simply far easier than before. It does require discipline, yes. But discipline is cheap compared to ~10 years of trial by fire.

Re: AI demands more engineering discipline. Not less

#74
post #72

Earlier quoted context omitted.

> 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. Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them. The idea that "I would have written a shorter letter, but I did not have the time" also applies to code, and som…

> Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them. Huh? If LoC weren't needed then adding them was unnecessary and a waste of time. Someone who is known at an organization for removing unnecessary code screams inefficiency to me. It's paying one person to create a mess then another to clean it up.

> Huh? If they weren't needed then adding them was unnecessary and a waste of time.

My previous reply already addressed this?

I can't help but think you are being purposefully obtuse if you can't acknowledge the concept of developers creating known (and hopefully temporary) technical debt due to various forms of deadline related time pressure or changing requirements.

Re: AI demands more engineering discipline. Not less

#75
> 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've been thinking about this a whole lot recently. So much of my intuition about software development is based on 25 years of accumulated experience on how long it will take to write different bits of code.

Should I add validation for this one edge-case which won't break everything but will make a little bit of a mess if someone hits it? If that's an extra couple of hours of code I might skip it. If it's one more prompt, why wouldn't I?

This new feature would be a lot easier to understand if there was a custom API explorer for it. There's no way I could justify investing in that... unless it's just 10 minutes with Codex, and it was: https://tools.simonwillison.net/datasette-extras-explorer#ur... (linked from the release notes https://docs.datasette.io/en/latest/changelog.html#extra-sup...)

That's just on the small scale. There are entire projects that I'd never previously have considered, because I don't need a custom SQLite SELECT query parsing library enough to justify spending a week or more building one. But now... https://github.com/simonw/sqlite-ast

People get VERY upset (and condescending) any time you suggest that being able to produce lines of code faster is a valuable thing. And sure, measuring output through "lines of code" is stupid.

But measuring "lines of verified code that deliver valuable" isn't stupid at all. That's the thing we can do faster now.

Re: AI demands more engineering discipline. Not less

#76
I read the article, and it seems she is forgetting the aphorism "all models are wrong". This is a common mistake that people who like "realistic" "simulation" RPGs often make. Any suitably comprehensive model of a thing is just the thing itself. To have a model of a location that includes all the detail of the actual location, you would need a 1:1 scale model, which is just a copy of the location. Any plan (i.e. prompt to a model) sufficiently capable of reliably replicating 100% of the functionality of a system is likely the source code of the system itself.

Re: AI demands more engineering discipline. Not less

#77
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.

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.

Re: AI demands more engineering discipline. Not less

#78
post #70

Earlier quoted context omitted.

> The most effective contributors at your job remove more code than they add Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks) > Every line of code removed is a line that was previously added Yes. This os not a failure. Code has a surprisingly short half-life.

It’s not a failure that resources were spent writing code that was not needed?

Maybe it was temporarily needed, but the assumptions around it has changed and now it's unneeded. Then people built on top of that not understanding that they could simplify the whole system, and only later was that option discovered.

What would you keep from this?

Re: AI demands more engineering discipline. Not less

#79
post #3

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

The intro lobbed up a clear cut point of contention for the article to address. I found the following writing to loose steam on that point. I turned to skimming, and did not manage to find a conclusion.

I suspect the stance they described as one readers mistakenly took away from their previous article to in fact be their stance. Otherwise why dance around it so hard?

Re: AI demands more engineering discipline. Not less

#80
post #24

It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under…

> It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around.

It's okay, I'm sure the algorithm questions during the interview phase totally weeded out the fakers of systems knowledge right?

Post reply on HN