When the Orchard Ships Production Software: AI-Augmented Development in the Real World
5 min read
There’s a running joke in my lab: every application I’m writing is named after a fruit. The naming convention is non-negotiable. What is negotiable, apparently, is the scope of what ends up inside those innocently named containers.
Apple monitors system state and diffs snapshots engineered to avoid 30 MB of transient heap allocations. Lime orchestrates OS ptimizers across Windows VMs, rolls back changes, and stamps every database row with a triggered_by field for audit compliance. Plum proxies Nutanix portal content through a Redis-backed BFF with Okta SAML SSO, and I have a CURSOR_TASKS.md that, and I quote myself here, is “a 16-task design-consistency plan written for delegation to an AI code editor. This is apparently a normal thing now.”
Yeah. About that.
The Orchard, Briefly
Five applications. Five stacks. All are named after fruit.
Apple — System State Inquest is the most serious piece of software in the group. A cross-compiled C# scanner captures a Windows machine’s installed software, registry keys, and files, then uploads them to a Next.js 15/React 19 web app that diffs two snapshots via a streaming iterator specifically engineered to keep heap allocations in check. Exports are signed with Ed25519. There’s an OpenAPI spec. There are smoke tests. There is a ClaudeReview.md documenting 24 external findings that were all subsequently fixed. It is also the one named after a fruit.
Peach — Hybrid Lab Manager is a Flask 3 app for managing Nutanix Prism Central infrastructure: clusters, hosts, VMs, EUC role tagging, a Chart.js dashboard with role-coloured bars, and brute-force login protection. The inline comment acknowledging that protection is “at most 2× the configured value” across gunicorn workers is the kind of honesty that belongs in production code. models.py is 37,000 lines. It is one file.
Lemons — LE Monitoring Service monitors Login Enterprise appliances across multiple sites. Fleet health, active test runs, launchers, and results aggregated into a card-based dashboard. At 397 lines in __init__.py, it is the most focused application in the orchard. Sometimes that’s the flex.
Lime — Lab Image Modification & Efficiency Engine is the most elaborate Flask app in the collection. It connects to Windows VMs over WinRM, runs Citrix Optimizer / VMware OSOT / WDOT templates, scores results RAG, and can remediate — including capturing prior state and rolling back. Credential-free OS detection via three fallback methods. Single-leader APScheduler election via flock. Fernet encryption of credentials at rest. A simulation mode for demos. models.py is 40,000 lines. Also, one file.
Plum — Prism Linked User Matching is a Next.js 15 BFF portal that proxies Nutanix Solutions Hub content, personalizes it against the user’s registered cluster inventory, and ships with a second standalone UI — dark-first, glassmorphic, animated mesh-gradient canvas, and a K command palette. Redis-backed sessions, PostgreSQL via Drizzle ORM, Okta SAML SSO, an SSRF allowlist, and a documented Kubernetes deployment topology. Guest mode works without authentication. CI via GitHub Actions.
What Actually Changed
I’ve been building tools like these for a long time. PowerShell scripts, reporting dashboards, automation glue: the problem category is familiar. What’s different now isn’t the ambition. It’s the execution velocity.
Modern stacks have compressed what used to be multi-month scaffolding work. Next.js 15’s App Router with React Server Components means you don’t have to write your own data-fetching layer. Drizzle ORM removes the ceremony around type-safe database access. Docker multi-stage builds let you cross-compile a .NET 8 binary on Linux and bake the resulting Windows EXE into a Node image in a single docker build command. The infrastructure decisions that used to require a whole architecture meeting are now sensible defaults you pick from a short list.
But the more interesting shift is how AI fits into the development loop, not as an autocomplete engine, but as a collaborator with a defined role.
The ClaudeReview.md in Apple is a structured code review document: 24 findings, each addressed. That’s the kind of review cycle that used to require scheduling time with a senior colleague across time zones. The CURSOR_TASKS.md in Plum is a delegation artifact; it’s a list of well-specified tasks handed off to an AI code editor to execute autonomously. Both patterns point to something real: AI augmentation is most effective when the developer stays in the architect’s chair and delegates execution with precision.
These apps aren’t examples of AI writing code for a developer who stepped back. They’re examples of someone with creative ideas who moved faster because the friction of routine implementation was lower. The Ed25519 signing in Apple, the triggered_by audit field in Lime, and the SSRF allowlist in Plum are engineering decisions. They were just executed with significantly less drag.
Stack Philosophy
It’s worth noting what these apps don’t do. There’s no GraphQL. No microservices federation. No event bus. The Python apps are Flask with SQLite, because that’s the right level of complexity for what they need to do. The JavaScript apps are Next.js because the full-stack story it now tells, server components, API routes, streaming, is genuinely coherent in a way it wasn’t three years ago.
The willingness to ship a 40,000-line models.py is its own kind of pragmatism. There’s a version of this project where that file gets refactored into a proper package structure. There’s also a version where Lime does everything it needs to do, has a full test suite, and is running in production while that refactoring is still on the backlog. The second version ships.
That philosophy to pick the boring technology that fits, lean on AI to close the gap between design and delivery, and don’t let architectural perfectionism block working software is probably the most transferable thing about this project.
The Bigger Picture
What I find most interesting about building this way isn’t any single technology. It’s the compound effect: modern frameworks lower the cost of each individual decision, AI lowers the cost of implementation and review, and together they push the threshold for “something I can realistically build and maintain solo” significantly higher than it was even two years ago.
Five production-grade applications. Cross-platform builds. Kubernetes-ready deployments. Ed25519 signatures. SAML SSO. A code review workflow that surfaces and closes 24 issues. None of this is theoretical as it’s running in a lab that’s also a real working environment.
The orchard is open for business.
What does your AI-augmented development workflow look like? Are you using AI for review, generation, planning or some mix of all three? Drop a comment below, or find me on X at @kbaggerman.
Kees Baggerman
Latest posts by Kees Baggerman (see all)
- When the Orchard Ships Production Software: AI-Augmented Development in the Real World - May 17, 2026
- Nutanix Documentation Script v5.0: Visual Reports, Brand Templates, and Seven Embedded Diagrams - May 15, 2026
- Nutanix AHV and Citrix MCS: Adding a persistent disk via Powershell – v2 - November 19, 2019
- Recovering a Protection Domain snapshot to a VM - September 13, 2019
- Checking power settings on VMs using powershell - September 11, 2019
![Citrix Provisioning on Nutanix AHV [Updated with PVS support for AHV]](https://blog.myvirtualvision.com/wp-content/uploads/2017/06/post-4547-card.svg){kind=small}
