AI demands more engineering discipline. Not less

Posted by BerislavLopac 1 hour ago

Comments

Comment by ryandvm 3 minutes ago

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 the sun with perfect formatting and at least superficial plausibility. This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible, but it's also just a game theory respopnse because it's in every engineer's best interest to be as prolific as possible.

We are absolutely drowning in documentation and code that seems legit and the only recourse is to lean on AI to help process the sheer quantity of it. I have a feeling that the fallout from this phase of the industry is going to be an exotic form of technical debt that is remarkable mostly in its enormity.

Comment by blensor 1 minute ago

Maybe the solution is to look out for the most silent engineers. Those that output less despite having the ability to create near infinite output.

Comment by msteffen 19 minutes ago

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, reading the code is much easier because you can guess why things were done the way they are.

Also, this blog post has gotten popular: https://blog.gpkb.org/posts/just-send-me-the-prompt/

I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.)

What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into is current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.

Comment by molsongolden 5 minutes ago

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 what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.

This is the way but plenty of engineering teams don't have any human docs at all. Decisions are made in one engineer's head or in a chat that isn't saved. The spec was just a few notes in a ticket that was deleted during cleanup or lost when the team changed trackers. There's no map of the codebase or features, no ADRs, minimal observability. All you have is the code. You read the code to try and figure out what is going on then ping an engineer who made a recent commit to a specific area to ask if they remember why something was done the way it was. Someone makes a change and it breaks something on the other side of the codebase that they thought was totally unrelated, etc.

Comment by e12e 47 minutes ago

Great article. I'm not sure the author is correct - but I think something is happening to the adage:

> A sufficiently detailed specification is runnable code.

In a way I think LLMs will enable the dream of 4gl and "sufficiently smart compilers"[c].

LLMs aren't smart, but they are capable. Especially capable of translation and transformation.

I can certainly see them help move the abstraction horizon at which we work - so that rigid high level descriptions of the desired logic/process along with the process for quality testing - become the relevant curated artifacts - and the generated go/rust/java/python/etc code become incidental and mutable; subject to constant rewriting as part of the deployment of systems.

[c] You know, the ones that take naive C/C++ and produce executables that fully leverage RISC/EPIC platforms to be better than CISC. See also: Intel Itanium

Comment by glouwbug 17 minutes ago

This is what Anthropic did with agents and $20k to write a C compiler that survived gcc’s torture suite. But the LLM knew:

1. What a C compiler was

2. What a C compiler looked like

3. What the C compiler had to do at runtime to pass gcc’s torture suite through some sort of collaborative iteration (compile, run, did it get stuck at some torture suite test or fail?)

Remove 1 and 2, or replace it with imperfect business logic, and you’re left with a system that is built to _only_ pass the tests you supply it, or in the most extreme case, print(“unit and functional tests pass!”)

Comment by sdicker 1 minute ago

Thanks, great to have the perspective of thoughtful engineers who have been in the trenches for a long time

Comment by glouwbug 1 hour ago

Before 2023 I remember everyone here on HN championed that removing lines of code was the strongest senior metric

Comment by hashmap 27 minutes ago

arent they still? or at least a lot. its too much current to win the swim race against the deluge of llm LOC. but i also disagree with some of the things the author just casually lays out, which is whether the LLMs can write good code. they write working code, but it looks written by a demogorgon and i get a bit ill seeing it. its bad but not bad in a way that a human would ever write, like i dont get that kind of sick reading spaghetti code written by new devs. it's a kind of sick like cthulhus eggs are hatching somewhere in your guts.

Comment by bluGill 36 minutes ago

Removing lines of code without removing functionality.

Comment by esafak 36 minutes ago

Simplification is still good. I remember one senior that only removed code when he joined my company until he became a manager!

Comment by ezoe 11 minutes ago

I have a doubt that one of Three Virtues of a Programmer, laziness is still considered a virtue on AI coding era.

