I'm a principal engineer. Code reviews still matter for production software.
Maybe your opinion is that I'm not vibe coding hard enough, and if I did AI better we wouldn't need code reviews. I disagree - both engineers and LLMs are still adding unneeded complexity or choose the wrong abstractions in ways that will cause problems down the road, don't think about all the corner cases, and pick the wrong handling for error conditions. They add in things that seem like a good idea to them and don't stick to the spec.
If my company stops doing code reviews for the software that matters, I'll quit.
Engineers not in the startup crunch should aim for using LLMs to code better, not faster. Faster just creates technical debt and ups your long term costs.
The fundamental issue is that traditional code review doesn’t scale.
I now use a “Controls” linter which applies deterministic methods to constrain AI output, requires explicit declaration when key resources are used (file system access, network egress, outside libraries, or whatever I feel is important), and ties directly to other external requirements for business level controls that may be audited. (And more, but this gets the idea across)
Individual control violations can block PR mergers, block release, or just flag for review.
I genuinely don’t care that much about AI code quality these days (though I exclusively use SOTA models like Astra, which could be related). I care about code structure and architectural quality. I’ve found those can be deterministically enforced and made visible. If structure and architecture are high quality, I have no need to nitpick code quality.
If I were working with humans, this system would be cruel. It is far harsher than any manual code review I’ve ever given to humans. I let humans get away with small issues all the time. Dealing with the consequences of small mistakes is how people learn. For anything that really matters, I am ruthless with AI developers.
The system itself needs to be audited, so code review is still necessary. It’s more spot checking than full review though. You need to be a decent traditional software developer and architect to build new controls and to run control audits.
I think it also depends on what kind of software you are writing.
If you're in finance, aviation, or some other industry where the cost of errors is very high, I do kinda want a human to look at every line of code even today.
Agree here. At my current place we have LLM apply deterministic rules where given thing cannot be checked statically. For example - all unit tests shouldn't access database. This can be checked statically. All comments should document why, rather than what - this cannot.
Humans tend to bring up things that matter to them + correctness, when they have time to think about it.
There are definitely areas where I’m reviewing individual lines. Protocols are high on the list. I always want to know that high-level services aren’t leaking their internal details to the outside world and that whatever entity owns a protocol is controlling what is being communicated.
AI is bad at certain kinds of abstraction (for now). For example:
Connect service A to service B. Service C exists in some deployments and will do the real work in those cases, but A must never use B as a passthrough to C or use C’s language. That would cause future planned changes in the app to require a massive refactor.
Then, later, in review: Why is A’s client protocol to B referencing functionality that only exists in C? B’s entire purpose in life is to prevent this!
I haven’t tried to solve this via automation yet. I think it will involve limiting what AI has access to.
How could I learn more about this linter approach (especially around architecture quality)? Any other terms to describe it or resources that explain it?
Declare and deterministically detect the entities you want to control. Figure out how to list them. Then, write rules that enforce structure and behavior of or between those entities.
It’s just lots of declaration, detection, and fancy tests. But you need to apply a lot of attention to detail and make sure you have confidence that a given rule is enforced, and that a given entity can be detected. There’s more to it than that, but if you start playing around I’m sure you’ll figure the rest out.
I will warn that the goal isn’t to get AI to write code like a human would. It’s to enable controlled, high-velocity AI-driven SDLC that scales to large, complex applications.
Code reviews matter in the sense that you need to check the code is reasonably sane occasionally, but that's not the same as doing PRs. Leaving checks to the end has always been a dubious strategy - it's a lot easier to catch problems if you're designing the code up front and then reviewing that things are on track during the dev process. Finding that there's a problem at the end is the worst possible time to change something.
AI has solidified notion that for me. When your team are cranking out PRs at a rate of several a day (not building faster; making small, atomic change requests of independent bits) you'll never have the bandwidth to review everything by hand. You need time at the start to understand the change, lots comms during the process of making the change, and lots of automation around deterministic tooling (linting, formatting, unit tests, integration tests, e2e tests, fuzzing, property testing, smoke tests, etc) to make sure your AI change hasn't broken anything. If you have that in place the need to review at the end of a change is greatly reduced. Down to zero in my opinion but your milage may vary.
> both engineers and LLMs are still adding unneeded complexity or choose the wrong abstractions in ways that will cause problems down the road
Completely agree. But why do you think the reviewer would choose a better abstraction?
Yes, an experienced dev has a high chance of doing so. But in most teams there are not enough experienced devs.
And even I, an experienced dev, choose wrong abstractions all the time.
But fixing even large oopsies is just a prompt away. So imo it does matter less and less.
What was and is true: iteration speed just matters more. I would bet a lot of money that a team that goes from written code to merge in hours has a better quality codebase than one that takes weeks.
"Fixing large oopsies is just a prompt away" really depends on what you are doing.
I write software responsible for updating customer controlled devices. In theory, these devices may be in use for decades. I don't get to dictate when customers update their software. I have to use whatever software is on device as part of the update process, and the software update process really should work from every single version that's ever been deployed.
So whatever decisions I make / the team makes, generally we're stuck dealing with in some form for the device lifetime.
there is also sentiment I see that engineers should move from the code review to the testing of the end result. which is nonsensical because with the code review you can catch problems which are borderline impossible to catch via testing. but
the code review requires a tamed agent producing comprehensible code.
We decided that we know the system well enough that we can self approve PRs
I would say people might have slightly different opinions I. The company, but in general, if it is not critical and it can go to preprod to check, we can merge.
I particularly do an automated code review and use some setup to check idea, code and documentation. But if it is critical or too important to go wrong I seek for code reviews.
The cost of writing code has gone down but not the cost for engineering.
I see my friends struggling with vibe coded projects because they didnt plan how to grow the baseline.
The line got blurred as it became cheaper to do-redo but you can check any vibe-coder code cost through time and it does increase at least linearly.
I will say that now it is easier to plan specific changes that can put in and out in case of problems whether before we would need to do several rollout steps so multiple people could work on a task.
Now several people work on several things and the struggles are others.
Code quality has been a pain for everyone.
I think for an LLM doing things one way or the other is a matter of what fitted the chances by the prompt and not good practices or choices. By this I mean, if there are two ways of writing the same code and one is clearly harder to read or performs worse, it can be more a matter of being lucky/unlucky to get it right throughout the whole code.
There are weeks I get 30 PRs done, there are weeks I get 3 PRs, like it was before.
But reading LLM code is painful. It is obtuse and without lots of guidance it invent rules to problems that do not exist.
Of course I see that from my bubble, but I guess as experienced engineers are seeing the problems piling up and it the models are getting more expensive and not getting better as faster as before.
These three things can be where we will delimit the usage of LLM for coding.
I particularly like that I don't need to do some of the annoying tasks that took me only checking 48302 files to be sure I got all the same string correct because some past bad decisions. But when I am working in important stuff, the cracks in llm makes me much slower.
A personal challenge has been to keep up knowing the codebase well enough while people (including me) are dumping stuff in there.
> still adding unneeded complexity or choose the wrong abstractions in ways that will cause problems down the road, don't think about all the corner cases, and pick the wrong handling for error conditions.
These are all one of those things which have never been easily quantifiable and therefore not easily sold to the stakeholders (your boss, boss of your boss, etc.). The AI will only emphasize this condition.
I have already seen the LLM hallucinate prompts from me - in this case, hallucinating being asked to switch to a different programming language - because it wasn't able to complete the task asked for in a satisfactory way instead of giving up and telling me it's not able to do it.
If it doesn't already, I suspect training needs to include those no-solution scenarios and reward not overstepping bounds, or else we're going to see a lot more harmful side effects.
This sounds like fun, but I'm not sure how changing build systems fixes the vendor problem. They will just ship their proprietary blobs built on top of this new build system instead of the old one, and will not change other behavior. Buying from vendors who upstream or minimally open source their work might help.
I'm a little doubtful on the post's assertion that yocto is only needed for "deeply embedded regulated products." For products that have to follow the https://en.wikipedia.org/wiki/Cyber_Resilience_Act coming up, they will almost certainly need:
And I'll echo what some other folks have said here: if you don't need features like that, bundle your custom bootloaders and kernel with a binary distribution like Debian and call it a day.
There's a relatively easy technological solution to mold: buy a dehumidifier.
We bought two after moving to Ireland. Both have drainage hoses. One has a pump and empties into the kitchen sink, the other has no pump and the drainage hose empties into the shower. No more mold problems.
Thank you for sharing. Do your dehumidifiers run all the time? Do they have some kind of auto on / auto off feature? Do you run them on some schedule? As necessary? I am thinking it would be very easy for me to forget unless it is a set it and forget it kind of thing.
Ours has been on constantly for nearly a year. Any decent one has humidity set points - we set ours for 55%. It's a bang-bang controller with a 5% range - it'll run until humidity drops to 52%, then turn off until it rises to 57%. During the winter our single one struggles to get much below 60%, we might add a second next year.
An unexpected benefit (for us, as its not something we're used to) is its virtually "free", as we don't have to run the electric clothes dryer anymore (nearly €4/load). We just hang the clothes on a rack by the dehumidifier and it dries them out in a few hours. My wife is starting to prefer it as its not destroying clothes nearly as quickly.
> An unexpected benefit (for us, as its not something we're used to) is its virtually "free", as we don't have to run the electric clothes dryer anymore (nearly €4/load). We just hang the clothes on a rack by the dehumidifier and it dries them out fairly quickly.
It’s not free as the dehumidifier has to do more work. If you have a modern heat-pump clothes dryer you might be using more electricity by abusing your humidifier like this.
"Free" as in our electric bill was basically unchanged before and after it; and we still get 10-15% lower humidity on average which has taken care of our (minor) mold problems.
I used to be in a house that needed a dehumidifier. I bought one with a built-in pump to empty the water tank, which can be tapped into an AC drain line, sink drain, or directly outdoors, depending on your situation. You can set many of them to run constantly or when humidity is above a certain level.
If you live in a hot/humid location your HVAC is much better at dehumidification than a dehumidifier, since a dehumidifier outputs a ton of heat to operate. But in a cool/humid location, you can definitely rig up one to be decently set and forget. You still need to perform maintenance (cleaning the grill, adding a bit of white vinegar to the water tank to kill growth buildup, etc).
I actually put mine into the HVAC cabinet and used a smart plug and smart thermostat to turn on the dehumidifier and the HVAC fan to dehumidify the house. But that’s way more than you need to do for a small apartment.
Hah, if you ever used the N800 media player you will have been exposed to a tiny bit of my code. Some of the UI polishes and usability tweaks were mine. (Well, someone else had figured out they needed to be done and the bug landed on my lap...)
"/* Here be dragons */" in a particularly hideous d-pointer punching chain must have been a surprise for whomever eventually picked it up.
It's great marketing! But yes. He considers it an error to specify "Use the same knife for the jelly" even though it's considered correct to state "Wipe the knife clean before using it for jelly". The latter statement implies the former, and if you follow all the instructions both are not wrong.
I also consider some of the instructions to be under specified. For example, a piece of bread could be said to have 6 sides, but only 2 of those are helpful for making a sandwich.
I'm just annoyed I lost points for specifying both "Open the peanut butter jar" and "unscrew the lid of the peanut butter jar". The first one's context! The second "more precise" version doesn't specify what you should do with the now-unscrewed lid and the obvious solution, for a robot that takes things literally, is to leave it sitting on top of the jar.
Does that mean I'm not in control of when and what I use them for?
reply