After outages, Amazon to make senior engineers sign off on AI-assisted changes

Post by raw_anon_1111 » Tue, Mar 10, 2026, 6:26 PM UTC

sarchertech wrote: post #171

raw_anon_1111 wrote: post #90

Earlier quoted context omitted.

In my experience, inefficient code is rarely the issue outside of data engineering type ETL jobs. It’s mostly architectural. Inefficient code isn’t the reason your login is taking 30 seconds. Yes I know at Amazon/AWS scale (former employee) every efficiency matters. But even at Salesforce scale, ringing out every bit of efficiency doesn’t matter. No one cares about handcrafted artisanal code as long as it meets both…

It’s not about hand crafted code or even code performance. We know from experimentation that agents will change anything that isn’t nailed down. No natural language spec or test suite has ever come close to fully describing all observable behaviors of a non-trivial system. This means that if no one is reviewing the code, agents adding features will change observable behaviors. This gets exposed to users as churn, jan…

Post by ansibsha » Tue, Mar 10, 2026, 6:33 PM UTC

ritlo wrote: post #74

locusofself wrote: post #50

Earlier quoted context omitted.

If you spend 5-15x the time reviewing what the LLM is doing, are you saving any time by using it?

A related Dirty Secret that's going to become clear from all this is that a very large proportion of code in the wild (yes, even in 2026—maybe not in FAANG and friends, IDK, but across all code that is written for pay in the entire economy) has limited or no automated test coverage, and is often being written with only a limited recorded spec that's usually fleshed out only to the degree needed (very partial) as a gi…

Post by johnnyanmac » Tue, Mar 10, 2026, 6:43 PM UTC

bluGill wrote: post #60

ardeaver wrote: post #46

Earlier quoted context omitted.

When I was really early in my career, a mentor told me that code review is not about catching bugs but spreading context (i.e. increasing bus factor.) Catching bugs is a side effect, but unless you have a lot of people review each pull request, it's basically just gambling. The more expensive and less sexy option is to actually make testing easier (both programmatically and manually), write more tests and more levels…

> people don't get promoted for preventing issues. they do - but only after a company has been burned hard. They also can be promoted for their area being enough better that everyone notices. still the best way to a promotion is write a major bug that you can come in at the last moment and be the hero for fixing.

Post by johnnyanmac » Tue, Mar 10, 2026, 6:48 PM UTC

rectang wrote: post #107

marginalia_nu wrote: post #103

Earlier quoted context omitted.

By the time you're working in increments small enough that it doesn't introduce significant issues, you really might as well write the code yourself.

That's not my experience — I'm significantly faster while guiding an LLM using this methodology. The gains are especially notable when working in unfamiliar domains. I can glance over code and know "if this compiles and the tests succeed, it will work", even if I didn't have the knowledge to write it myself.

Post by sarchertech » Tue, Mar 10, 2026, 7:01 PM UTC

raw_anon_1111 wrote: post #181

sarchertech wrote: post #171

Earlier quoted context omitted.

It’s not about hand crafted code or even code performance. We know from experimentation that agents will change anything that isn’t nailed down. No natural language spec or test suite has ever come close to fully describing all observable behaviors of a non-trivial system. This means that if no one is reviewing the code, agents adding features will change observable behaviors. This gets exposed to users as churn, jan…

Thats easy enough to prevent with modular code that’s what “plan mode” is for. But you probably never worked with a bunch of C# developers using R#