Now that AI coding speed and performance outperformed most of human. But AI still need human to be commanded. Yes, you can let AI agent manage sub-agents but still, human is at the top of manager who order AI what should be written.

So human must command and final say on when it's done.

Is laziness still a good virtue in AI era?

Comment by workbox 1 hour ago

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.

Comment by argee 59 minutes ago

I'm not sure this article had enough thought put into it. For example:

    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.

It's not so much as "the economics [...] were turned upside down", but that a manufacturing process that used to be strictly additive (akin to 3D printing) is now complemented by a subtractive process (akin to CNC milling). The "shape" that is demanded hasn't really changed, and nor has the human effort (as long as you care about achieving certain tolerances). You still have to "treasure, reuse, care for, and curate" your product to whatever degree the market demands.

Also I disagree with:

    Lines of code are not the ideal artifact to review

What does "ideal" mean here? When I was growing up "show your work" was the rule for all examinations. Why? Because we're working to improve mental models and thought processes for the next generation, not just products we will release tomorrow.

Comment by molsongolden 25 minutes ago

I think the point is that there are better engineering artifacts to review instead of lines of code. Encoding the decisions, structure, requirements, testing, monitoring, then reviewing those and having AI generate and regenerate code based on them. The code itself doesn't matter if enough thought and rigor has gone into the structure that produces the code.

> What does "ideal" mean here? When I was growing up "show your work" was the rule for all examinations. Why? Because we're working to improve mental models and thought processes for the next generation, not just products we will release tomorrow.

They're saying that the mental models and thought processes are incredibly important but that code is not the place for that work to live.

Comment by nielsbot 6 minutes ago

meta, but: I gave up. I found the language really hard to follow and the point of the piece didn’t stand out to me. shrug

Comment by ed_elliott_asc 23 minutes ago

I enjoyed it, people post on blogs as a way to entertain themselves, not necessarily the reader.

Comment by romaniv 6 minutes ago

>"It’s easy to forget, but for most of 2025, the idea that AI-generated code was slop and might always be slop was not only a reasonable position to hold, it was the default, mainstream position.

That question was answered decisively last November."

It's easy to forget that people said this exact thing about every model after GPT 3.5. This is one a standard tricks the industry uses to invalidate negative experience with LLMs. 'You are prompting it wrong' becomes 'you are using model X, but you should use model Y' which then becomes 'well, all of your criticism is now irrelevant, because everything is fixed in this new version'.

This "discussion" is set up to be asymmetrical by design.

Comment by wbl 4 minutes ago

The old model couldn't do math, the new one solved a big open problem.

Comment by turtlebro 12 minutes ago

I feel with AI agents the pace of coding has increased so much, it can be a bit exhausting. Previously you worked days on a feature, now it's done in a few hours and then onto the next. But you still need to verify, think, build a mental model of everything that's happening. It's easy to obsess with getting more and more done, but leaves you so overwhelmed and drained at the end of the day. I guess everyone is hyped to the max at the moment, but human attention bottleneck seems real.

Comment by kstenerud 19 minutes ago

This has been my experience with AI.

Writing software begins with a solid design that is defensible. If you don't have that, the AI will produce slop.

Once you're happy with the design, you need a solid plan. If you don't have that, the AI will produce slop.

Once you're happy with the plan, you can set the AI loose, but don't get too complacent! Anything that you missed in the previous phases could very well lead to slop (although likely localized).

And then then, as your project matures and you gain more understanding of the space, you start to notice deficiencies in your model. This is where AI really shines: design and code changes to adapt to reality.

Comment by AndrewKemendo 50 minutes ago

Broadly concur with this and in fact it’s all of this is going to make doing real engineering easier in my opinion

The author makes the wrong assumption though that the majority of people who are doing engineering want to do even more engineering.

It’s my experience that most technology workers just want a high paycheck and have some kind of association with being in tech and doing cool things

Comment by rustystump 16 minutes ago

That is the problem imo. Most tech workers want a big check and no work. Gross. I like the work. But i do get wanting to get a nut with little effort.