Absolutely no one in the value chain cares about “how many layers of abstractions your code has - not your management or your customers. They care about functional and none functional requirements
Of course they don’t. Please reread what I said, give it the slightest bit of thought, and re-respond if you want a response from me.
By definition, coding agents are right now the worse they will ever be and the industry as a whole by definition is the least experienced it will ever be at using then.
So many people on HN are so insulted that the people who put money in our bank accounts and in some cases stock in our brokerage accounts ever cared about their bespoke clean code, GOF patterns and they never did. LLM just made it more apparent.
It’s always been dumb for PR to be focused on for loops vs while loops instead of focusing on whether functional and non functional requirements are met
>Junior and mid-level engineers can no longer push AI-assisted code without a senior signing off Review by a senior is one of the biggest "silver bullet" illusions managers suffer from. For a person (senior or otherwise) to examine code or configuration with the granularity required to verify that it even approximates the result of their own level of experience, even only in terms of security/stability/correctness, r…
The goal of Sr code review is not to make the code better, it's to make the author better.
That's not going to work when the author is an LLM
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.
With tens of thousands in a meeting, cracking a 30-second stupid joke is probably costing several thousand dollars.
It's worth 10x that because they are all AI powered super devs now /sarc
If they do not also increase the senior devs’ allotted time for code reviews to make up for the increased volume of changes due to increased productivity of the junior to mid level devs, or hire more seniors, this will just lead to burnout (on top of Amazon’s already high levels) and scapegoating seniors for having waved through a change because they materially can’t review them fast enough.
And guess what? You probably don’t pay as much as I make now either… Even in late 2023 with the shit show of the current market, I had no issues having multiple offers within three weeks just by reaching out to my network and companies looking for people with my set of skills.
I field a small team of experts who are paid upwards of a million GBP in cold-hard cash in London. Not stock. Cash. You sound like a bozo, I can sniff it through my screen.
The optics here are really bad for Amazon. The continuing mass departures of long tenured folks, second-rate AI products, and a string of bad outages paints a picture that current leadership is overseeing a once respected engineering train flying off the tracks. News from the inside makes it sound like things are getting pretty bad.
> The continuing mass departures of long tenured folks
You mean senior programmers that have been there for ages don't want to spend their time reviewing AI slop? Who'd a thunk it!
You could create an agent template for each incident you've ever had, with context pre-cached with the postmortem report, full code change, and any other information about the incident. Then for every new PR you could clone agents from all those templates and ask whether the PR could cause something similar to the pre-loaded incident. If any of them say yes, reject the PR unless there's a manual override. You'd never have a repeat incident.
Obviously it's probably cost-prohibitive to do an all to all analysis for every PR, but I imagine with some intelligent optimizations around likelihood and similarity analysis something along those lines would be possible and practical.
>Junior and mid-level engineers can no longer push AI-assisted code without a senior signing off Review by a senior is one of the biggest "silver bullet" illusions managers suffer from. For a person (senior or otherwise) to examine code or configuration with the granularity required to verify that it even approximates the result of their own level of experience, even only in terms of security/stability/correctness, r…
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…
I think of code review more about ensuring understandability. When you spend hours gathering context, designing, iterating, debugging, and finally polishing a commit, your ability to judge the readability of your own change has been tainted by your intimate familiarity with it. Getting a fresh pair of eyes to read it and leave comments like "why did you do it this way" or "please refactor to use XYZ for maintainability", you end up with something more that will be easier to navigate and maintain by the junior interns who will end up fixing your latent bugs 5 years later.
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, a…
> 2. Having Less comments on their PRs: for some drastically dumb reason, having a PR thoroughly reviewed I'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 softwa…
I've been involved in so many CRs where I've given feedback over 10 revs, then the submitter cancels the CR and files a new one, for the metrics.