[deleted]
AI demands more engineering discipline. Not less
201–210 of 234 posts
Re: AI demands more engineering discipline. Not less
#202It's good to see the hype around "programmers are no longer needed" giving way to a more realistic view. Generating lines of code was never the hardest part of engineering. What's much harder is understanding exactly what we're building, how it integrates with legacy systems, and making sure it doesn't crash the database under load
Re: AI demands more engineering discipline. Not less
#203It 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.
Good code is absent code
LLMs by nature work like autocomplete on steroids. They're always trying to write more than necessary to please the prompt. Seniority now is measured by the ability to break down a task so that the agent doesn't even think to drag in unnecessary abstractions
Re: AI demands more engineering discipline. Not less
#204Earlier 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…
[dead]
Re: AI demands more engineering discipline. Not less
#205Earlier quoted context omitted.
Written exactly like that, yours is obviously cleaner. But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.
There were no comments. If there were comments for each conditional, it should still be refactored as return a || b // comment 1 || c // comment 2 // long comment 3 // on multiple lines || d; Many years ago, "lines of code" was the classic example of nonsense management metrics. Today, there are somehow HN users who argue that lines of code is indeed a good metric and ask "But what if the code had comments?" as if th…
That's still going to make it hard to read. I'd have one big comment above talking about the different cases and then one line of code. Even with the slightly higher risk of getting code and comment out of sync. But that context switch between code and comments you need when you read this one return are pretty awful.
Re: AI demands more engineering discipline. Not less
#206Earlier 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.
It's all about YAGNI. Programmers try to be smart covering cases no one thought about, reviewer is happy that corner cases have been implemented, artificial tests report all good. But it's just more to read when you have to change the code.
Re: AI demands more engineering discipline. Not less
#207Earlier 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.
Deleted code is debugged code.
Re: AI demands more engineering discipline. Not less
#208Earlier quoted context omitted.
Not sure how to understand that. You mean as the best engineers? Funnily at my company, the few engineer that did the majority of the work before AI still do the majority of the work now. By majority I mean tackling both more issues and better. However there is a general verboseness and over engineering trend across the board.
Kind of yes. The person who does not spam the messages. What I noticed for myself is that saying no to something is becoming harder by the day because, why wouldn't you try something if it's so cheap to do. That makes having the strength to say no almost a quality in and of itself. That is true both for external pressure and internal pressure.
Saying "no" as in "this makes no sense" is not the same as "give it to another team". The first can be an engineering take while the second is just politics.
Re: AI demands more engineering discipline. Not less
#209Articles like this are exactly why I doubt that SWE jobs are going away. The SWE job of 2026 doesn't look like one from 2020, let alone 1990 so why would anyone believe the false dichotomy that either the SWE jobs of 2026 will remain or all be eliminated? I worked at Google a zillion years ago when the idea of reviewing all code was novel. Before that, when I worked at MS things mostly didn't get reviewed until the end of the project when the stakes were high because code got burned onto a CD and put in a box. The way SWEs spent their time changed radically from 2000 to 2004 and I think for the better since it increased shared understanding and fostered more collaboration.
If AI writes the code and humans spend more time reviewing it, that might not be a bad thing, but when the AI code is good enough, people are going to view thorough reviews as optional. Then the job of a SWE will look very, very different than before since SWEs won't write much code or spend much time reviewing it. The IDE may go the way of the dodo. And maybe the focus will move to setting up the goals and tests that keep the AI coding team on task. Maybe SWEs will spend more time architecting since they're likely to know where projects are heading and won't want AI to rewrite things as goalposts legitimately move. Maybe more will be spent exploring: build it one way and another and another and compare and generate new ideas from the different approaches.
I have no better idea than anyone else, but I'd be heavily against the role going away and in favor of it evolving, like it's done many times before, though perhaps never as rapidly as it is right now.
Re: AI demands more engineering discipline. Not less
#210Earlier quoted context omitted.
I don’t know. I mean, I agree with you overall, but it seems like tons of engineers, especially here on HN, have been more than willing to go all-in on AI for at least the past year, with many dire warnings of “coding is a solved problem,” “if you’re not programming swarms of agents, you’re going to be left behind,” and so on. This has not been my experience with my fellow engineers IRL on average, but I do feel like…
A lot of people who write code aren't professional SWEs. A lot of professional SWEs especially on Blind aren't typical SWEs at typical companies. A lot of people who claim to write code are lying. I mean would you take Gary Tan as a valid datapoint for how effective AI is at professional SWE coding? I wouldn't. But these are the kind of people who shill it the most on HN. Also, I suspect that a lot of HN comments tha…
There's also a lot of people whose jobs involve sitting in 3 hours meeting to decide where to add another textbox to the website, and that will then create a ticket to create the textbox, have a meeting to estimate the creation of the textbox, have several meetings with the design team about the placement and size of the textbox.
Some teams are incredibly inefficient. And in the end the AI is perfectly capable of creating the textbox.