Ask HN: Is understanding code becoming "optional"?

Post by raw_anon_1111 » Sun, Feb 01, 2026, 5:04 PM UTC

giantg2 wrote: post #40

raw_anon_1111 wrote: post #39

Earlier quoted context omitted.

My thought process during my architecture influences my testing. Since AI has been a thing, I’ve been in a customer facing cloud consulting role - working full time at consulting departments (AWS ProServe) and now a third party company - specializing in app dev. Before my hands actually write a line of code or infrastructure as code, I’ve already spoken to sales to get a high level idea of what the customer wants, re…

"I don’t have to think about what I need to test for." Good luck then. The business process flow including edge cases should arguably be top of mind for what to test. Testing shouldn't be an afterthought but rather an integral thought when writing the code that needs to be tested. "I would have to have two or three more junior people doing the work" Yeah, and they're the ones thinking about testing the code they writ…

If I’m starting off from sales -> reading the contract -> discovery -> design -> project plan -> implementation -> implementation review -> handover, how am I not involved with the business case?

I would never trust a junior developer who is just an experienced ticket taker (and most don’t get their first job after 10 years of being hobbyist) to look in that level of detail. Honestly the code is the least important. What it does is. If I’m 50 years old and still just a “human LLM ticket taker”, I’ve done something horrible wrong in life.

By definition, this is the worse AI coding will ever be, anyone hoping to stay in this game long term by being able to “codez real gud” is going to be in for a rude awakening.

Enterprise development where most developers work was becoming a commodity in 2016 where it was easy to become “good enough” and comp still looks like it did on the high end a decade ago. Now it’s even harder to stand out from the crowd.

Now we are seeing that even BigTech jobs where “I can reverse a b tree on the whiteboard” developers are becoming a disposable commodity with all of the layoffs. There is a reason I’ve been moving up the stack and closer to “the business” over the last decade

Post by dapangzi » Sun, Feb 01, 2026, 10:13 PM UTC

giantg2 wrote: post #38

dapangzi wrote: post #32

Earlier quoted context omitted.

> Not very often > testing This does not match my experience, have been working with LLM since 2023. We presently use the latest models, I assure you. We can definitely afford it. I am not saying LLM is worthless, but being able to check its outputs is still necessary at this stage, because as you said, it is non-deterministic. We have had multiple customer impacting events from code juniors committed without underst…

I had a mid-level submit a PR implementing caching. I had to reject it multiple times . They were using Copilot and it couldn't implement it right and the developer couldn't understand it. Stuff like always retrieving from the API instead of the cache, or never storing the object in the cache after retrieving it. They promoted that guy over me because he started closing more stories than me and faster after he starte…

This matches my experience so hard that I wrote a novel below, have seen this pattern a lot, wanted to expand so people can understand the cycle/pattern.

Let's propose a generic scenario that shows why being able to engineer and read code is still important, and is a story we've all heard or seen a thousand times since the great LLMing of 2025.

"Just deliver the feature/product, we expect `ridiculousMetric` increase in productivity due to LLM" screeching from management and product/business.

A junior engineer will find someone who is willing to rubber stamp their LLM PRs so seniors or designated product experts don't even get a chance to check.

The LLM modifies existing tests to game everything to pass, the junior doesn't know any better, and so it quietly makes it to prod.

Because management is thinking in sprints, the way they see it, the ticket is closed, it's a win.

Then the broken production code, which junior will eventually be promoted for because the ticket is closed on paper, breaks prod, causes a huge outage costing `hugeNumber` dollars to the organization, and senior engineers have to clean it up. To boot, the spend metric is trash because of the LLM not knowing how to scale infra.

Since juniors can't meaningfully debug due to the toxic cycle, seniors spend too much time cleaning things up and it blocks their deliverables, and seniors look bad to leadership. Then they get managed out for not delivering, while the juniors lacking engineering experience due to the toxic cycle continue to rise through the ranks for delivering, even though their deliverables are trash.

I don't blame the juniors, they are under immense pressure and genuinely don't know better. I blame short-sighted leadership.

I've heard this story from contacts at any of the big names you can think of.

It seems US tech industry is flying head-first into having giant teams of mid and senior level engineers who don't know how to debug or deliver efficiency within the next five years.

We're failing our juniors, and punishing seniors for having standards.

Re: Ask HN: Is understanding code becoming "optional"?

Re: Ask HN: Is understanding code becoming "optional"?