AFAICT, it applies to everything. Few people are exercising any thinking skills because they put in a half-formed broken thought in fractured english into the prompt, and then use the result.
Emails, general comms, problem-solving... everything is now at the point where the lazy fucks are no longer detectable in the workplace.
1. why should we trust the AI work? and
2. make me understand what the agent team did, while it spinned for hours
I think no 1 will be solved by N-version coding, keeping a population of replicas which provide differential testing on fuzzed inputs or prod data. This also helps no 2 - where execution diverges it can be a bug or a missing spec. Either fix code or fix spec.
Yes, people are struggling with status and purpose, but the reality is Opus 5.5 onwards has completely changed reality. We have to harness it.
If this is your metric, why aren't you starting with something like a CI step where an LLM looks for vulns?
People keep thinking of the coding step as a discrete, and thus also slow, expensive, non-deterministic step, but engineers did a lot to make it less so, whether it was techniques, tools, process, culture, whatever. Like, imagine an incredibly good agent working on a 2kloc PR for ~120 hours, periodically checking in with 4-5 other also incredibly good agents with near perfect knowledge of the system they're working on, constantly reevaluating the approach, periodically considering whether the existing codebase and architecture can facilitate the types of functionality you're adding, spending considerable effort to make it as easy as possible for other agents to add features, improving itself through these efforts, building ideas for new tools to help it, etc etc. It wasn't just code generation; so many useful things were happening in parallel.
You can think of it like dating in a huge city. In smaller cities incidental contact is frequent and encouraged. Dating is a bunch of meet cutes, dating in the workplace, ad hoc get togethers, etc. In huge cities incidental contact is overwhelming, oppressive, and discouraged, so if you want to meet people you have to expend considerable energy deliberately doing something you used to get relatively for free: talking to people you may want to socialize with/date/whatever. It's of course possible and people do it, but it's much harder, and we're only starting to become aware of the second order consequences of it (loneliness epidemic, growing political separation between men and women, falling fertility rates, etc). It's to the point where getting into a relationship as an adult is a part-time job, and fewer and fewer people can bring themselves to put forth the effort.
Swapping in LLMs for humans for the code generation process has the same dynamics. You can have more meetings about architecture, you can have it slop out more tools, you can have it analyze the last N PRs and have it slop out something that would've made those PRs smaller/simpler/whatever, you can have it rearchitect whatever you want (kinda) but you have to constantly push yourself to do it. You're no longer internally motivated to do it because you're no longer personally affected, fewer and fewer engineers will be able to put in the effort, and things will start to fall apart.
Maybe this won't be a problem. Maybe the code will be good enough and we'll find we don't need these higher level operations, i.e. we won't need engineers to spend weeks doing tedious tech debt sweeps every quarter in order to keep the lights on. But my guess is our ambitions will grow until we do.
> second set of eyes ... spreads knowledge around the team, and keeps any one person from quietly drifting the codebase off in their own direction
because people generally think things they are told, basic memetics.
There are a set of things code review is for, this set of things is for written information transfer and rather too large for speech, so when choosing to speak about what things code review is for people choose some, shared understanding is slightly more abstract than catching and reducing bugs so catching and reducing bugs gets repeated slightly more, and the next generation of people hearing what code review is for repeat it.
As a general rule I have seldom seen bugs get caught in review, I have caught a few bugs in review, but far fewer than the amount of code I have reviewed. I have very few times had bugs caught in review of my code, this is not because I don't make bugs, they just get caught out in testing.
Normally my experience is much of the communication I receive about code I've written is generally bike-shedding, probably 70-80%, above that it starts to become things we can absolutely agree is useful in some way (even if not at the bug catching stage), bug catching is maybe 0.01% of the comments.
P.S. Have a feeling this will get down-voted but posting since I am interested in counter-arguments for this approach.
E.g. why re-implement the oauth workflow instead of using the established package of the ecosystem? Why monkeypatch an existing python method for all code instead of implementing and using where needed a context manager?
The agent can give you an assessment on such alternative approaches if you ask it, but I haven't seen it taking the initiative to radically steer a PR.
Reviews ensure that the writer's hypothesis has an antithesis to create a better synthesis. It follows fairly naturally from the academic background of engineers'. Structural engineers don't have drawing reviews to ensure shared understanding and agreement; they really just want to avoid being liable for killing people. That's the structure that software engineering evolved from.
IMO they’re primarily about ensuring shared understanding and agreement, not just about how things are changing now, but how they’ll change in the future..