Sometimes it can be useful to get a second perspective on things, what’s better than one AI working for you, perhaps two? Check out the video:
In this video, Erik shares a practical workflow he’s been using that pairs two of the most capable (and most expensive) AI coding assistants — Astra (OpenAI’s Codex) and Fable (Anthropic’s Claude) — to build and refine AL code for Business Central. The approach uses one AI to build the application and the other to critically review it, creating a productive feedback loop that catches bugs and improves code quality.
The Power Couple: Why Two LLMs?
Erik has been experimenting with using two different large language models in tandem, and the results have been very positive. The core idea is simple: use one AI to build the code and a different AI to review it, essentially pitting them against each other to get a fresh perspective on potential issues.
He’s upfront about the cost: Astra and Fable are by far the two most expensive AI services available right now. But for building AppSource apps, even these premium models are significantly cheaper than hiring additional developers. His reasoning: why use a lesser product when a better product is available?
That said, Erik acknowledges you could adapt this approach to work with less expensive models — using Opus versus Sonnet, for instance — or even with locally hosted LLMs.
The Demo App: A Rental Application
To demonstrate the workflow, Erik shows a rental application for Business Central that was built entirely by Astra (Codex). The app handles the core fundamentals of a rental business:
- Inventory and fixed asset assignment — marking items as available for rental
- Rental contracts — with start dates, end dates, and billing frequency
- Availability tracking — showing when assets like trucks are available, reserved, or out for maintenance
- Reservation management — tracking the status of each asset across dates
- Invoicing — generating invoices for rental periods
In the demo, Erik shows a rental contract for a truck being rented out for three days in February, with the contract in a “reserved” status getting ready to be activated. The fixed asset availability view shows the truck’s status across different dates — available on some days, rented on others, and sent for maintenance on yet another date.
The Workflow: Build with One, Review with the Other
Here’s where the “power couple” dynamic comes into play. The workflow has three distinct phases:
Step 1: Build with Astra (Codex)
Erik uses Codex to build the application. Codex handles the code generation, makes architectural decisions, and maintains context about why things were built a certain way. This is the primary builder.
Step 2: Bug Hunt with Fable (Claude)
Once the app is built, Erik opens Claude and asks it to do a bug hunt — reviewing the entire application for issues. The key insight: you don’t need to provide much context anymore. There’s already documentation written, and the AI goes through the codebase methodically.
After about 116 seconds of analysis, Claude returned a list of potential issues:
- “Likely to bite in production” — serious issues that would cause problems in a live environment
- New contract defaults clobbering user input — when creating a new quote, selecting a customer and then adding items could overwrite previously entered start/end dates and billing frequency. Erik confirmed this was a real usability problem he’d already noticed.
- Work date and “today” are mixed — inconsistent date handling throughout the app
- Invoice generation confirmation dialog issues — the process could pop a confirmation dialog and silently keep the wrong date
Step 3: Validate Findings Back in Codex
Rather than asking Claude to fix the bugs directly, Erik takes Claude’s findings back to Codex. This is crucial — Codex still has the context of building the app, including the decisions made and where things are located. Even if the conversation has been long, Codex retains compacted context and memories from the build process.
The prompt isn’t “fix these bugs.” Instead, it’s “are these bugs valid?” This creates a productive back-and-forth:
- Inefficient resource log — marked as “partly valid.” The paths in question don’t require the resource row log in every case, but the log table affects reads across regular variables.
- Contract insertion triggers — validated with evidence from the codebase
- Confirm behavior check — marked as missing, but the wrong billing scenario wasn’t actually established
- Several other findings — marked as “valid and important”
The result is a refined, higher-quality list of issues where the bugs found by one AI have been critically evaluated by the other.
Why Different Providers Matter
Erik notes that you could technically do this with the same provider — just open another task or thread and have it review the work. But he finds that using different providers gives you a genuinely different perspective on how things should be done. Each model has different assumptions, different strengths, and different ways of evaluating code quality. That diversity of opinion has been “surprisingly effective.”
On his actual AppSource projects (not just the demo rental app), this approach has surfaced issues where one AI flags something as a bug, but the other explains why it’s actually intentional — or vice versa. Ideally, you’d want the two AIs to have a direct conversation about these disagreements, but that capability isn’t here yet.
Erik’s Operating Philosophy
Erik emphasizes that the “just build me an entire app” approach isn’t how he normally operates. While he’s done it for demos and experiments, his real workflow is much more hands-on:
- He makes the plan (possibly discussing it with AI)
- He gives specific, scoped tasks: “do this, then do that”
- He operates in what he calls the “I know better overlord” mode — directing the AI rather than letting it make all the decisions
The bug hunt / cross-validation pattern fits naturally into this philosophy. It’s not about replacing developer judgment — it’s about getting a second opinion and a fresh perspective from a different intelligence.
Conclusion
Using two different AI models as a “power couple” for AL development creates a valuable feedback loop: one builds, the other critiques, and the builder validates the critique. This pattern catches real bugs, identifies usability issues, and produces higher-quality code than either model would achieve alone. While Astra and Fable represent the premium end of the spectrum, the underlying pattern — build with one AI, review with another — can be adapted to whatever models and budget work for your situation. Give it a try and see if the cross-pollination of AI perspectives improves your own AL development workflow.
