new | ask | show | jobs
4lx87 3 hours ago  [ - ]

Producing features and fixing bugs, same as it was before. The organizational process of software development has not changed much with AI: execs decide direction and initiatives, PMs decide what to build, which is broken down into features and bug fixes that SWEs produce. In my experience organizations don't actually care how SWEs produce features, except insofar as it relates to how many and how fast the features can be pumped out. Organizations see code review as a process to prevent bugs. Humans are not as good as LLMs at reviewing code for bugs. Abstract notions of code style and quality that programmers care about is not why organizations enforce code review.

necovek 2 hours ago  [ - ]

Before LLMs, "organizations" have seen code review as multiple things:

  * Share knowledge about a particular area of the codebase between multiple people
  * Share overall engineering knowledge between the parties in the review
  * Ensure maintainability of the codebase long-term
  * Ensure readability of the code
  * Catch architectural/directional omissions (yes, from the planning/architecture phase) before it's really too late and non-reversible change goes in (eg. large destructive DB schema change)
  * Ensure changes are small, self-contained, and as often as possible, reversible
  * Do some basic manual QA
  * Do comprehensive integration testing with a fully built-out system
  ...
  * And yes, catch bugs before they hit production.
A lot of the above could be fun and engaging, and especially knowledge sharing and ensuring maintainability/readability was a very motivating thing for me as a more experienced engineer having learned so much from getting good reviews when I was less experienced.

Programmers care about style to ensure readability and thus maintainability of the code, but also to keep changes minimal — if every diff converted between tabs and spaces in the entire codebase, it'd be impossible to see what has really changed with the simple tooling we generally use (one could build diffing tools that ignore changes like these, and they even exist, but are not ubiquitous).