7 ms·

But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise pro

by onion2k 8mo ago

But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. The remain 10% of things like var naming, whitespace, and patterns can be checked with a linter instead of a person. If you can get the team to that level you can stop doing code reviews. You also need to build a team that you can trust to write the code you agreed you'd write, but if your reviews are there to check someone has done their job well enough then you have bigger problems.

loire280 8mo ago
I've seen engineers I respect abandon this way of working as a team for the productivity promise of conjuring PRs with a coding agent. It blows away years of trust so quickly when you realize they stopped reviewing their own output.
- onion2k 8mo ago
  Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. Agents are getting really good, and if you're used to planning and designing up front you can get a ton of value from them. The main problem with them that I see today is people having that level of trust without giving the agent the context necessary to do a good job. Accepting a zero-shotted service to do something important into your production codebase is still a step too far, but it's an increasingly small step.
  - camillomiller 8mo ago
    >> Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. I have been doing this to, and I've forgotten half of them. For me the point is that this usage scenario is really good, but it also has no added value to it, really. The moment Claude Code raises it prices 2x this won't be viable anymore, and at the same time to scale this to enterprise software production levels you need to spend on an agent probably as much as hiring two SWEs, given that you need at least one to coordinate the agents.
    - onion2k 8mo ago
      I think Claude could raise it's prices 100x and people would still use it. It'd just shift to being an enterprise-only option and companies would actually start to measure the value instead of being "Whee, AI is awesome! We're definitely going really fast now!"
      - christophilus 8mo ago
        100x? You think people would pay $20k per month for Claude Code? Codex is as good (or very nearly) as Claude code. Open source models continue to improve. The open source harnesses will also continue to improve. Anthropic is good, but it has no moat. No way could they 100x their prices.
    - jeremyjh 8mo ago
      Deepseek v3.2 tokens are $0.26/0.38 on OpenRouter. That model - released 4 months ago - isn't really good enough by today's standards, but its significantly stronger than Opus 4.1, which was only released last August! In 12 months I think its reasonable to expect there will be a model with less cost than that which is significantly stronger than anything available now. And no, it isn't ONLY because VC capital is being burned to subsidize cost. That is impossible for the dozen smaller providers offering service at that cost on OpenRouter who have to compete with each other for every request and also have to pay compute bills. Qwen3.5-9B is stronger than GPT-4o and it runs on my laptop. That isn't just benchmarks either. Models are getting smaller, cheaper and better at the same time and this is going to continue.
- overfeed 8mo ago
  Perhaps due to FOMO outbreak[1], upper management everywhere has demanded AI-powered productivity gains, based on LoC/PR metrics, it looks like they are getting it. 1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.
  - deleted 8mo ago
    [deleted]
  - tripledry 8mo ago
    Would love to be a fly on the wall for a couple of months to see what corporate CxO's actually do. Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute. (half) joking - most likely I'm massively trivializing the role.
    - eptcyka 8mo ago
      A charitable explanation for what CxOs do is that they figure out their strategic goals and then focus really hard on ways to herd cats en masse to achieve the goals in an efficient manner. Some people end up doing a great job, some do so accidentally, other just end up doing a job. Sometimes parroting some linkadink drivel is enough to keep the ship on course - usually because the winds are blowing in the right direction or the people at the oars are working well enough on their own.
    - arethuza 8mo ago
      "Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin" Having worked for a pretty decent CIO of a global business I'd say his main job was to travel about speak to other senior leaders and work out what business problems they had and try and work out, at a very high level, how technology would fit into that addressing those problems. Just parroting latest technology trends would, I suspect, get you sacked within a few weeks.
    - 7mo ago
- nvardakas 8mo ago
  [dead]
