Discussion

raw_anon_1111: My last project was basically an ETL implementation on AWS starting with an empty AWS account and a internal web admin site that had 10 pages. I am yada yada yadaing over a little bit.What I checked.1. The bash shell scripts I had it write as my integration test suite2. To make sure it wasn’t loading the files into Postgres the naive way -loading the file from S3 and doing bulk inserts instead of using the AWS extension that lets it load directly from S3. It’s the differ xe between taking 20 minutes and 20 seconds.3. I had strict concurrency and failure recovery requirements. I made sure it was done the right way.4. Various security, logging, log retention requirementsWhat I didn’t look at - a line of the code for the web admin site. I used AWS Cognito for authentication and checked to make sure that unauthorized users couldn’t use the website. Even that didn’t require looking at the code - I had automated tests that tested all of the endpoints.

newobj: Speed of code-writing was never the issue at Amazon or AWS. It was always wrong-headed strategic directions, out to lunch PMs, dogshit testing environment, stakeholder soup, high turnover, bureaucracy, a pantheon of legacy systems, insane operational burdens, garbage tooling, and so on...Imagine if the #1 problem of your woodworking shop is staff injuries, and the solution that management foists on you is higher RPM lathes.

recursive: The TSA Pre-check monetization model

AlexeyBrin: I wonder how this will work in practice. Say I'm a senior engineer and I produce myself thousands of lines of code per day with the help of LLMs as mandated by the company. I still need to presumably read and test the code that I push to production. When will I have time to read and evaluate similar amounts of code produced by a junior or a mid level engineer ?

MichaelRo: >> I wonder how this will work in practice. Say I'm a senior engineer and I produce myself thousands of lines of code per day with the help of LLMs as mandated by the company.LOL, it's the age old "responsibility without authority". The pressure to use AI will increase and basically you'll be fired for not using it. Simultaneously with the pressure to take the blame when AI fucks up and you can't keep up with the bullshit, leading you to get fired. One way or the other, get some training on how to stack shelves at the supermarket because that's how our future looks, one way or the other.

prakhar897: From the amazon I know, people only care about a. not getting fired and b. promotions. For devs, the matrix looks like this:1. Shipping: deliver tickets or be pipped.2. Having Less comments on their PRs: for some drastically dumb reason, having a PR thoroughly reviewed is a sign of bad quality. L7 and above use this metric to Pip folks.3. Docs: write docs, get them reviewed to show you're high level.Without AI, an employee is worse off in all of the above compared to folks who will cheat to get ahead.I can't see how "requesting" folks for forego their own self-preservation will work. especially when you've spent years pitting people against each other.

embedding-shape: > 2. Having Less comments on their PRs: for some drastically dumb reason, having a PR thoroughly reviewedI'm very far away from liking Amazon's engineering culture and general work culture, but having PRs with countless of discussions and feedback on it does signal that you've done a lot of work without collaborating with others before doing the work. Generally in teams that work well together and build great software, the PRs tend to have very little on them, as most of the issues were resolved while designing together with others.

riknos314: The technique of creating specs before implementation that Kiro embodies was used widely internally before Kiro's release, but as a (now former) employee I gained access to the Kiro tool at the same time as the public. Others may have had internal access earlier but I'm not aware of them.

age1mlclg6: What has really happened is that those employees were made into "reverse centaurs":https://www.theguardian.com/us-news/ng-interactive/2026/jan/...

cmiles8: The core message of the article is that Amazon has been having issues with AI slop causing operational reliability concerns, and that seems to be 100% accurate.

coredog64: /with AI slop//

embedding-shape: > This meeting happens literally every week, and has for years. Feels like the media is making a mountain out of a mole hill here.Are you completely missing the point of the submission? It's not about "Amazon has a mandatory weekly meeting" but about the contents of that specific meeting, about AI-assisted tooling leading to "trends of incidents", having a "large blast radius" and "best practices and safeguards are not yet fully established".No one cares how often the meeting in general is held, or if it's mandatory or not.

