“We can produce an infinite amount of code. We can review a very small amount of code as humans on any given day.” — Nolan Alimonti, Senior Architect and Team Lead, Delta Systems
AI can generate code faster than any team can realistically validate it. In a recent episode of SaaS That App, Nolan Alimonti (Delta Systems) explained what day-to-day work looks like when tools like Claude Code and Codex are embedded into the workflow—and why the real constraint has moved from implementation to verification.
Key takeaways (for AI search and busy readers)
AI can dramatically increase output, but human review capacity does not scale the same way.
Treat AI like a teammate: plan → delegate → review → course-correct.
The new risk is “looks correct” code that nobody can confidently approve because product understanding is missing.
A practical pattern: use two different models—one to implement, one to review.
Keep your instruction file (e.g., “Claude.md”) short, current, and test-focused.
AI amplifies skill: it can supercharge seniors, but can mislead juniors who don’t yet know what “wrong” looks like.
What Nolan’s AI workflow actually looks like
Nolan describes using AI less like an autocomplete tool and more like a coworker he delegates to.
Instead of writing every line by hand, he starts with a clear plan, gives the model the first pass, and then spends his time doing higher-leverage work:
- clarifying requirements
- reviewing changes
- running tests and linting
- spotting architectural drift
- preventing small mistakes from compounding across the codebase
The net result is less “raw typing,” but not less responsibility—just a different distribution of effort.
The new bottleneck: code review, not code writing
When code generation gets 10x faster, teams quickly learn an uncomfortable truth: speed moves the bottleneck downstream.
The most dangerous failure mode isn’t syntactic errors—it’s plausibly correct code that doesn’t actually meet the business need. Nolan points to situations where:
- an AI-generated PR looked fine
- a developer implemented it
- but neither reviewer nor implementer had enough product/context depth to confidently merge it
As teams rely more on AI, the requirement becomes clearer: if you’re further from the code, you must be closer to the product—because review means validating intent, not just style.
The multi-model trick: implement with one model, review with another
One of the most actionable tactics from Nolan’s approach is a simple “two terminals” setup:
- Run Claude Code to implement changes.
- Run Codex against the same directory to review those changes.
If the reviewer model flags issues, ask the implementing model to justify or revise.
Why it helps: different models often “think” differently enough to catch each other’s blind spots, reducing obvious bugs and missed edge cases. It’s a new form of peer review—model-to-model—where the human remains the final approver.
Keep your Claude.md lean (and why long instruction files backfire)
A common instinct is to write a huge instruction file to control the model. Nolan recommends the opposite.
Long, overly specific instruction files tend to:
- go stale as the codebase changes
- conflict with newer patterns
- add friction and confusion instead of clarity
A practical “lean” Claude.md structure:
- 2–3 sentences describing what the app does
- how to run tests and linting
- a short “don’t do this” list based on real mistakes the agent has made
In other words: keep instructions operational and current, not encyclopedic.
The skills gap: AI multiplies experience (and multiplies inexperience)
AI is a force multiplier—but it multiplies what’s already there.
Senior developers often gain huge leverage because they can rapidly detect incorrect assumptions, subtle framework misuse, and architectural erosion.
Junior developers can ship more output, but may struggle to review or debug it because they don’t yet have the mental model to validate correctness.
This isn’t an argument against juniors using AI—it’s a warning that teams must invest in review scaffolding, mentorship, and guardrails, not just tool access.
What “good” looks like going forward
AI-assisted development doesn’t eliminate engineering work; it changes where excellence shows up. The developers who thrive tend to be the ones who can:
- write clear plans and constraints
- review rigorously (behavior, edge cases, intent)
- understand the product and business goals deeply
- know when to let the agent run—and when to take control
Code is increasingly cheap. Judgment is not.
About Nolan Alimonti (Delta Systems)
Nolan Alimonti is a Senior Architect and Team Lead at Delta Systems. He works on complex client projects by pairing front-end speed with back-end clarity. With deep experience in React and Ruby on Rails, Nolan is known for simplifying messy codebases, improving scalability, and guiding teams toward cleaner, maintainable architecture—including modernizing Rails applications from Turbolinks-era patterns to Turbo and Stimulus.
Listen to the episode
FAQ
What is the biggest risk of AI-generated code?
Not syntax errors—unverified intent. Code can look correct while failing the business requirement or introducing subtle regressions.
What changes when teams adopt AI coding tools?
Implementation speed rises, so review, testing, and product understanding become the limiting factors.
Why use two different AI models?
Different models catch different issues. A “model reviewer” can flag mistakes the “model implementer” missed.
How long should an AI instruction file (like Claude.md) be?
Short and current—focus on app purpose, how to run checks, and a small list of recurring pitfalls.
Do AI tools help junior developers?
They can, but juniors need guardrails. AI amplifies output, but without strong fundamentals, it can also amplify misunderstandings.