Now that the cost of generating code for a feature or a bug fixes has dropped to near zero, the conversation in company has shifted a to a new bottleneck. Code Review.
And this is the big misunderstanding :
Code review is not a bottleneck which is slowing you down — it’s an early defects detect mechanism that keep your system stable and maintainable.
There are two types of cycles in the companies...
The validation cycle : Business and leadership want to test ideas fast in the market.
The stability cycle : Once an idea is validated, the focus shifts to making it reliable for paying customers.
Code review belongs to the stability cycle. Its job is to maintain the health of the existing codebase. Companies like Google have a strong code review culture where nothing gets merged until it is reviewed — see their Engineering Practices guide.
And you might think we are NOT Google; we are in an early stage and want to validate the idea quickly.
You might build a feature quickly to validate it, but speed comes at the cost of bugs. And if you ship a buggy feature, then the validation might hold true. Maybe the user didn’t use that feature not because it wasn’t needed, but because it was buggy.
Code review is a bottleneck for quick validations. But the problem is.....
What’s happening in many companies right now is a dangerous blending of these two cycles. Non-technical teammates like, PM, Designer and Customer support team have integrated AI agents directly into their workflows.
With one Slack message, a Claude or Cursor agent creates a PR automatically from user bug reports. That means engineers are drowning in the code reviews queues for code they didn’t ask for and don’t fully understand.
These two cycles require different approaches. Treating them the same creates unreliable and broken systems. Experimental work needs to be kept separate where code review does not matter so it can be scrapped without affecting the stable system.
When a senior developer reviews a PR who has the system understanding. They can:
Spot patterns that don’t fit the existing architecture
Flag known issues the codebase already handles
Share context that simply doesn’t exist in the code or prompts
Reading and inspecting code is also one of the fastest ways to reason about whether a system is extendable, maintainable, or heading toward technical debt.
And studies have shown that.
Human processes inspections and walk-throughs, (for instance) tend to be better than computer-based testing at finding certain kinds of errors and that the opposite is true for other kinds of errors (1979).
It cost six times as much to detect design defects by using testing as by using inspections (Ackerman, Buchwald, and Lewski 1989).
IBM found that only 3.5 staff hours were needed to find each error when using code inspections, whereas 15-25 hours were needed to find each error through testing (Kaplan 1995).
Source : The Code Complete 2nd Edition
AI tools also tend to create unnecessary abstractions or build things from scratch that already exist in the system. Worse, they sometimes “fix” things that aren’t actually bugs.
If you don’t read AI generated code than you won’t understand how a system works, and you can’t fix bugs reliably. You can’t just prompt : fix it, please fix it, fix it please, I will give you chocolate and expect results.
A deeper understanding of the system allows you to:
Decouple things more effectively
Reduce the overall rate of defects
Identify why something is broken, not just patch symptoms
While reviewing the code, ask deeper questions:
Does something equivalent already exist in the system?
Is there a simpler workaround?
Merging AI-generated code without proper review creates a pattern: two steps forward, one step back. And If your answer to all this is to create an AI agent to review the code, then, my friend, you are just adding fuel to the fire.
Have you seen teams skip code review in the name of speed — and what was the cost? Where do you draw the line between moving fast and maintaining system health?
Be skeptical of whatever you see on the internet. Good content may not be easily discovered. Big people are paying big bucks to gain more attention.
Bigger highlights for me are... GenUI using Flutter templates, Material UI decoupling, pluggable platform, and core packages.
Software is more sociological than technical, as it involves people.
Organizational culture influences technology, not vice versa.
Implementing AI for rapid growth leads to scalability challenges.
Considerations on system scalability and the impact of code size on compilers are crucial.
Software components are interconnected, making the system fragile.
Prioritize understanding these aspects within your organization by asking “why?” and “what if?” questions.
AI offers new possibilities for maintaining codebase architecture.
Senior professionals play a key role in building strong fundamentals and supporting junior developers.
Content creators lean more on education and teaching, while AI influencers lean more towards clicks.
Production-ready AI-powered Flutter SDK for real-time face liveness detection, replay attack prevention, and persistent face identity — powered by Google ML Kit + TensorFlow Lite. All processing runs entirely on-device with zero server calls (except one-time model downloads).
Local + managed services, upfront: OpenHuman stores its Memory Tree, Obsidian-style Markdown vault, workspace config, and local runtime state on your machine.
I am currently open for consultation part-time/full-time, specialized in mobile development with Android and Flutter. So if you are looking for someone to:
Build product architecture from scratch
Train existing developers to level up
Fix major bottlenecks in legacy codebase
Improve code quality
And most importantly, ship things faster
then reach out to me at info@burhanrashid52.com.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.