skeeter2020: >> Are you completely missing the point of the submissionno, and that's what people are noting: the headline deliberately tries to blow this up into a big deal. When did you last see the HN post about Amazon's mandatory meeting to discuss a human-caused outage, or a post mortem? It's not because they don't happen...

thepasch: > the headline deliberately tries to blow this up into a big dealI do not understand how “company that runs half the internet has had major recent outages and now explicitly names lax/non-existent LLM usage guidelines as a major reason” can possibly not be a big deal in the midst of an industry-wide hype wave over how the world’s biggest companies now run agent teams shipping 150 pull requests an hour.The chain of events is “AWS has been having a pretty awful time as far as outages go”, and now “result of an operational meeting is that the company will cut down on the use of autonomous AI.” You don’t need CoT-level reasoning to come to the natural conclusion here.If we could, as a species, collectively, stop measuring the relevance of a piece of news proportionally by how much we like hearing it, please?

coredog64: There's an explicit tension: SWEs would love that as a "get out of jail free" card, but their management chain is being evaluated by ajassy on AI/ML adoption. Admitting AI code as the root cause of a CoE is gonna look really bad unless/until your peers are also copping to it.

readthemanual: a) what happens if there is change that hasn't been encountered yet so it's not in .agentnotallowed? b) is there a guarantee that something described in these files won't be touched? I've seen examples when agents directly violate these rules, profusely apologising after they get caught on it.

mhogers: allowlist instead of denylist, depending on your risk profile :)

BigTTYGothGF: > It says he “asked” staff to attend the meetingBeing "asked" by your boss to attend an optional meeting is pretty close to being required, it's just got a little anti-friction coating on it.

ragall: Exactly. It's just West coast passive aggressive managerial behavior.

hintymad: > Review by a senior is one of the biggest "silver bullet" illusions managers suffer fromEspecially in a big co like Amazon, most senior engineers are box drawers, meeting goers, gatekeepers, vision setters, org lubricants, VP's trustees, glorified product managers, and etc. They don't necessarily know more context than the more junior engineers, and they most likely will review slowly while uncovering fewer issues.

marginalia_nu: Machine code is still code, even if the representation is a bit less legible than the punch cards we used to use.

ChrisArchitect: Previously: https://news.ycombinator.com/item?id=47319273

munk-a: Reviewing code changes (generally) takes more time than writing code changes for a pretty significant chunk of engineers. If we're optimizing slop code writing at the expense of more senior's time being funneled into detailed reviews then we're _doing it wrong_.

dboreham: Bingo. Hopefully there are some business opportunities for us in that truth.

mattgreenrocks: The defensiveness is almost as interesting as the meeting itself.

rossdavidh: As Deming once said in regard to manufacturing inspections: "Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product."The fact that software is "soft" makes it seem like this doesn't apply, but it does, not least because of the fact that once you have gone down the wrong path with software design, it is very difficult to pull back and realize you need to go down an entirely different one.

cobolcomesback: That really isn’t the culture at Amazon. There are all-team meetings that happen all the time, and every now and then there is a reminder that “hey we’re gonna be talking about an interesting topic so you might want to join”, but it is certainly not a mandate or expectation that everyone will join.Different companies have different cultures. Weird that people can’t grok this.

dboreham: 4. Don't work in the corporate equivalent of The Hunger Games.

mikkupikku: lgtm

MDGeist: A former colleague of mine recently took a role that has largely turned out to be "greybeard that reviews the AI slop of the junior engineers". In theory it sounds workable, but the volume of slop makes thoughtful review impossible. Seems like most orgs will just put pressure on the slop generators to do more and put pressure on the approvers and then scape goat the slop approvers if necessary?

dboreham: This was always the case in the before times with humans. AI just pulls back the curtain on the delusion that code can and is being meaningful reviewed.