- denkmoon 7mo ago
  I’m so disappointed to see the slip in quality by colleagues I think are better than that. People who used to post great PRs are now posting stuff with random unrelated changes, little structs and helpers all over the place that we already have in common modules etc :’(
  - bluefirebrand 7mo ago
    > little structs and helpers all over the place that we already have in common modules I've often wondered about building some kind of automated "this codebase already has this logic" linter Not sure how it would actually work, otherwise I'd build it. But it would definitely be useful Maybe an AI tool could do something like that nowadays. "Search this codebase for instances of duplicated functions and list them out" sort of thing
    - SkyBelow 7mo ago
      >this codebase already has this logic At first glance this looks like it might be the halting problem in disguise (instead of the general function of the logic, just ask if they both have logic that halts or doesn't halt). I think we would need to allow for false negatives to even be theoretically possible, so while identical text comparison would be easy enough, anything past that can quickly becomes complicated and you can probably infinitely expand the complexity by handling more and more edge cases (but never every edge case due to the underlying halting problem/undecidability of code).
    - glitchdout 7mo ago
      You only need to detect structuraly similar code. You absolutely do not need AI for that. You need ASTs. In Ruby we have the Flay gem, for example. https://github.com/seattlerb/flay https://github.com/seattlerb/flay
jauntywundrkind 8mo ago
I wonder what delayed continuous release would be like. Trust folks to merge semi-responsibly, but have a two week delay before actually shipping to give yourself some time to find and fix issues. Perhaps kind of a pain to inject fixes in, have to rebase the outstanding work. But I kind of like this idea of the org having responsibility to do what review it wants, without making every person have to coral all the cats to get all the check marks. Make it the org's challenge instead.
Swizec 8mo ago
> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~10min to revert a bad deploy.
- pdhborges 8mo ago
  > The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?
  - jamiemallers 8mo ago
    [dead]
  - DrewADesign 7mo ago
    Having data model changes be a part of regular deployments would give me persistent heartburn.
    - redman25 7mo ago
      It's why you always have a rollback plan. Every `up` needs to a `down`.
      - hedora 7mo ago
        If you do that, it expands your test matrix quadratically. So, it makes sense if you have infinite testing budgets. Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good. I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability. Would love to hear of an example.
anal_reactor 8mo ago
I never review PRs, I always rubber-stamp them, unless they come from a certified idiot: 1. I don't care because the company at large fails to value quality engineering. 2. 90% of PR comments are arguments about variable names. 3. The other 10% are mistakes that have very limited blast radius. It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable state, in which case there's no point delaying the project. Regarding knowledge share, it's complete fiction. Unless you actually make changes to some code, there's zero chance you'll understand how it works.
- devmor 8mo ago
  I used to do this! I can’t anymore, not with the advent of AI coding agents. My trust in my colleagues is gone, I have no reason to believe they wrote the code they asked me to put my approval on, and so I certainly don’t want to be on a postmortem being asked why I approved the change. Perhaps if I worked in a different industry I would feel like you do, but payments is a scary place to cause downtime.
- recursivecaveat 8mo ago
  Do people really argue about variable names? Most reviews comments I see are fairly trivial, but almost always not very subjective. (Leftover debug log, please add comment here, etc) Maybe it helps that many of our seniors are from a team where we had no auto-formatter or style guide at all for quite a while. I think everyone should experience that a random mix of `){` and `) {` does not really impact you in any way beyond the mild irking of a crooked painting or something. There's a difference between aesthetically bothersome and actually harmful. Not to say that you shouldn't run a formatter, but just for some perspective.
  - anal_reactor 8mo ago
    Yes. 80% of comments to my PRs are "change _ to -" or something like that.
    - blitzar 8mo ago
totetsu 8mo ago
This seems to be a core of the problem with trying to leave things to autonomous agents .. The response to Amazons agents deleting prod was to implement review stages https://blog.barrack.ai/amazon-ai-agents-deleting-production/ https://blog.barrack.ai/amazon-ai-agents-deleting-production...
riffraff 8mo ago
This is also the premise of pair programming/extreme programming: if code review is useful, we should do it all the time.
- roncesvalles 8mo ago
  Anyone who talks about pair programming has either never done them or just started doing them last week.
  - interroboink 7mo ago
    My sense is that there is a narrow slice of software developers who genuinely do flourish in a pair programming environment. These are people who actually work through their thoughts better with another person in the loop. They get super excited about it and make the common mistake of "if it works for me, it will work for everybody" and shout it from the hilltops. Then there are the people who program best in a fugue state and the idea of having to constantly break that to transform their thoughts into words and human interaction is anathema. I say this as someone who just woke up in the wee hours of the morning when nobody else is around so I can get some work done (:
    - mwigdahl 7mo ago
      I hope you mean "flow state" and not actually "fugue state".
      - interroboink 7mo ago
        Well, I wrote what I meant, but I meant to be facetious (:
  - nicoburns 7mo ago
    I like pair programming for certain problems: things that are genuinely hard / pushing the boundaries of both participants knowledge and abilities. In those scenarios sometimes two minds can fill in each other's gaps much more efficiently than either can work alone.
rendall 8mo ago
Yes. This is the way. Declarative design contracts are the answer to A.I. coders. A team declares what they want, agents code it together with human supervision. Then code review is just answering the question "is the code conformant with the design contract?" But. The design contract needs review, which takes time.
ramon156 8mo ago
I'm in a company that does no reviews and I'm medior. The tools we make is not interesting at all, so it's probably the best position I could ask for. I occasionally have time to explore some improvements, tools and side projects (don't tell my boss about that last one)
froh 8mo ago
yes! and it also works for me when working with ai. that produces much better results, too, when I first so a design session really discussing what to build. then a planning session, in which steps to build it ("reviewability" world wonder). and then the instruction to stop when things get gnarly and work with the hooman. does anyone here have a good system prompt for that self observance "I might be stuck, I'm kinda sorta looping. let's talk with hooman!"?
hinkley 8mo ago
These systems make it more efficient to remove the actively toxic members for your team. Beligerence can be passively aggressively “handled” by additional layers but at considerable time and emotional labor cost to people who could be getting more work done without having to coddle untalented assholes.
- layer8 8mo ago
  Sounds like there was a bad hiring process.
  - usefulcat 7mo ago
    There's no such thing as a hiring process that avoids that problem 100% of the time. After all, most people will be on their best behavior during an interview, and even a lengthy interview process is a very short period of time compared to working with someone for weeks or months.
    - layer8 7mo ago
      Not 100%, but well enough that it shouldn’t be a general expectation to have someone like that on the team.
  - hinkley 7mo ago
    They’re all bad hiring processes. Some worse than others. Hiring known quantities can slip onto nepotism shockingly fast.
ozim 8mo ago
Then you spend all your budget on code design sessions and have nothing to show to the customer.
thrwaway55 8mo ago
Okay but Claude is a fucking moron.
DeathArrow 8mo ago
The issue is that every review adds a lot of delay. A lot of alignment and pair programming won't be time expensive?
- onion2k 7mo ago
  A lot of alignment and pair programming won't be time expensive? The question is really "Will up-front design and pair programming cost more than not doing up-front design and pair programming?". In my experience, somewhat counter-intuitively, alignment and pairing is cheaper because you get to the right answer a bit 'slower' but without needing the time spent reworking things. If rework is doubling the time it takes to deliver something (which is not an extreme example, and in some orgs would be incredibly conservative) then spending 1.5 times the estimate putting in good design and pair programming time is still waaaay cheaper.
alkonaut 8mo ago
This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation. Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.
- AIorNot 7mo ago
  “Everyone has a plan until they get punched in the mouth" - Mike Tyson
- 2OEH8eoCRo0 7mo ago
  I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. > Most of what's planned falls down within the first few hours of implementation. Not my experience at all. We know what computers are capable of.
  - steveBK123 7mo ago
    > I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool. The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.
roncesvalles 8mo ago
>shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits hell in one sentence
- hedora 7mo ago
  I have seen the future, and it is a robotic boot pushing a human neck to the left.
ap99 7mo ago
Unless you're covering 100% of edge/corner cases during planning (including roughly how they're handled) then there is still value in code reviews. You conveniently brushed this under the rug of pair programming but of the handful of companies I've worked at, only one tried it and just as an experiment which in the end failed because no one really wanted to work that way. I think this "don't review" attitude is dangerous and only acceptable for hobby projects.
- zingar 7mo ago
  Reviews are vital for 80% of the programmers I work with but I happily trust the other 20% to manage risk, know when merging is safe without review, and know how to identify and fix problems quickly. With or without pairing. The flip side is that if the programmer and the reviewer are both in the 80% then the review doesn’t decrease the risk (it may even increase it).
Certhas 7mo ago
That's partly the point of the article, except the article acknowledges that this is organizationally hard: > You get things like the famous Toyota Production System where they eliminated the QA phase entirely. > [This] approach to manufacturing didn’t have any magic bullets. Alas, you can’t just follow his ten-step process and immediately get higher quality engineering. The secret is, you have to get your engineers to engineer higher quality into the whole system, from top to bottom, repeatedly. Continuously. > The basis of [this system] is trust. Trust among individuals that your boss Really Truly Actually wants to know about every defect, and wants you to stop the line when you find one. Trust among managers that executives were serious about quality. Trust among executives that individuals, given a system that can work and has the right incentives, will produce quality work and spot their own defects, and push the stop button when they need to push it. > I think we’re going to be stuck with these systems pipeline problems for a long time. Review pipelines — layers of QA — don’t work. Instead, they make you slower while hiding root causes. Hiding causes makes them harder to fix.
srean 7mo ago
Bean counters do not like pair programming. If we hired two programmers, the goal was to produce twice the LOC per week. Now we are doing far less than our weekly target. Does not meet expectation.
agumonkey 7mo ago
Anybody has idea on how to avoid childish resistance? Anytime something like this pops up people discuss it into oblivion and teams stay in their old habits
muskstinks 7mo ago
[dead]
chrisweekly 7mo ago
"If you can get the team to that level you can stop doing code reviews." IMHO / IME (over 20y in dev) reviewing PRs still has value as a sanity check and a guard against (slippery slope) hasty changes that might not have received all of the prior checks you mentioned. A bit of well-justified friction w/ ROI, along the lines of "slow is smooth, smooth is fast".
rendaw 7mo ago
I've seen this mentioned a couple times lately, so I want to say I don't believe pair programming can serve in place of code review. Code review benefits from someone coming in fresh, making assumptions and challenging those by looking at the code and documentation. With pair programming, you both take the same logical paths to the end result and I've seen this lead to missing things.
- flr03 7mo ago
  Pair programming is basically continuous code review. You don't take the same path until you discuss and challenge the ideas first. I could argue that code reviews are also lazily done, yes pair programming can be difficult but god reviewing massive PRs, how many times does the attention drops, how many times is it done seriously? LGTM
jayd16 7mo ago
Linting isn't going to catch most malicious implementation patterns. You still need to sniff test what was written.
QuiEgo 7mo ago
> your reviews are there to check someone has done their job well enough then you have bigger problems Welcome to working with real people. They go off the rails and ignore everything you’ve agreed to during design because they get lazy or feel schedule pressure and cut corners all the time. Sideline: I feel like AI obeys the spec better than engineers sometimes sigh.
chaiyihein 7mo ago
actually you don't need reviews if you have a realistic enough simulation test environment that is fully instrumentable by the AI agent. If you can simulate it almost exactly as in production and it works, there's no need to code review. to move to the hyperspeed timescale you need reliable models of verification in the digital realm, fully accessible by AI.
Asooka 7mo ago
Well we can't not review things, because the workflow demands we review things. So we hacked the process and for big changes we begin by asking people who will be impacted (no-code review), then we do a pre-review of a rough implementation and finally do a formal review in a fraction of the time.
deleted 7mo ago
[deleted]
maxothex 7mo ago
[dead]
wcfrobert 7mo ago
Master planning has never worked for my side projects unless I am building the exact replica of what I've done in the past. The most important decisions are made while I'm deep in the code base and I have a better understanding of the tradeoffs. I think that's why startups have such an edge over big companies. They can just build and iterate while the big company gets caught up in month-long review processes.
psychoslave 7mo ago
>The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. This is like, there's not going to be surprise on the road you'll take if you already set the destination point. Though most of the time, you are just given a vague description of the kind of place you want to reach, not a precise point targeted. And you are not necessarily starting with a map, not even an outdated one. Also geological forces reshape the landscape at least as fast as you are able to move.
qalfy 7mo ago
Pairing through the gnarly bits is doing the review, just synchronously and earlier. You haven't eliminated reviews — you've moved them to a higher-bandwidth channel. Genuinely better for catching design-level stuff. But it needs overlapping hours and enough shared context to actually work, which falls apart fast across timezones. Async review exists partly because async work does.

by onion2k 8mo ago

loire280 8mo ago

I've seen engineers I respect abandon this way of working as a team for the productivity promise of conjuring PRs with a coding agent. It blows away years of trust so quickly when you realize they stopped reviewing their own output.

onion2k 8mo ago
Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. Agents are getting really good, and if you're used to planning and designing up front you can get a ton of value from them. The main problem with them that I see today is people having that level of trust without giving the agent the context necessary to do a good job. Accepting a zero-shotted service to do something important into your production codebase is still a step too far, but it's an increasingly small step.
- camillomiller 8mo ago
  >> Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. I have been doing this to, and I've forgotten half of them. For me the point is that this usage scenario is really good, but it also has no added value to it, really. The moment Claude Code raises it prices 2x this won't be viable anymore, and at the same time to scale this to enterprise software production levels you need to spend on an agent probably as much as hiring two SWEs, given that you need at least one to coordinate the agents.
  - onion2k 8mo ago
    I think Claude could raise it's prices 100x and people would still use it. It'd just shift to being an enterprise-only option and companies would actually start to measure the value instead of being "Whee, AI is awesome! We're definitely going really fast now!"
    - christophilus 8mo ago
      100x? You think people would pay $20k per month for Claude Code? Codex is as good (or very nearly) as Claude code. Open source models continue to improve. The open source harnesses will also continue to improve. Anthropic is good, but it has no moat. No way could they 100x their prices.
  - jeremyjh 8mo ago
    Deepseek v3.2 tokens are $0.26/0.38 on OpenRouter. That model - released 4 months ago - isn't really good enough by today's standards, but its significantly stronger than Opus 4.1, which was only released last August! In 12 months I think its reasonable to expect there will be a model with less cost than that which is significantly stronger than anything available now. And no, it isn't ONLY because VC capital is being burned to subsidize cost. That is impossible for the dozen smaller providers offering service at that cost on OpenRouter who have to compete with each other for every request and also have to pay compute bills. Qwen3.5-9B is stronger than GPT-4o and it runs on my laptop. That isn't just benchmarks either. Models are getting smaller, cheaper and better at the same time and this is going to continue.
overfeed 8mo ago
Perhaps due to FOMO outbreak[1], upper management everywhere has demanded AI-powered productivity gains, based on LoC/PR metrics, it looks like they are getting it. 1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.
- deleted 8mo ago
  [deleted]
- tripledry 8mo ago
  Would love to be a fly on the wall for a couple of months to see what corporate CxO's actually do. Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute. (half) joking - most likely I'm massively trivializing the role.
  - eptcyka 8mo ago
    A charitable explanation for what CxOs do is that they figure out their strategic goals and then focus really hard on ways to herd cats en masse to achieve the goals in an efficient manner. Some people end up doing a great job, some do so accidentally, other just end up doing a job. Sometimes parroting some linkadink drivel is enough to keep the ship on course - usually because the winds are blowing in the right direction or the people at the oars are working well enough on their own.
  - arethuza 8mo ago
    "Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin" Having worked for a pretty decent CIO of a global business I'd say his main job was to travel about speak to other senior leaders and work out what business problems they had and try and work out, at a very high level, how technology would fit into that addressing those problems. Just parroting latest technology trends would, I suspect, get you sacked within a few weeks.
  - 7mo ago
nvardakas 8mo ago
[dead]
denkmoon 7mo ago
I’m so disappointed to see the slip in quality by colleagues I think are better than that. People who used to post great PRs are now posting stuff with random unrelated changes, little structs and helpers all over the place that we already have in common modules etc :’(
- bluefirebrand 7mo ago
  > little structs and helpers all over the place that we already have in common modules I've often wondered about building some kind of automated "this codebase already has this logic" linter Not sure how it would actually work, otherwise I'd build it. But it would definitely be useful Maybe an AI tool could do something like that nowadays. "Search this codebase for instances of duplicated functions and list them out" sort of thing
  - SkyBelow 7mo ago
    >this codebase already has this logic At first glance this looks like it might be the halting problem in disguise (instead of the general function of the logic, just ask if they both have logic that halts or doesn't halt). I think we would need to allow for false negatives to even be theoretically possible, so while identical text comparison would be easy enough, anything past that can quickly becomes complicated and you can probably infinitely expand the complexity by handling more and more edge cases (but never every edge case due to the underlying halting problem/undecidability of code).
  - glitchdout 7mo ago
    You only need to detect structuraly similar code. You absolutely do not need AI for that. You need ASTs. In Ruby we have the Flay gem, for example. https://github.com/seattlerb/flay https://github.com/seattlerb/flay

jauntywundrkind 8mo ago

I wonder what delayed continuous release would be like. Trust folks to merge semi-responsibly, but have a two week delay before actually shipping to give yourself some time to find and fix issues. Perhaps kind of a pain to inject fixes in, have to rebase the outstanding work. But I kind of like this idea of the org having responsibility to do what review it wants, without making every person have to coral all the cats to get all the check marks. Make it the org's challenge instead.

Swizec 8mo ago

> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~10min to revert a bad deploy.

pdhborges 8mo ago
> The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?
- jamiemallers 8mo ago
  [dead]
- DrewADesign 7mo ago
  Having data model changes be a part of regular deployments would give me persistent heartburn.
  - redman25 7mo ago
    It's why you always have a rollback plan. Every `up` needs to a `down`.
    - hedora 7mo ago
      If you do that, it expands your test matrix quadratically. So, it makes sense if you have infinite testing budgets. Personally, I prefer exhaustively testing the upgrade path, and investing in reducing the time it takes to push out a hot fix. Chicken bits are also good. I haven’t heard of any real world situations where supporting downgrades of persistent formats led to best of class product stability. Would love to hear of an example.

anal_reactor 8mo ago

I never review PRs, I always rubber-stamp them, unless they come from a certified idiot: 1. I don't care because the company at large fails to value quality engineering. 2. 90% of PR comments are arguments about variable names. 3. The other 10% are mistakes that have very limited blast radius. It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable state, in which case there's no point delaying the project. Regarding knowledge share, it's complete fiction. Unless you actually make changes to some code, there's zero chance you'll understand how it works.

devmor 8mo ago
I used to do this! I can’t anymore, not with the advent of AI coding agents. My trust in my colleagues is gone, I have no reason to believe they wrote the code they asked me to put my approval on, and so I certainly don’t want to be on a postmortem being asked why I approved the change. Perhaps if I worked in a different industry I would feel like you do, but payments is a scary place to cause downtime.
recursivecaveat 8mo ago
Do people really argue about variable names? Most reviews comments I see are fairly trivial, but almost always not very subjective. (Leftover debug log, please add comment here, etc) Maybe it helps that many of our seniors are from a team where we had no auto-formatter or style guide at all for quite a while. I think everyone should experience that a random mix of `){` and `) {` does not really impact you in any way beyond the mild irking of a crooked painting or something. There's a difference between aesthetically bothersome and actually harmful. Not to say that you shouldn't run a formatter, but just for some perspective.
- anal_reactor 8mo ago
  Yes. 80% of comments to my PRs are "change _ to -" or something like that.
  - blitzar 8mo ago

totetsu 8mo ago

This seems to be a core of the problem with trying to leave things to autonomous agents .. The response to Amazons agents deleting prod was to implement review stages https://blog.barrack.ai/amazon-ai-agents-deleting-production/ https://blog.barrack.ai/amazon-ai-agents-deleting-production...

riffraff 8mo ago

This is also the premise of pair programming/extreme programming: if code review is useful, we should do it all the time.

roncesvalles 8mo ago
Anyone who talks about pair programming has either never done them or just started doing them last week.
- interroboink 7mo ago
  My sense is that there is a narrow slice of software developers who genuinely do flourish in a pair programming environment. These are people who actually work through their thoughts better with another person in the loop. They get super excited about it and make the common mistake of "if it works for me, it will work for everybody" and shout it from the hilltops. Then there are the people who program best in a fugue state and the idea of having to constantly break that to transform their thoughts into words and human interaction is anathema. I say this as someone who just woke up in the wee hours of the morning when nobody else is around so I can get some work done (:
  - mwigdahl 7mo ago
    I hope you mean "flow state" and not actually "fugue state".
    - interroboink 7mo ago
      Well, I wrote what I meant, but I meant to be facetious (:
- nicoburns 7mo ago
  I like pair programming for certain problems: things that are genuinely hard / pushing the boundaries of both participants knowledge and abilities. In those scenarios sometimes two minds can fill in each other's gaps much more efficiently than either can work alone.

rendall 8mo ago

Yes. This is the way. Declarative design contracts are the answer to A.I. coders. A team declares what they want, agents code it together with human supervision. Then code review is just answering the question "is the code conformant with the design contract?" But. The design contract needs review, which takes time.

ramon156 8mo ago

I'm in a company that does no reviews and I'm medior. The tools we make is not interesting at all, so it's probably the best position I could ask for. I occasionally have time to explore some improvements, tools and side projects (don't tell my boss about that last one)

froh 8mo ago

yes! and it also works for me when working with ai. that produces much better results, too, when I first so a design session really discussing what to build. then a planning session, in which steps to build it ("reviewability" world wonder). and then the instruction to stop when things get gnarly and work with the hooman. does anyone here have a good system prompt for that self observance "I might be stuck, I'm kinda sorta looping. let's talk with hooman!"?

hinkley 8mo ago

These systems make it more efficient to remove the actively toxic members for your team. Beligerence can be passively aggressively “handled” by additional layers but at considerable time and emotional labor cost to people who could be getting more work done without having to coddle untalented assholes.

layer8 8mo ago
Sounds like there was a bad hiring process.
- usefulcat 7mo ago
  There's no such thing as a hiring process that avoids that problem 100% of the time. After all, most people will be on their best behavior during an interview, and even a lengthy interview process is a very short period of time compared to working with someone for weeks or months.
  - layer8 7mo ago
    Not 100%, but well enough that it shouldn’t be a general expectation to have someone like that on the team.
- hinkley 7mo ago
  They’re all bad hiring processes. Some worse than others. Hiring known quantities can slip onto nepotism shockingly fast.

ozim 8mo ago

Then you spend all your budget on code design sessions and have nothing to show to the customer.

thrwaway55 8mo ago

Okay but Claude is a fucking moron.

DeathArrow 8mo ago

The issue is that every review adds a lot of delay. A lot of alignment and pair programming won't be time expensive?

onion2k 7mo ago
A lot of alignment and pair programming won't be time expensive? The question is really "Will up-front design and pair programming cost more than not doing up-front design and pair programming?". In my experience, somewhat counter-intuitively, alignment and pairing is cheaper because you get to the right answer a bit 'slower' but without needing the time spent reworking things. If rework is doubling the time it takes to deliver something (which is not an extreme example, and in some orgs would be incredibly conservative) then spending 1.5 times the estimate putting in good design and pair programming time is still waaaay cheaper.

alkonaut 8mo ago

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation. Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.

AIorNot 7mo ago
“Everyone has a plan until they get punched in the mouth" - Mike Tyson
2OEH8eoCRo0 7mo ago
I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. > Most of what's planned falls down within the first few hours of implementation. Not my experience at all. We know what computers are capable of.
- steveBK123 7mo ago
  > I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for the third time, to get to a much worse product slightly faster. Now we can do that part 10x faster, cool. The thing is, at every other level of the company, people are actually planning in terms of quarters/years, so the underlying product being given only enough thought for the next 2 weeks at a time is a mismatch.

roncesvalles 8mo ago

>shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits hell in one sentence

hedora 7mo ago
I have seen the future, and it is a robotic boot pushing a human neck to the left.

ap99 7mo ago

Unless you're covering 100% of edge/corner cases during planning (including roughly how they're handled) then there is still value in code reviews. You conveniently brushed this under the rug of pair programming but of the handful of companies I've worked at, only one tried it and just as an experiment which in the end failed because no one really wanted to work that way. I think this "don't review" attitude is dangerous and only acceptable for hobby projects.

zingar 7mo ago
Reviews are vital for 80% of the programmers I work with but I happily trust the other 20% to manage risk, know when merging is safe without review, and know how to identify and fix problems quickly. With or without pairing. The flip side is that if the programmer and the reviewer are both in the 80% then the review doesn’t decrease the risk (it may even increase it).

Certhas 7mo ago

That's partly the point of the article, except the article acknowledges that this is organizationally hard: > You get things like the famous Toyota Production System where they eliminated the QA phase entirely. > [This] approach to manufacturing didn’t have any magic bullets. Alas, you can’t just follow his ten-step process and immediately get higher quality engineering. The secret is, you have to get your engineers to engineer higher quality into the whole system, from top to bottom, repeatedly. Continuously. > The basis of [this system] is trust. Trust among individuals that your boss Really Truly Actually wants to know about every defect, and wants you to stop the line when you find one. Trust among managers that executives were serious about quality. Trust among executives that individuals, given a system that can work and has the right incentives, will produce quality work and spot their own defects, and push the stop button when they need to push it. > I think we’re going to be stuck with these systems pipeline problems for a long time. Review pipelines — layers of QA — don’t work. Instead, they make you slower while hiding root causes. Hiding causes makes them harder to fix.

srean 7mo ago

Bean counters do not like pair programming. If we hired two programmers, the goal was to produce twice the LOC per week. Now we are doing far less than our weekly target. Does not meet expectation.

agumonkey 7mo ago

Anybody has idea on how to avoid childish resistance? Anytime something like this pops up people discuss it into oblivion and teams stay in their old habits

muskstinks 7mo ago

[dead]

chrisweekly 7mo ago

"If you can get the team to that level you can stop doing code reviews." IMHO / IME (over 20y in dev) reviewing PRs still has value as a sanity check and a guard against (slippery slope) hasty changes that might not have received all of the prior checks you mentioned. A bit of well-justified friction w/ ROI, along the lines of "slow is smooth, smooth is fast".

rendaw 7mo ago

I've seen this mentioned a couple times lately, so I want to say I don't believe pair programming can serve in place of code review. Code review benefits from someone coming in fresh, making assumptions and challenging those by looking at the code and documentation. With pair programming, you both take the same logical paths to the end result and I've seen this lead to missing things.

flr03 7mo ago
Pair programming is basically continuous code review. You don't take the same path until you discuss and challenge the ideas first. I could argue that code reviews are also lazily done, yes pair programming can be difficult but god reviewing massive PRs, how many times does the attention drops, how many times is it done seriously? LGTM

jayd16 7mo ago

Linting isn't going to catch most malicious implementation patterns. You still need to sniff test what was written.

QuiEgo 7mo ago

> your reviews are there to check someone has done their job well enough then you have bigger problems Welcome to working with real people. They go off the rails and ignore everything you’ve agreed to during design because they get lazy or feel schedule pressure and cut corners all the time. Sideline: I feel like AI obeys the spec better than engineers sometimes sigh.

chaiyihein 7mo ago

actually you don't need reviews if you have a realistic enough simulation test environment that is fully instrumentable by the AI agent. If you can simulate it almost exactly as in production and it works, there's no need to code review. to move to the hyperspeed timescale you need reliable models of verification in the digital realm, fully accessible by AI.

Asooka 7mo ago

Well we can't not review things, because the workflow demands we review things. So we hacked the process and for big changes we begin by asking people who will be impacted (no-code review), then we do a pre-review of a rough implementation and finally do a formal review in a fraction of the time.

deleted 7mo ago

[deleted]

maxothex 7mo ago

[dead]

wcfrobert 7mo ago

Master planning has never worked for my side projects unless I am building the exact replica of what I've done in the past. The most important decisions are made while I'm deep in the code base and I have a better understanding of the tradeoffs. I think that's why startups have such an edge over big companies. They can just build and iterate while the big company gets caught up in month-long review processes.

psychoslave 7mo ago

>The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. This is like, there's not going to be surprise on the road you'll take if you already set the destination point. Though most of the time, you are just given a vague description of the kind of place you want to reach, not a precise point targeted. And you are not necessarily starting with a map, not even an outdated one. Also geological forces reshape the landscape at least as fast as you are able to move.

qalfy 7mo ago

Pairing through the gnarly bits is doing the review, just synchronously and earlier. You haven't eliminated reviews — you've moved them to a higher-bandwidth channel. Genuinely better for catching design-level stuff. But it needs overlapping hours and enough shared context to actually work, which falls apart fast across timezones. Async review exists partly because async work does.