Introduction: The Uncomfortable Question
Software projects are still failing at alarming rates—despite decades of “Agile adoption.” Engineers are burning out in London, Bangalore, New York, and Tokyo. Morale is collapsing. Quality is declining. The methodologies we were told would save us—Scrum and Kanban—are often making things worse.
Agile promised adaptability, but delivered rigid rituals. Agile promised collaboration, but delivered status meetings. Agile promised quality, but delivered technical debt.
The problem is not Agile’s values. The problem is the way Agile has been packaged, sold, and dogmatized around the world. It is time to rethink Agile—not abandon it, but evolve beyond it.
This article examines the structural flaws of Scrum and Kanban honestly. Not to dismiss Agile values—those remain sound. But to expose the gap between what these methods claim to do and what they actually do, especially for serious, long-running software systems. Then it points toward a method that addresses the flaws directly: Albatross.
Part One: The Structural Flaws of Scrum
1. Sprints Are Arbitrary; Components Are Not
The sprint is Scrum’s fundamental unit of planning. Work is broken into two-week (or one-month) increments. The team commits to a sprint backlog. At the end, something should be “done.”
But software is not composed of two-week units. It is composed of logical, interconnected components. A database schema, an authentication module, an API gateway, a UI layer—these have natural boundaries defined by architecture, not by calendar.
Forcing components into fixed sprints creates dependency hell. A component that takes three weeks must be split across two sprints, creating artificial handoffs, incomplete work, and integration problems. A component that takes three days leaves the team scrambling to fill the remaining sprint time with busywork.
The sprint does not respect the structure of the software. It imposes an external rhythm that the software did not ask for and cannot accommodate.
2. Velocity Is a Treadmill, Not a Metric
Scrum uses velocity—story points completed per sprint—as a measure of team productivity. In theory, it is a planning tool. In practice, it becomes a performance metric.
If a team delivers 30 points this sprint, management expects 31 next sprint. If they deliver 28, questions are asked. The number must go up. Engineers learn to inflate estimates. They learn to split stories to inflate point counts. They learn to avoid hard tasks that might not finish within the sprint.
The 2024 DORA report found that AI adoption in coding is associated with larger batch sizes, and “bigger changesets are riskier” [14].
Velocity does not measure value. It measures conformity to an arbitrary unit. And because it is used as a performance metric, it corrupts the very planning it was meant to support.
3. Stand-ups Become Status Reports
The daily stand-up is meant to be a brief synchronization—15 minutes, three questions, no problem-solving. In practice, it becomes a status-report ritual. Engineers spend their first hour of the day anxious about what they will say. Managers attend to monitor progress. The stand-up becomes a surveillance mechanism, not a coordination tool.
A peer-reviewed grounded theory study of daily stand-up meetings found that “the factors that contributed the most to a negative attitude were status reporting to the manager and that the frequency of the meeting was perceived to be too high and the duration too long” [10]. Positive attitudes came from “information sharing with the team and the opportunity to discuss and solve problems”—not from status reporting [10].
Worse, the stand-up interrupts flow. An engineer in the middle of solving a complex problem must stop, formulate a status update, and then try to re-enter the mental state they were in. The cost of context switching is real, and Scrum imposes it daily.
4. Retrospectives as Gaslighting
The sprint retrospective is meant to be a safe space for process improvement. Teams identify what went well, what went wrong, and what to change.
But in most organizations, nothing changes. The team identifies the same problems sprint after sprint. Management listens, nods, and does nothing. The retrospective becomes a ritual of performative honesty followed by institutional silence.
The second edition of Agile Retrospectives (2024) states plainly: “Without a doubt, the most common reason why people become retrospective skeptics is because of a belief that Nothing Changes Anyway. It’s the sense, grounded in that person’s experience and reality, that retrospectives are a waste of time because they don’t actually lead to real improvements and change” [7].
This creates learned helplessness. Engineers stop believing that their feedback matters. They stop offering honest assessments. The retrospective becomes another meeting to endure, not a mechanism for improvement.
5. “Done” Does Not Mean Done
Scrum defines “done” as the state in which a product increment meets the team’s definition of done [4]. In practice, “done” often means “code written and unit tests pass.” It does not mean integrated, documented, verified, or understood.
Because the sprint must end, unfinished work is declared done. Technical debt is hidden. Integration is deferred. Documentation is skipped. The next sprint begins with a foundation of hidden incompleteness.
This is not a failure of individual engineers. It is a structural incentive. The sprint boundary rewards closure over completeness. Engineers respond rationally to the incentives they are given.
6. No Design Phase
Scrum does not include a design phase. It assumes design emerges through iterative development. In practice, this means design happens implicitly, inconsistently, and often too late.
Jan Bosch, a software architecture researcher, observes: “One of my concerns with the Agile paradigm is that it ignores architectural questions, considering them out of scope. Of course, we’ve compensated for that and added architecture activities, but the challenge remains: the paradigm doesn’t provide a constructive way to deal with architecture beyond the principle of fixing it as you go” [8].
A team begins coding without a clear architecture. Components are created ad hoc. Interfaces are defined by whoever writes the calling code first. The system grows organically, but not coherently. By the time architectural problems become visible, the cost of fixing them is enormous.
7. The Product Owner Assumption
Scrum assumes a product owner who knows what to build, can prioritize effectively, and has the authority to make decisions [3]. In practice, many product owners are middle managers relaying messages from above, or business analysts without decision authority, or founders who change their minds weekly.
When the product owner does not know what they want, the sprint becomes a guessing game. Engineers build what they think is wanted. The product owner sees the result and changes direction. The cycle repeats. Velocity is maintained, but progress is illusory.
Scrum does not solve this problem. It assumes it away.
8. Moral Injury
Engineers know when they are building on shaky foundations. They know when shortcuts will cause problems later. They know when a feature is half-baked but shipped anyway to close a sprint.
Being forced to prioritize speed over quality, repeatedly, against one’s professional judgment, causes moral injury. It is a form of distress that accumulates over time. It leads to burnout, cynicism, and departure.
Scrum’s defenders say the method is not the problem—bad management is. But a method that assumes good management and provides no protection against bad management is not a good method. It is a method that works only in ideal conditions that rarely exist.
Part Two: The Structural Flaws of Kanban
1. Flow Without Direction
Kanban visualizes work on a board. It limits work in progress. It measures cycle time. It optimizes flow.
But flow to where? Kanban does not answer this question. It shows you where work is. It does not show you where work is going, what depends on what, or what the critical path is.
A Kanban board can be perfectly balanced—smooth flow, short cycle times, no bottlenecks—while the project is heading for disaster because a critical dependency was ignored.
2. Reactive, Not Proactive
Kanban is a reactive system. It shows you where the bottleneck is. It does not show you where the bottleneck will be.
By the time cards pile up in a column, the delay is already baked in. By the time cycle time increases, the problem has already occurred. Kanban is excellent at diagnosing problems after they happen. It is poor at preventing them.
For manufacturing, this may be acceptable. For software development, where dependencies are complex and delays compound, it is not.
3. No Dependency Visualization
Kanban boards are flat. Columns represent states—To Do, In Progress, Review, Done. Cards move left to right. Dependencies between cards are invisible.
Industry analysis confirms this limitation. A comparison of Kanban boards and Gantt charts notes that Kanban’s approach to dependencies is “visual blockers & waiting states,” while Gantt charts provide “dependency mapping, explicit task sequencing” [15]. Kanban shows you where work is stuck. It does not show you why, or what the downstream consequences are.
Consider a system with components A, B, C, D, E, and F, where A must be completed before B, B before D, and D before F. The critical path is A → B → D → F. If A is delayed by two weeks, F is delayed by two weeks—regardless of how fast C and E are completed.
A Kanban board does not show this. It shows six cards moving through columns. It does not show that one card is on the critical path and another is not. It does not show that helping with C is useless while A is stuck. It does not show that the project will be late even if every column is balanced.
4. No Committed Delivery Date
Kanban provides forecasts, not commitments. It can tell you the probable cycle time for a card. It cannot tell you when the project will be done.
For some contexts, this is fine. For enterprise projects with regulatory deadlines, contractual obligations, or coordinated launches, it is not. Stakeholders need to know when the system will be ready. Kanban cannot tell them.
5. The Manufacturing Confusion
Kanban originated in manufacturing. Toyota used it to manage production on the factory floor. In manufacturing, the design is fixed. The process is repetitive. The goal is to produce identical units efficiently.
Software development is not manufacturing. It is product development. The design is not fixed. The process is not repetitive. Each component is unique. Dependencies matter. The critical path matters.
Applying manufacturing Kanban to software development is a category error.
6. WIP Limits as a Substitute for Planning
Kanban’s WIP limits prevent overload. They ensure that work flows smoothly. But WIP limits are not a planning tool. They do not tell you what to work on first. They do not identify the critical path. They do not help you allocate resources to the most important work.
A team can have perfect WIP discipline and still fail because they worked on the wrong things in the wrong order.
7. Continuous Delivery Without Continuous Value
Kanban optimizes for continuous delivery. But delivering continuously is not the same as delivering value continuously. If the delivered increments do not cohere into a working system, continuous delivery is just continuous waste.
Without architecture, without dependency management, without a clear critical path, continuous delivery can produce a stream of disconnected components that never integrate into a coherent whole.
Part Three: The Shared Flaws of Scrum and Kanban
1. No Design Phase
Neither Scrum nor Kanban includes a design phase. Both assume design emerges. Both defer architectural decisions until they are most expensive to make.
A good design isolates components, defines interfaces, and establishes boundaries. It makes the system comprehensible and maintainable. Without it, components are entangled, interfaces are implicit, and the system becomes a ball of mud.
Agile methods do not reject design. They simply do not include it. And what is not included is not done.
2. No Debt Management
Neither Scrum nor Kanban manages technical debt. Debt is invisible on the board. It is not a card. It is not a story. It is not a sprint goal. It is not tracked, measured, or resourced.
Debt accumulates silently. Refactoring is deferred because it produces no visible feature. Documentation is skipped because it does not close a sprint. Tests are minimized because they do not deliver value to the customer. Architecture is neglected because it is not on the backlog.
By the time debt becomes visible—through slowing velocity, increasing defects, or declining morale—it is already severe.
3. No Comprehension Management
Neither method treats comprehension as a deliverable. A story is done when the code works. It is not done when a human can explain it, modify it, or debug it.
This is a critical flaw. Code that works but is not understood is a liability. It cannot be safely changed. It cannot be safely extended. It cannot be safely replaced. It is a black box that will eventually fail, and no one will know how to fix it.
4. Feature Factory Dynamics
Both methods optimize for visible output. Stories are completed. Cards are moved. Velocity is maintained. Features are delivered.
But visible output is not the same as value. A feature that is half-baked, poorly integrated, or architecturally inconsistent is not valuable. It is debt disguised as progress.
The feature factory rewards delivery over quality, speed over sustainability, and output over outcome. Engineers respond to these incentives. They ship code that closes tickets, not code that solves problems.
5. No Central Control
Both methods assume distributed decision-making. Teams self-organize. Priorities emerge. Architecture evolves.
In practice, this means no one is responsible for the coherence of the whole. Each team optimizes its own work. Interfaces drift. Dependencies are ignored. The system becomes a collection of locally optimized parts that do not work together.
Some coordination is necessary. Someone must own the architecture. Someone must manage dependencies. Someone must ensure that the parts cohere into a whole. Neither Scrum nor Kanban provides this role.
6. Assumption of Competence
Both methods assume a competent product owner, a competent team, and a competent organization. They provide no protection against incompetence. They provide no mechanism for detecting dysfunction early.
A method that works only when everyone is competent is not a robust method. It is a method that works in ideal conditions and fails everywhere else.
7. The Global Problem of Copying Without Thinking
Around the world, IT industries suffer from an inferiority complex toward Silicon Valley. Companies import methodologies (Scrum, Kanban, SAFe) without understanding the underlying principles—or whether they even fit the local context.
This happens everywhere. In Europe, enterprises adopt US frameworks to appear “modern,” even when their regulatory environments demand meticulous upfront planning. In Asia, companies copy US rituals without adapting them to local work cultures. In Latin America and Africa, startups import Silicon Valley playbooks that assume venture capital funding and high turnover, neither of which apply locally. Even in the US itself, many companies have adopted Scrum so dogmatically that they have lost sight of the original Agile values.
The result is global: theater, not results. Burnout, not productivity. Technical debt, not quality. Cynicism, not engagement.
Part Four: How Albatross Solves These Problems
Albatross is a proactive, component-based methodology. It is architecture-centric, component-based, feedback-integrated engineering. It assumes a functional organization—where product owners know their domain and developers are trusted to estimate accurately.
1. Sprints are arbitrary; components are not.
Scrum forces work into fixed two-week increments that do not match the structure of software. Kanban avoids sprints but still provides no natural unit of completion.
Albatross replaces sprints with component-based delivery. The system is decomposed into a DAG of small, logical components. Each component is completed at its natural boundary. There is no calendar forcing premature closure.
2. Velocity is a treadmill, not a metric.
Scrum measures story points per sprint, which becomes a performance metric and creates perverse incentives. Kanban measures cycle time but does not measure progress toward a defined goal.
Albatross estimates in actual hours and measures progress by components completed and critical path advanced. The metric is tied to real deliverables, so it cannot be gamed the way story points can.
3. Stand-ups become status reports.
Scrum requires daily stand-ups that interrupt flow and become surveillance. Kanban has no such ritual but also provides no structured communication.
Albatross does not require daily stand-ups. Developers follow the Gantt chart for task assignment. Help is requested when needed. Visibility is provided by the plan, not by a daily meeting.
4. Retrospectives without action are gaslighting.
Scrum holds retrospectives that often produce no change, leading to learned helplessness. Kanban has no equivalent mechanism for improvement.
Albatross uses continuous feedback integration. Each component is validated with the product owner upon completion. Feedback is tied to a concrete deliverable, so it produces action rather than frustration.
5. “Done” does not mean done.
Scrum’s sprint boundary rewards declaring work done before it is integrated, verified, or understood. Kanban has no definition of done at all.
Albatross defines done at the component level: implemented, verified, tested, reviewed, and understood by a human. There is no boundary forcing premature closure.
6. No design phase.
Neither Scrum nor Kanban includes design. Architecture emerges—or fails to emerge. Bosch confirms Agile “ignores architectural questions, considering them out of scope” [8].
Albatross is architecture-first. The UI prototype and overlook design are completed and validated before coding begins. Architecture cannot be neglected until it is expensive to fix.
7. The product owner assumption.
Scrum assumes a competent product owner and provides no protection when that assumption fails. Kanban assumes clear priorities and does not address where they come from.
Albatross requires the product owner to articulate what they want before coding begins, through the UI prototype and overlook design. If they cannot, the project does not start. The problem is surfaced before resources are invested.
8. Moral injury.
Scrum forces engineers to choose between speed and quality, repeatedly. Kanban offers no structural protection against this either.
Albatross removes the structural incentives that cause moral injury. No arbitrary sprints. No velocity treadmill. Component-level completion ensures quality. Engineers are not forced to choose between speed and quality.
9. Kanban: flow without direction.
Kanban optimizes flow but does not show where work is going or what the critical path is.
Albatross uses a DAG and Gantt chart to show dependencies and the critical path. Flow serves the project’s objective rather than being an end in itself.
10. Kanban: reactive, not proactive.
Kanban shows where the bottleneck is, not where it will be. By the time cards pile up, the delay is already baked in.
Albatross is proactive. The Gantt chart identifies the critical path before work begins. Resources are allocated to critical components first. Delays are prevented, not discovered.
11. No dependency visualization.
Neither Scrum nor Kanban visualizes dependencies. Kanban’s approach is “visual blockers & waiting states,” while Gantt charts provide “dependency mapping, explicit task sequencing” [15].
Albatross makes dependencies explicit. The DAG shows which components depend on which. The Gantt chart shows how delays propagate along the critical path.
12. No committed delivery date.
Kanban provides forecasts, not commitments. Scrum provides sprint goals, not project completion dates.
Albatross provides a committed delivery date. The Gantt chart maps components and dependencies onto a timeline. The critical path determines the completion date.
13. No debt management.
Neither method manages technical debt. Debt is invisible on the board and not resourced.
Albatross bounds debt within components. A well-designed component has well-defined interfaces. Debt inside a component is reworked when the component is replaced. Bounded debt is manageable; unbounded debt is not.
14. No comprehension management.
Neither method treats comprehension as a deliverable. Code that works but is not understood is a liability.
Albatross makes comprehension a completion criterion. A component is not done until a human can explain it, modify it, and debug it. This fits naturally into component-level verification.
15. Feature factory dynamics.
Both methods optimize for visible output—stories completed, cards moved—rather than value delivered.
Albatross optimizes for component completion and quality. Progress is measured by the critical path advanced and the project delivered. Features are completed as components within an architecture, not shipped to close a sprint.
16. No central control.
Both methods assume distributed decision-making. No one is responsible for the coherence of the whole.
Albatross assumes a manager with central control. The manager owns the architecture, manages dependencies, and ensures coherence. Verification is distributed to all developers. If the system is too big for one manager, the organization creates a cascade of managers.
17. Assumption of competence.
Both methods assume competence without providing protection against incompetence.
Albatross requires competence and reveals incompetence early. If the product owner cannot articulate what they want, the project does not start. If the manager cannot maintain central control, the method reveals it before the project is lost.
18. The manufacturing confusion.
Kanban originated in manufacturing, where the design is fixed and the process is repetitive. Software development is product development, not manufacturing.
Albatross treats software development as product development. It includes a design phase, manages dependencies, and uses Gantt-like charts—the tools appropriate to unique, dependency-heavy work.
Part Five: The AI Age Accelerates These Flaws
The Evidence on AI and Debt
The evidence on AI-generated code and debt accumulation is stark:
- GitClear’s analysis of 211 million changed lines of code across major repositories found that over the same period (2021–2024), lines classified as “copy/pasted” (cloned) rose from 8.3% to 12.3% of changes, while refactoring—lines “moved” as part of code restructuring—dropped from 25% of changed lines in 2021 to less than 10% in 2024 [13]. This is the first time in the dataset that duplication outpaced refactoring.
- Google’s 2024 DORA report found a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability in environments where AI had been adopted [14].
These findings support the argument that AI accelerates the accumulation of both technical debt and comprehension debt when used without structural safeguards.
Why This Matters
If code generation is cheap but comprehension is expensive, a method that does not treat comprehension as a deliverable will accumulate comprehension debt faster than ever. If AI produces larger changesets, and larger changesets are riskier [14], a method that does not visualize dependencies or the critical path will fail to detect integration risks until they compound. If AI produces cloned code faster than humans can refactor it [13], a method that does not manage technical debt explicitly will allow debt to spread unchecked.
The flaws identified in Parts One through Three are not new. But AI accelerates their consequences. A feature factory with human-speed code generation might survive for years. A feature factory with AI-speed code generation will hit the wall sooner.
How Albatross Responds
Albatross’s design is well-suited to the AI age because it already treats the three scarce resources—architecture, comprehension, and dependency management—as first-class concerns.
- AI operates within components. The DAG defines component boundaries. AI agents generate code for specific components, within defined interfaces. They cannot violate the architecture because the architecture constrains them.
- Verification is distributed. Every component’s development includes verification, test, and review—whether AI-generated or manual. The team owns verification. The manager does a light final check.
- Comprehension is a completion criterion. A component is not done until a human can explain it. AI-generated code is not exempt. If no human understands it, it is not complete.
- The Gantt chart reveals the bottleneck. If AI accelerates generation but verification becomes the constraint, the Gantt chart shows it. The manager allocates resources accordingly.
- Debt is bounded. AI-generated code inside a component is contained by the component’s interfaces. When the component is replaced, the debt is discarded.
AI changes the speed of some activities. It does not change the structure of the method. Generation is faster. Prototyping is faster. Refactoring is faster. Test creation is faster. But verification still takes time. Comprehension still takes time. Architecture still matters. The critical path still matters.
Conclusion: Engineering, Not Ritual
Scrum and Kanban are the default management methods of the software industry. They are taught, certified, and mandated. But adoption is not the same as effectiveness, and a method can be widely practiced while remaining structurally unsound.
The flaws examined in this article share a common root. Scrum and Kanban manage the flow of visible work. They do not manage the things that determine whether a long-running system stays healthy: architecture, dependencies, comprehension, and debt. In stable conditions, with small systems and forgiving deadlines, this gap may not matter. In serious, long-running developments, it is the difference between a system that can be changed and one that must be replaced.
The evidence assembled here points in one direction. Agile methods commonly omit architecture, and practitioners recognize the cost [8]. Retrospectives frequently fail to produce change, and practitioners know why [7]. Stand-ups often become status reporting rather than coordination, and the research confirms it [10]. Kanban cannot show dependencies, only blockers [15]. And the arrival of AI-generated code is making all of these weaknesses more consequential: duplication is rising while refactoring falls [13], and delivery throughput and stability decline as AI adoption increases [14].
None of this is an argument against Agile values. It is an argument against ritual masquerading as engineering. The response is not to abandon planning, feedback, or iteration. It is to put them on a foundation that respects the structure of software: architecture before code, components before sprints, dependencies before flow, comprehension before closure, and debt as a first-class concern rather than an invisible side effect.
Albatross is one attempt to build that foundation. It is not Waterfall, and it is not Agile ceremony. It is a method that treats architecture, components, dependencies, and comprehension as the primary objects of management, and that delivers feedback at the boundaries where the work naturally completes. It assumes a functional organization and a competent manager, and it reveals the absence of either early—before the project is lost rather than after.
The software industry does not need another ritual. It needs methods that keep understanding ahead of output. Engineering outlasts fashion.
References
[1] Scrum.org Blog. “Story Points vs Reality: What Estimation Really Shows.” July 18, 2025. https://www.scrum.org/resources/blog?uid=244234
[2] SpringerLink. “Jidoka: automation with a human touch.” Software and Systems Modeling, 2024. https://rd.springer.com/article/10.1007/s10270-024-01256-z
[3] Scrum.org Blog. “The anti-patterns of a Product Owner.” March 6, 2025. https://www.scrum.org/resources/blog/anti-patterns-product-owner
[4] Scrum.org. “What is the Definition of Done?” https://www.scrum.org/resources/what-definition-done-0
[5] Scribbr. “What Is Hindsight Bias? | Definition & Examples.” February 9, 2023. https://www.scribbr.co.uk/bias-in-research/the-hindsight-bias/
[6] Carnegie Mellon University Software Engineering Institute. “Achieving Balance: Agility, MBSE, and Architecture.” July 30, 2025. https://sei.cmu.edu/library/achieving-balance-agility-mbse-and-architecture/
[7] Derby, E., Larsen, D., & Sanger, A. (2024). Agile Retrospectives: Making Good Teams Great (2nd ed.). Pragmatic Bookshelf. Quoted in: “Agile Retrospectives, 2nd Edition.” https://www.oreilly.com/library/view/agile-retrospectives-2nd/9798888650868/f_0142.xhtml
[8] Bosch, J. “From Agile to Radical: system and software architecture.” May 26, 2024. https://janbosch.com/from-agile-to-radical-system-and-software-architecture/
[9] ScienceDirect. “The Evolution of Technical Debt from DevOps to Generative AI: A multivocal literature review.” August 26, 2025. https://www.sciencedirect.com/science/article/pii/S0164121225002687
[10] Stray, V., Sjøberg, D. I. K., & Dybå, T. “The daily stand-up meeting: A grounded theory study.” Journal of Systems and Software, Vol. 114, 2016. https://www.sciencedirect.com/science/article/abs/pii/S0164121216000066
[11] DEV Community. “Story Points After AI: When Velocity Metrics Stop Meaning What They Used To.” August 11, 2026. https://dev.to/brywritescode/story-points-after-ai-when-velocity-metrics-stop-meaning-what-they-used-to-1jkf
[12] LinkedIn. “Story Points Revisited | Kyriacos Elia.” November 26, 2023. https://www.linkedin.com/posts/kyrielia_story-points-revisited-activity-7134872878751064064–bR1
[13] GitClear. “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data.” https://www.gitclear.com/ai_assistant_code_quality_2025_research
[14] InfoQ. “2024 Accelerate State of DevOps Report Shows Pros and Cons of AI.” November 27, 2024. https://www.infoq.com/news/2024/11/2024-dora-report/
[15] Businessmap. “Kanban Board vs. Gantt Chart: Which Tool Is Better?” January 27, 2026. https://businessmap.io/blog/kanban-board-vs-gantt-chart
[16] Bitrix24. “Kanban vs. Gantt: Which View Actually Fits?” May 25, 2026. https://www.bitrix24.com/articles/kanban-vs-gantt-which-view-fits.php
[17] Safeguard.sh. “AI Code Review: What It Catches vs. Misses.” July 7, 2026. https://safeguard.sh/resources/blog/ai-code-review-benefits-and-limits