bonesss: That’s the reverse-centaur issue I see: humans are not great at repetitive nuanced similar seeming tasks, putting the onus on humans to retroactively approve high volumes of critical code has them managing a critical failure mode at their weakest and worst. Automated reviews should be enhancing known good-faith code, manual reviews of high volume superficially sound but subversive code is begging for issues over time.Which results the software engineering issue I’m not seeing addressed by the hype: bugs cost tens to hundreds of times their coding cost to resolve if they require internal or external communication to address. Even if everyone has been 10x’ed, the math still strongly favours not making mistakes in the first place.An LLM workflow that yields 10x an engineer but psychopathically lies and sabotages client facing processes/resources once a quarter is likely a NNPP (net negative producing programmer), once opportunity and volatility costs are factored in.

demosito666: > Even if everyone has been 10x’ed, the math still strongly favours not making mistakes in the first placeThe math depends on importance of the software. A mistake in a typical CRUD enterprise app with 100 users has zero impact on anything. You will fix it when you have time, the important thing is that the app was delivered in a week a year ago and was solving some problem ever since. It has already made enormous profit if you compare it with today’s (yesterday’s ?) manual development that would take half a year and cost millions.A mistake in a nuclear reactor control code would be a total different thing. Whatever time savings you made on coding are irrelevant if it allowed for a critical bug to slip through.Between the two extremes you thus have a whole spectrum of tasks that either benefit or lose from applying coding with LLMs. And there are also more axes than this low to high failure cost, which also affect the math. For example, even non-important but large app will likely soon degrade into unmanageable state if developed with too little human intervention and you will be forced to start from scratch loosing a lot of time.

Barrin92: to be fair senior engineering leads in the software world are like Voltaire's joke about the holy roman empire, neither holy, roman or an empire.Despite the name not a lot of seniority, leadership or engineering going around

djb_hackernews: When an SVP asks you to do something in a mass email, it's very much optional. Dave Treadwell is an SVP, his org is likely in the 10's of thousands, there is no way to even have a mandatory meeting for that many people.My SVP asks me to do things all the time, indirectly. I do probably 5% of them.

javcasas: With tens of thousands in a meeting, cracking a 30-second stupid joke is probably costing several thousand dollars.

bluefirebrand: > we’re doing the industrial equivalent of eating our seed corn and there is seemingly no will to slow that trend down, much less reverse it.I know I'm probably coming across as a lunatic lately on HN but I really do think we're on the path towards violence thanks to AIYou just cannot destroy this many people's livelihoods without backlash. It's leading nowhere goodBut a handful of people are getting stupidly rich/richer so they'll never stop

bluGill: I have found ai extreemly good at finding all those really hard bugs though. Ai is a greater force multiplier when there is a complex bug than in gneen field code.

danjl: Yes, more time on up front spec and plan building. Bite sized specifically to fit within the context window of a single implementation session. Each step should have a verification process that includes new tests.Prior to each step, I prompt the AI to review the step and ask clarifying questions to fill any missing details. Then implement. Then prompt the AI after to review the changes for any fixes before moving on to the next step. Rinse, repeat.The specs and plans are actually better for sharing context with the rest of the team than a traditional review process.I find the code generated by this process to be better in general than the code I've generated over my previous 35+ years of coding. More robust, more complete, better tested. I used to "rush" through this process before, with less upfront planning, and more of a focus on getting a working scaffold up and running as fast as possible, with each step along the way implemented a bit quicker and less robustly, with the assumption I'd return to fix up the corner cases later.

js8: That's the incidental (necessary) vs accidental (avoidable) complexity distinction. But I don't think it makes it any easier to deal with.

bluGill: those are different things. Often you don't plan for all the necessary things and so it doesn't fit in - even though a better design evists that would have it fit in neater - but only years latter do you see it and getting there is now a massive effort you can't afford. The result looks sloppy because on hindsight right is obvious

ForHackernews: >while plenty of Juniors that put in a lot of time using code agents will transition.But will they? I'm not at all convinced that babysitting an AI churning out volumes of code you don't understand will help you acquire the knowledge to understand and debug it.

m3kw9: A year later, they will require AI to sign off engineer changes.