Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI demands more engineering discipline. Not less

charitydotwtf.substack.com

Post reply on HN
Print view View original

91–100 of 234 posts

Re: AI demands more engineering discipline. Not less

#91

Post by jtbayly »

hhjinks wrote: post #84
banannaise wrote: post #77

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.

Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.

Re: AI demands more engineering discipline. Not less

#92

Post by roncesvalles »

philbo wrote: post #33
trjordan wrote: post #27

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

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 expected of you.

Re: AI demands more engineering discipline. Not less

#93

Post by sdesol »

mooreds wrote: post #30
trjordan wrote: post #27

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

Are there any products out there that are capturing the prompts/sessions? I imagine you could do it in an adhoc way, asking Claude to write up a summary of the session as part of the commit message. But is there anything else that's more structured/higher level?

I am working on solving the AI Code Provenance problem and I believe my repos may be the first that provides AI code provenance. See the following example:

https://github.com/gitsense/gsc-cli/blob/main/internal/cli/r...

Notice how the code block header attributes the model. The UUID can be traced to the conversation so everybody can tell exactly how the code came about. For this to work though, you need to use my chat app as it ensures you can't tamper with things if you are truly serious about AI code provenance.

I also have a lot more human-focused method which is part of my CLI tool.

https://github.com/gitsense/gsc-cli

I am currently looking at making pi (https://github.com/earendil-works/pi) support AI code provenance, but for now if you want a more structured way to capture what you have done in an agent session that can be used in code reviews and be carried forward as knowledge that lives inside your repository, I have

gsc lessons

The basic idea is, after you have finished chatting/working with the agent, you would work with it to identify lessons worth carrying forward. You can store your session if you want, but really, the lessons should be something that can help you review code better and to prevent future mistakes.

I have a real working example at

https://github.com/gitsense/smart-ripgrep

This is a fork of the BurntSushi/ripgrep repository. It shows how you can use lessons to learn from past design decisions.

Re: AI demands more engineering discipline. Not less

#94

Post by molsongolden »

sublinear wrote: post #31
molsongolden wrote: post #22

Earlier quoted context omitted.

I wonder if the reception is so variable due to differing exposure to 1) infra as code and 2) engineering teams that don't produce any artifacts outside of their code. > 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 w…

Talking to an LLM is often still a lower quality result than asking the lead engineer themselves or the collaborators they left behind. You're making a tradeoff between time taken and result quality. Even the most AI-positive teams prefer human discussion when things get that tough. Given enough time, things will "click" for humans. LLMs don't work that way. Even a team of all-new unfamiliar devs forced to study an o…

Agreed and I think the author agrees with this too. One of the ideas is that the devs should be discussing and documenting their intent outside of the code then letting AI tools generate the code as specified. "Engineering" should occupy the time that was previously occupied by "coding" and the context and writing should exist as intentional written context, not just poorly documented code.

Re: AI demands more engineering discipline. Not less

#95

Post by keybored »

trjordan wrote: post #27

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

Flintstone Engineering is applying Space Age synthetic intelligence (in a metaphorical sense) technology with code generation. Babysitting, version controlling, etc. generated code should be a thing of the past. But that is what GenAI is.

At the very least apply it at a higher level: specification, proofs, anything but generating Rust/Java/C and then letting yourself or an agent babysit it.

Re: AI demands more engineering discipline. Not less

#96

Post by tj-teej »

strix_varius wrote: post #42
ryandvm wrote: 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.

"Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts"

I'd simplify to "Truly capable engineers are able to achieve more positive outcomes" - half of what makes a capable, dependable engineer is knowing what outcomes are needed and making them happen.

Re: AI demands more engineering discipline. Not less

#97

Post by evdubs »

fusslo wrote: post #68
trjordan wrote: post #56

Earlier quoted context omitted.

I think it's worse than that. At least if I dumped 5k LoC on somebody in 2021, you knew I spent the time to write it, so it's "fair" to ask you to read it. But I didn't write it in 2026, so you shouldn't read it. I think it's less about "break it down" and more about "let's communicate at the same altitude." I wrote a (bait-titled) post about it: https://tern.sh/blog/stop-reading-prs/

113 files +22913 −2423 305 files +15075 −13110 153 files +21934 −8698 125 files +28120 −2398 43 files +11188 −63 118 files +21564 −647 These are the largest (6 of 35) in the past 30 days. added: 190079 removed: 39696 in the last 6 months from one person.

I hope 99% of that was documentation and testing.

Re: AI demands more engineering discipline. Not less

#98

Post by hintymad »

ryandvm wrote: 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…

Eh, are you using the loop engineering effectively? Remember, Boris can merge more than 200 PRs a week mostly with merely a phone and despite his busy schedule. Anthropic engineers do not write code manually any more, and they don't need to review most of the code either.

In all seriousness, though, I'm indeed curious about Anthropic's engineering practice, particular how they can achieve such level of autonomy.

Re: AI demands more engineering discipline. Not less

#99

Post by thisisit »

ryandvm wrote: 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…

There are also people who think AI is magic. I have often heard - "we want to use AI to automate processes but we don't have full documentation about the processes, we hope AI can help". Despite being told that no one can create outputs from thin air - every AI topic turns into the same discussion.

Often the solution to create those document to feed into these AI automations? Use AI. Its like ouroboros. Create docs using AI, then summarize and ingest using AI, explained by AI.

Same thing is going to happen with code. Create 1000s of line of code using AI. Then explain it using AI etc.

Re: AI demands more engineering discipline. Not less

#100

Post by vyaa »

LtWorf wrote: post #53
hungryhobbit wrote: post #41

Earlier quoted context omitted.

Ok, I like the idea and support that seniors value simplicity ... but how the hell do you stay employed for even a month (let alone until "manager time") without writing any code?

You don't just delete stuff… it's more that your pull requests remove more lines than they add. But I'm sure the person you're replying to is exaggerating, or they got promoted because of completely unrelated reasons.

It’s pretty common for me to deliver a feature while removing more lines than I added in React. Just so many useless useEffects and states and divs. The caveat is I have to be allowed to refactor related code.

I find it’s less common for me in ruby, even refactoring bad ruby. Sure I can remove lines but bad JS/React balloons so fast.

My current org values this and my direct boss constantly praises those of us that try to remove more lines than we add. Very refreshing.

Post reply on HN