You can’t make humans read faster, in order to speed up review time, you need to write less.
AI is very good at writing a ton of overly complex code so the you gotta babysit it sometimes to get a lean code.
On the other hand, reviewing the code needs a better surface. It’s still the hard part, but what kills me is that GitHub is still expecting us to review PRs the same way, and it’s increasingly stressful due to GitHub’s poor support for a good PR review experience, I ended up building my own solution (https://pyor.review) to make reviewing the code a lot less tedious and closer to how I want to look at code.
One of the features that actually makes me read less code confidently is that it highlights the moved code, so in a large refactor PR, i can skip reviewing the parts of the code that just moved without change, it also takes AI-assisted review differently as it groups files depending on importance and flags noise, so it’s not adding more walls of text for me to read.
First articulate the purpose of code reviews (typically, there are about 3 or 4).
Then think about whether there are other, better ways, to accomplish those goals, assuming you still want to reach those goals. That can inform how you modify your SDLC.
be willing to change paradigm to what works well for you specifically. Gather buy-in towards a specific shape, if there are other devs involved.
my teams and I use small sub-branch/stacked PRs in a specific order (contract, spec, mechanics, logic, wiring, cleanup) -> feature branch -> staging. PRs need to stay small enough that we can (1) review intent, (2) review code, and (3) hold the PR stack in mind. It adds overhead to introduce sanity to the current speed of developing with AI.
every contract has specs, every spec touches logic. If any one of those is orphaned, identify why.
it boils down to "identify the fundamentals that matter to your way of operating and your company's needs"
if someone is just letting a third-party LLM at the code without any structure...
blessed be their sleepless nights.
Go all in on AI, stop worrying about quality. When shit breaks, spin a replica and have an agent look at the logs and figure it out while hoping the replica restores service. It might sound counter-intuitive, but you know who's doing it? Your competition.
It's cheaper to create than it is to understand, so if you have no understanding in your SDLC, you can't expect to have it on incidents.
This is going to lead to more hacking incidents and give the entire industry a bad rap, which will invite more intense regulation. Do you want HIPAA for all of software development? We'd best not be so cavalier or we earn what society legislates on us
As someone who's been there for the last few years, there's no fighting it anymore. People will need to come to their conclusion on their own - and they're fighting a trillion dollar hype machine and everyone above middle management and a good percentage of those below.
> People will need to come to their conclusion on their own
I disagree, humans are social creatures, we have many constructs developed over millennia to lean on. This is where social media borks us, but we can step back from that as well and return to more IRL interaction. It's already started, more people are giving up or reducing social media time.
Depends what do you look for in code review? I only check the code architecture.
Does it use dependency injection as we set it up?
Are domain/data/presentation classes in correct modules?
Is the data flow hierarchy correct according to clean arch?
Are unit tests written, is the code coverage better or at least the same?
Are classes doing specific things named according to patterns how we name them?
Is everything generally following the same pattern as the rest of the project?
Code is mostly about patterns, and if you know the pattern, making sure the AI agent follows it gives you the peace of mind that you can also manually check and understand it later. Everything else is a fine detail, and at the moment, this is something that I don't think is that important unless you have specific bottlenecks or issues, which again... you fix with a new prompt...
Seems like a bad practice. I recently worked through a major security regression with OpenCode that requires understanding more details. Then their platform got hacked a couple days back. Too much eyes / brain free coding will come back to bite you.
What @pluc said basically. You could use stuff like https://bte.mills.io and https://git.mills.io/prologic/squint to help test/validate the "behaviour" of what is being developed/built. Try to think of yourself as the "Product Designer" and "Product Owner". Worry less about the _actual_ code itself, and more about how the software/product behaves. Write specifications that can be validated and ask yoru favourite coding assistant to ensure that those are validated.
Trigger automated review at the end of CI, but do stay very in the loop, both during development and review. This idea that you can let the machines write and decide things, and you just need to check, is the wrong approach. Tell the bots what the architecture should look like and how the core loops should work. These are places our machine gods make poor decisions and many mistakes.
You can’t make humans read faster, in order to speed up review time, you need to write less.
AI is very good at writing a ton of overly complex code so the you gotta babysit it sometimes to get a lean code.
On the other hand, reviewing the code needs a better surface. It’s still the hard part, but what kills me is that GitHub is still expecting us to review PRs the same way, and it’s increasingly stressful due to GitHub’s poor support for a good PR review experience, I ended up building my own solution (https://pyor.review) to make reviewing the code a lot less tedious and closer to how I want to look at code.
One of the features that actually makes me read less code confidently is that it highlights the moved code, so in a large refactor PR, i can skip reviewing the parts of the code that just moved without change, it also takes AI-assisted review differently as it groups files depending on importance and flags noise, so it’s not adding more walls of text for me to read.
I found this to be the only way to move faster.
First articulate the purpose of code reviews (typically, there are about 3 or 4).
Then think about whether there are other, better ways, to accomplish those goals, assuming you still want to reach those goals. That can inform how you modify your SDLC.
be willing to change paradigm to what works well for you specifically. Gather buy-in towards a specific shape, if there are other devs involved.
my teams and I use small sub-branch/stacked PRs in a specific order (contract, spec, mechanics, logic, wiring, cleanup) -> feature branch -> staging. PRs need to stay small enough that we can (1) review intent, (2) review code, and (3) hold the PR stack in mind. It adds overhead to introduce sanity to the current speed of developing with AI.
every contract has specs, every spec touches logic. If any one of those is orphaned, identify why.
it boils down to "identify the fundamentals that matter to your way of operating and your company's needs"
if someone is just letting a third-party LLM at the code without any structure... blessed be their sleepless nights.
Go all in on AI, stop worrying about quality. When shit breaks, spin a replica and have an agent look at the logs and figure it out while hoping the replica restores service. It might sound counter-intuitive, but you know who's doing it? Your competition.
It's cheaper to create than it is to understand, so if you have no understanding in your SDLC, you can't expect to have it on incidents.
> stop worrying about quality
This is going to lead to more hacking incidents and give the entire industry a bad rap, which will invite more intense regulation. Do you want HIPAA for all of software development? We'd best not be so cavalier or we earn what society legislates on us
I agree that it's a terrible idea, but here we are.
we were not here before, nor do we have to remain in this place - start with individual change and then move to encouragement towards others
As someone who's been there for the last few years, there's no fighting it anymore. People will need to come to their conclusion on their own - and they're fighting a trillion dollar hype machine and everyone above middle management and a good percentage of those below.
> People will need to come to their conclusion on their own
I disagree, humans are social creatures, we have many constructs developed over millennia to lean on. This is where social media borks us, but we can step back from that as well and return to more IRL interaction. It's already started, more people are giving up or reducing social media time.
Depends what do you look for in code review? I only check the code architecture.
Does it use dependency injection as we set it up? Are domain/data/presentation classes in correct modules? Is the data flow hierarchy correct according to clean arch? Are unit tests written, is the code coverage better or at least the same? Are classes doing specific things named according to patterns how we name them? Is everything generally following the same pattern as the rest of the project?
Code is mostly about patterns, and if you know the pattern, making sure the AI agent follows it gives you the peace of mind that you can also manually check and understand it later. Everything else is a fine detail, and at the moment, this is something that I don't think is that important unless you have specific bottlenecks or issues, which again... you fix with a new prompt...
> I only check the code architecture
Seems like a bad practice. I recently worked through a major security regression with OpenCode that requires understanding more details. Then their platform got hacked a couple days back. Too much eyes / brain free coding will come back to bite you.
What @pluc said basically. You could use stuff like https://bte.mills.io and https://git.mills.io/prologic/squint to help test/validate the "behaviour" of what is being developed/built. Try to think of yourself as the "Product Designer" and "Product Owner". Worry less about the _actual_ code itself, and more about how the software/product behaves. Write specifications that can be validated and ask yoru favourite coding assistant to ensure that those are validated.
Trigger automated review at the end of CI, but do stay very in the loop, both during development and review. This idea that you can let the machines write and decide things, and you just need to check, is the wrong approach. Tell the bots what the architecture should look like and how the core loops should work. These are places our machine gods make poor decisions and many mistakes.
Writing tests should be "practically free" too
[flagged]