Everyone's racing to build agent orchestration. Frameworks, protocols, multi-model pipelines. Gartner titled a January 2026 research note \"Enterprise AI Will Fail to Scale Without Agentic Orchestration Platforms.\" Tools are multiplying — workmux, dmux, agent-orchestrator. The assumption is that the hard problem is coordination — if we just build better ways to control agents, they'll produce better work.
\nThat assumption is wrong. The pattern that actually works is the opposite: giving agents more independence as the work gets harder.
\nThis is the lesson from building a 424K-line production platform with AI agents. My first post covered the process — how treating AI agents like an engineering team with PRs, code reviews, and manual QA produced a platform that would take a traditional team 14-18 months. My second post covered the cost — 42% of commits were fixes, and the guardrails I built to stop the bleeding. This post is about a principle I keep rediscovering: as tasks get more complex, agents need proportionally more independence.
\nHere's the framework. Three tiers of agent independence, each solving a problem the previous tier can't:
\n| Tier | Independence | Analogy | When to use |
|---|---|---|---|
| Fire-and-forget | Low — pass input, get output | Asking someone to look something up | Quick tasks: explore code, lint, search |
| Coordinated team | Medium — shared task lists, messaging, review gates | A team working a sprint | Single feature with sub-tasks |
| Full independence | High — own context, own tools, runs its own team | A tech lead who staffs and manages their own sprint | Substantial tickets with their own lifecycle |
You wouldn't give a senior engineer a shared notebook and tell them to write their findings in it for the team lead to read later. You'd give them a branch, a ticket, and the ability to tap you on the shoulder when they're stuck. The same logic applies to agents — but most orchestration frameworks treat every agent like it should be writing in the team lead's notebook.
\nThe rest of this post walks through each tier — what it solves, when you outgrow it, and what the next tier gives you.
\nYou dispatch an agent as a function call. Pass input, get output. This is Claude Code's Agent tool, Cursor's background agents, GitHub Copilot's workspace agents.
\nWhat it solves: the \"do one thing at a time\" bottleneck. Instead of exploring the codebase, running linters, and searching for usages sequentially, you dispatch agents to do it in parallel while you keep thinking. On KomplyOS, I use this constantly — \"find every controller that touches the billing system\" and \"check if this hook is used anywhere\" running simultaneously while I plan the next feature. Code review dispatch works the same way: fire off a reviewer agent, keep working, read its findings when it's done.
\nWhen you outgrow it: the moment agents need to know what each other are doing. If Agent A changes a model and Agent B is building a service that depends on that model, fire-and-forget gives you two agents with contradictory assumptions. No shared task list. No messaging. No way for A to tell B \"heads up, I renamed that field.\" You don't find out until both are done and the code doesn't compile.
\nThis is where most of the ecosystem lives today. Addy Osmani observed that \"three focused agents consistently outperform one generalist agent working three times as long\" — and that's true, at this tier. The tmux+worktree tools being built (workmux, dmux, worktrunk) solve workspace isolation, which is necessary but not sufficient. Isolation without coordination just gives you three agents working confidently in three different directions.
\nThe rule: use fire-and-forget when the agent doesn't need to know anything about what other agents are doing, and you don't need to interact with it mid-flight.
\nAgents share a coordination layer — task lists, messaging, review gates. They're aware of each other. One agent can tell another \"I finished the API endpoint, here's the response contract.\" This is Claude Code's experimental Agent Teams feature, or custom team skills built on top of it.
\nWhat it solves: the coordination gap. When you're building a single feature that spans backend, frontend, and tests, the agents working on each layer need to share context. The backend agent decides the response shape; the frontend agent needs to know it; the test agent needs to verify it. Without coordination, each guesses independently and you spend the integration time fixing mismatches.
\nOn KomplyOS, I built custom team skills that replaced the default subagent dispatch with proper coordination. For a feature like API key rotation — backend service, controller, serializer, frontend UI, tests — I create one team with 3-4 teammates and a shared task list. The key addition was two-stage review gates: a spec reviewer who checks \"did they build what was requested?\" and a code quality reviewer who checks \"is it well-built?\" The spec reviewer has a critical instruction: \"The implementer finished suspiciously quickly. Their report may be incomplete, inaccurate, or optimistic. Verify everything independently.\" That instruction alone catches more bugs than any linting rule.
\nWhen you outgrow it: when you need to run multiple features in parallel, each with its own plan-implement-review lifecycle. Every teammate's results flow back into the parent's context window. For one feature with 3 sub-tasks, this is fine. For 3 features running 2-3 review cycles each, that's 20+ substantial messages compressing the orchestrator's memory. Older context gets dropped. The orchestrator starts losing track of what's happening.
\nThe other problems compound from there. Teammates can message each other and the orchestrator — the docs say messages are \"delivered automatically.\" In practice, I've found that a teammate deep in a multi-step implementation doesn't always act on a message until it finishes what it's doing. If the orchestrator sends a correction mid-flight, the teammate may have already moved past the point where it mattered. The interaction exists, but it's not the same as tapping someone on the shoulder and getting an immediate response.
\nThe rule: use coordinated teams when agents need to share context within a single feature, but the parent orchestrator can hold the full picture in its context window.
\nEach agent is its own session — its own process, its own context window, its own tools, its own communication channel with you. But the key difference from the lower tiers isn't just resource isolation. It's that each agent is an orchestrator, not a worker. It doesn't just implement a ticket — it plans the work, creates its own Tier 2 coordinated team, dispatches teammates for backend, frontend, and tests, runs two-stage review gates, and loops code review and completion audits until both pass clean. It's a tech lead you hand a ticket to, who staffs their own team, runs their own sprint, and delivers a branch.
\nIndependent, not autonomous — each agent still works within constraints you set: mandatory team mode, enforced review loops, worktree isolation. You can intervene at any time by switching to its tab. The independence is about resources and environment, not about decision-making freedom.
\nThis solves four things the lower tiers can't:
\nContext isolation. Each agent gets the full context window. Three agents means three independent windows, not one shared window split three ways. This is the difference between giving three engineers their own laptops versus making them share one screen. On a 424K-line codebase with complex features that touch dozens of files, the context window isn't a luxury — it's the agent's working memory. Splitting it means each agent forgets things mid-task.
\nInteractivity. If an agent hits ambiguous requirements — \"should rotating an API key invalidate the old one immediately or after a grace period?\" — it asks you. You switch to its tab and answer. The agent continues with correct information instead of guessing. On KomplyOS, this alone has prevented more wrong-assumption bugs than any review gate. The difference between an agent that can ask you a question and one that can't is the difference between a colleague and a batch job.
\nFull capability. Each session loads your full environment — project configuration, skills, MCP servers, memory. Subagents and teammates run in a restricted subset. An independent session is the same as your main session — same tools, same context, same capabilities.
\nRecursive orchestration. This is where the tiers compose. Each Tier 3 agent creates its own Tier 2 team internally — dispatching teammates for implementation, running shared task lists and messaging between them, enforcing review gates. Those teammates in turn use Tier 1 fire-and-forget for quick codebase exploration and linting. A complex ticket might have an independent agent managing an internal team of 3-4 teammates, each doing focused work, all coordinated within that single tmux tab. You don't need to manage this internal complexity — but you can see all of it. Switch to the tab and watch the agent coordinate its team in real time. Send a message from your main session via tmux send-keys without switching tabs. Or let the orchestrating Claude session do it for you — it spawned the tabs, it knows the tmux session and window names, and it can send messages to any agent via tmux send-keys on your behalf. The visibility and control are always there; you just don't have to use them.
On KomplyOS, I run 3 tickets in parallel this way — each in its own git worktree, its own tmux tab, its own Claude session. Tier 3 handles ticket-level parallelism. Tier 2 handles task-level coordination within each ticket. Tier 1 handles the small stuff. The nesting is natural, not forced — each layer uses the tier that fits its scope.
\nThe implementation is deliberately simple. No orchestration framework. No agent-to-agent protocol. A tmux window, a git worktree, a claude process, and a trigger message. The agent writes a .ticket-status file when it's done and moves its Trello card to \"Done\" — you poll, switch tabs, or just check your board.
Anthropic's C compiler experiment is the same principle at a different scale — 16 agents, each in its own Docker container, each working on a different aspect of a Rust-based C compiler. $20K in API cost, 100K lines of compiler code, compiles a bootable Linux 6.9 on x86, ARM, and RISC-V. The implementation is different (Docker containers vs tmux tabs, shared git repo vs worktrees), but the principle is identical: each agent had full independence over its domain.
\nThe rule: use full independence when the task benefits from its own context window, the ability to interact with you mid-flight, and a full lifecycle — plan, implement, review, commit.
\nOne question decides the tier: does this task benefit from an independent context window and the ability to interact?
\n| Your situation | Tier | What to do |
|---|---|---|
| Quick, independent tasks (search, lint, explore) | Fire-and-forget | Dispatch and move on |
| Single feature with coordinated sub-tasks | Coordinated team | Shared task list, review gates, messaging |
| 2+ substantial tickets in parallel | Full independence | Own session, own worktree, own context |
| Agent might need to ask you questions mid-flight | Full independence | You need to be able to switch to its tab |
| You want live visibility into what the agent is doing | Full independence | You need to be able to watch it work |
Start at the lowest tier that fits. Move up when you feel the pain — context bloat, agents guessing instead of asking, lost coordination. Don't over-orchestrate simple work and don't under-resource complex work.
\nEach tier costs something:
\nTier 1 → Tier 2: Coordination overhead. Shared task lists, messaging, and review gates all consume tokens and add time. For a task that didn't need coordination, you just made it slower and more expensive.
\nTier 2 → Tier 3: Automated orchestration. No parent session gets notified when agents complete — you're polling files or switching tabs. Shared task visibility disappears — independent processes don't know about each other unless you build it.
\nToken burn rate accelerates fast. Three independent sessions, each defaulting to the most capable model, each creating internal teams with their own review loops — you're running 3 orchestrators, each running 3-4 teammates, each running fire-and-forget agents. A single complex ticket can burn 200K-500K tokens. Three tickets in parallel can hit 1M+ tokens in an hour. I almost never downgrade the model — the quality difference is worth it — but the cost is real and you feel it.
\nManual QA gets harder too. With one feature, you test it. With three features landing on master in sequence, you need to test each one individually and test them together after integration. The interaction surface grows combinatorially — feature A might work alone, feature B might work alone, but A and B together expose a state conflict you didn't anticipate. I've started running a full Playwright suite after each rebase integration, not just at the end, to catch these early.
\nFor the engineers who want to try this:
\n1. Validate independence. Before spawning anything, check which files each ticket will likely touch. Read the relevant controllers, services, models, and components. If two tickets touch the same files, run them sequentially — merge conflicts from parallel agents are worse than sequential execution. The few minutes spent validating saves hours of conflict resolution and wasted compute.
\n2. Create worktrees. One git worktree per ticket, branched from master, as sibling directories to your main repo. If your project configuration (.claude/, .cursor/, etc.) is git-tracked, worktrees get it automatically. If not, copy it in — never symlink. Symlinks break when agents inside the worktree resolve the link back to the main repo's path and start writing files there.
3. Spawn sessions. One tmux window per ticket. Launch a claude process in each. Use window index (not name) for tmux send-keys — tmux misparses window names that contain substrings of the session name.
4. Send trigger messages directly. No intermediate files. The trigger message goes straight through tmux send-keys as the agent's first user message. Three mandatory instructions in every message, learned the hard way:
5. Monitor and interact. Switch tmux tabs to watch agents work. ctrl+b 1 to check ticket A. ctrl+b 3 to answer ticket C's question. It's the same as walking over to a colleague's desk. The agents write .ticket-status files (DONE/BLOCKED/FAILED) when they finish — a simple polling loop tells you the state.
6. Integrate. When all tickets report done, verify no two touched the same files. Rebase each ticket onto master one at a time, running the full test suite after each. Never merge — always rebase for linear history.
\n┌─ tmux session ────────────────────────────────────────────┐
│ Tab 0: [orchestrator] ← your main session │
│ Tab 1: [ticket-a] ← independent claude process │
│ Tab 2: [ticket-b] ← independent claude process │
│ Tab 3: [ticket-c] ← independent claude process │
│ │
│ ctrl+b 1 ← watch ticket-a / answer its questions │
│ ctrl+b w ← list all windows │
└────────────────────────────────────────────────────────────┘
Filesystem:
project/ ← main repo (orchestrator)
project-ticket-a/ ← worktree for ticket A
project-ticket-b/ ← worktree for ticket B
project-ticket-c/ ← worktree for ticket C
Tier 2 — Shared Context:
┌─ Orchestrator (1M tokens) ──────────────────────────────┐
│ [plan] [dispatch A] [A result] [dispatch B] [B result] │
│ [review A] [fix A] [re-review A] [review B] [fix B] │
│ [re-review B] ... context pressure builds ... │
└─────────────────────────────────────────────────────────┘
Tier 3 — Independent Contexts:
┌─ Orchestrator ──┐ ┌─ Agent A (1M) ─┐ ┌─ Agent B (1M) ─┐
│ [plan] │ │ [full ticket │ │ [full ticket │
│ [monitor] │ │ lifecycle] │ │ lifecycle] │
│ [integrate] │ │ [own teams] │ │ [own teams] │
└──────────────────┘ └────────────────┘ └────────────────┘
┌─ Tier 3: Independent Session (ticket-a) ─────────────────┐
│ │
│ ┌─ Tier 2: Coordinated Team ────────────────────────┐ │
│ │ │ │
│ │ Teammate 1: Backend service │ │
│ │ Teammate 2: Frontend UI │ │
│ │ Teammate 3: Tests │ │
│ │ ↕ shared task list + messaging │ │
│ │ │ │
│ │ ┌─ Tier 1: Fire-and-forget ──────────────────┐ │ │
│ │ │ explore codebase │ run linter │ grep │ │ │
│ │ └────────────────────────────────────────────┘ │ │
│ │ │ │
│ └────────────────────────────────────────────────────┘ │
│ │
│ Review loop: code review + audit → fix → re-run → ... │
│ Exit: both return zero findings in same pass │
└──────────────────────────────────────────────────────────┘
Start
│
▼
Does the agent need to know what
other agents are doing?
│
├─ No → Tier 1: Fire-and-forget
│
▼ Yes
Is it sub-tasks within ONE feature,
and can the parent hold all context?
│
├─ Yes → Tier 2: Coordinated team
│
▼ No
Do you need to interact mid-flight,
or run 2+ full-lifecycle tickets?
│
└─ Yes → Tier 3: Full independence
This mirrors how you'd manage engineers. You don't give a senior engineer a checklist and check on them every hour — that's micromanagement. But you also don't give an intern a vague ticket and disappear for a week. Match the independence to the complexity of the work and the capability of the agent.
\nThe ecosystem is racing to build orchestration frameworks — more control, more protocols, more abstraction layers. The principle that emerges from practice is the opposite: the hard part isn't coordinating agents, it's knowing when to stop coordinating them and give them independence.
\nAnthropic's C compiler project, the proliferation of tmux+worktree tools, Claude Code's Agent Teams — they're all converging on the same insight from different angles. The agents that produce the best work are the ones given a clear scope, full tools, and a communication channel with a human. Not the ones managed through the most sophisticated orchestration layer.
\nGive each agent a terminal, a branch, and a trigger message. Let them work. Check in when you want. Integrate when they're done.
\nThis is the third post in a series on building production software with AI agents. Previous posts: This Isn't Vibe Coding and 42% Were Fixes.
\nIf you're running parallel AI agents and want to compare setups, connect with me on LinkedIn.
", "url": "https://docs.komplyos.com/blog/independence-principle-ai-agents", "title": "Give Them a Terminal: Why AI Agents Work Better with Less Orchestration", "summary": "Everyone's building agent orchestration frameworks. The pattern that actually works is simpler: as tasks get more complex, agents need more independence — their own context, their own tools, their own communication channel with you.", "date_modified": "2026-04-06T00:00:00.000Z", "author": { "name": "Ali Sarkis", "url": "https://linkedin.com/in/alisarkis" }, "tags": [ "engineering", "ai", "claude-code", "process", "parallel-agents", "tmux", "worktrees", "thought-leadership" ] }, { "id": "https://docs.komplyos.com/blog/the-real-cost-of-ai-code", "content_html": "My last post told the success story: 166K lines of production code, built in 6 weeks, one engineer plus AI agents. This post is the other side — every mistake the AI made, every correction I had to repeat, every weird fix I found in production code, and the guardrails I had to build to stop it from happening again.
\nI'm writing this because the AI hype cycle is full of \"look what I built\" posts and almost entirely missing the \"here's how it actually broke\" posts. If you're going to build with AI, you need both.
\nThroughout this post, I quote things I said to the AI agent in moments of frustration. I want to be clear: I would never speak to a human engineer this way. The bluntness you'll see below — \"stop guessing,\" \"you haven't fixed anything,\" \"don't waste my time\" — is how I talk to a tool when it's burning my time on the same mistake for the third time in a row. AI agents don't have feelings, don't have bad days, and don't carry the interaction into their next session. A human colleague deserves patience, context, and respect. An AI agent that keeps adding setTimeout to Playwright tests after being told not to three times gets the short version.
Let's start with the git history. 733 total commits in the KomplyOS repository. Here's the breakdown:
\n| Category | Commits | % of Total |
|---|---|---|
| Fix commits | 308 | 42% |
| Refactoring phases | 11 | — |
| Audit-triggered waves | 4 | — |
| Exact duplicate commits | 8+ | — |
| Recorded corrections (feedback memories) | 17 | — |
42% of all commits were fixes. Not features. Not enhancements. Fixes for things the AI got wrong the first time.
\nThat number alone should make anyone pause before calling AI-assisted development \"easy.\" It is fast. It is not easy. And the speed is deceptive — because you spend a huge chunk of that speed fixing what was just built.
\nThese are the mistakes I had to correct multiple times. Some of them are now codified as hard rules in my CLAUDE.md configuration file because telling the AI once — or twice, or three times — wasn't enough.
This was the most frustrating recurring pattern. I'd report a bug, and the AI would immediately start changing code — without reading the error message, without tracing the execution path, without checking the actual data.
\nThe QR Code incident: There was a clear React error — \"expected string/function but got: object.\" The AI tried three different import fix attempts before I had to step in and point it at Vite's bundle output. The actual fix was a CJS/ESM interop issue that a 30-second diagnostic check would have revealed.
\nThe SES incident: Email delivery wasn't working. Instead of reading the letter_opener gem's source code or checking how Rails configures delivery methods, the AI tried random configuration changes. I had to redirect it to actually read the source before proposing a fix.
The seeder incident: Database seeding was broken. Instead of tracing the actual execution path, the AI changed code speculatively.
\nThis happened so many times that it became a formal rule:
\n\n\nRule: Diagnose before fixing. Read the actual error. Check the actual data. Trace the execution path. Verify your hypothesis with a test BEFORE writing code. Apply ONE targeted fix. Never chain speculative changes.
\n
AI agents love timeouts. When a Playwright test is flaky, the easiest fix is { timeout: 30000 } or page.waitForTimeout(2000). The AI added them constantly. I removed them. It added them again. I removed them again. It found new creative ways to add them — test.setTimeout(60000), new Promise(r => setTimeout(r, 1000)), { timeout: N } in test options.
This became the most explicitly documented rule in the entire CLAUDE.md — seven banned patterns with zero exceptions:
\nBANNED: { timeout: N } on ANY Playwright call
BANNED: page.waitForTimeout(N)
BANNED: test.setTimeout(N) / testInfo.setTimeout(N)
BANNED: { timeout: N } in test options
BANNED: new Promise(r => setTimeout(r, N))
BANNED: new RegExp(...) in waitForURL
REQUIRED: Wait for a specific element on the target page
The commit history tells the story. One commit removed all timeouts from the entire E2E suite: d9534338 — chore(e2e): remove all timeouts from E2E test suite. Then follow-up commits kept fixing tests that broke because the timeouts were masking real bugs. Then more commits optimized tests that were genuinely slow. It took 50+ commits to get the E2E suite right.
The real lesson: timeouts don't fix tests — they hide bugs. Every waitForTimeout(2000) means \"I don't know what I'm waiting for.\" The correct approach is always to wait for a specific element that proves the page/state you need is ready.
Multiple times, the AI would finish implementing a feature, dispatch a code review agent, and report it as ready for QA. I'd open the browser and find:
\nThe pattern was clear: the AI was self-certifying its own work without ever visually verifying it. Code review agents reviewed the code — not the rendered output.
\nThis is now a formal rule: before declaring anything ready for QA, the AI must run a Playwright script that logs in, navigates through the key flows, takes screenshots, and verifies pages render without crashing. Not an E2E test — a manual QA simulation. Verify the product, not just the code.
\nThe Superpowers framework includes a skill for executing implementation plans that offers two options: subagent-driven development (parallel agents in worktrees) or inline execution (do everything in the main context window). Every time a plan was ready, the AI would ask which one I wanted.
\nEvery time, I said \"1\" — subagent-driven.
\nThis wasn't just my problem. The Superpowers community has been asking for the same thing. Issue #846 describes it exactly: \"For users who consistently prefer sub-agent-driven development, this becomes repetitive — every time, I have to manually select the sub-agent option.\" The maintainer actually tried removing the choice in v5, but added it back in v5.0.4 after other users complained. In that same thread, someone asked: \"Is there any way for us to set a default?\"
\nThe bigger community request — with 96 upvotes on issue #429 — is for Claude Code's Team mode (TeamCreate + teammates with SendMessage coordination) to replace standalone subagents entirely. Multiple people have submitted PRs (#578, #470, #733, #598) and shared working forks, but none have been merged into mainline yet.
So I stopped waiting and wrote my own skill. The team-driven-development skill replaces the Superpowers default entirely — it uses Team mode instead of standalone subagents, adds two-stage review gates (spec compliance then code quality), and never asks which mode to use. It just executes. The CLAUDE.md has a routing table that intercepts every Superpowers skill that spawns agents and redirects it to the team-mode equivalent. The question doesn't exist anymore because the skill that asked it is no longer in the workflow.
The AI used git merge to integrate feature branches, creating merge commits. Always git rebase master first, then fast-forward merge. Never merge commits. This was a single correction — but cleaning up merge commits on master after the fact is painful. You're rewriting shared history, which means force-pushing, which means anyone else pulling from that branch gets conflicts. Catch it before it lands or live with the mess.
I found window.alert() and window.confirm() in the frontend code. Native browser dialogs — ugly, thread-blocking, and completely inconsistent with the app's design system.
The app already had toast.error() / toast.success() from Sonner for feedback, and AlertDialog from shadcn/ui for confirmations. The AI just didn't bother to check what patterns the codebase already used.
The git history shows this had to be cleaned up across multiple files:
\n181b94f7 — fix: replace alert/confirm with toast and AlertDialog on equipment edit687cc451 — fix: keyboard delete now uses ConfirmDialogde93b892 — fix: replace window.confirm with ConfirmDialog in TemplateEditorLayoutKomplyOS serves the tri-state area — New York, New Jersey, and Connecticut. The AI kept writing \"NYC, NJ, and CT\" (mixing a city with two states), \"NYC tri-state area\" (redundant — NYC is in the tri-state area), and generally positioning the company as NYC-specific.
\nThis required 7 separate fix commits across the marketing website:
\ne282612b — fix: correct tri-state area geographic references across all pages896acb6d — fix: fix last 2 NYC-centric KomplyOS referencesf6fe66fc — fix: fix NYC-centric language in building compliance blog post74c19a49 — fix: rename NYC building compliance blog post to tri-state8421e113 — fix: replace NYC with New York in state-level comparisonsfbea8ac2 — fix: don't mix full state names with state codesSeven commits to fix a geographic reference. The AI has a persistent memory system, but it only works if I remember to save the correction as a feedback memory after the first time. If I fix the issue in the moment but forget to persist the rule, the next session starts fresh and makes the same mistake. The fix isn't just correcting the AI — it's remembering to update the memory so the correction sticks.
\nThese aren't recurring patterns — they're one-off disasters that required real engineering judgment to catch.
\nTwo Ruby gems had a dependency relationship. One got updated and its error classes changed. The AI's fix? Reopen the gem's module, define the missing constants, and point them at the new classes. Every test passed. Green across the board.
\nThe right fix? Update the other gem. One-line Gemfile change. bundle update.
This is now Rule 16 in CLAUDE.md: \"No monkey-patching in tests. No exceptions. If a test needs monkey-patching to pass, the production code has a bug.\"
\nThe AI attempted to use React's hydrateRoot for SEO optimization on prerendered pages. It broke every page in the application. The commit chain tells the story:
a53c31c7 — feat: use hydrateRoot instead of createRoot (broke everything)1dc61d35 — revert: revert hydrateRoot back to createRoot (emergency revert)27e5b1c6 — fix: remove empty class attribute to avoid hydration mismatch090f2397 — fix: deduplicate head meta tags from react-helmet-async in prerender429327c5 — fix: lazy hydration — defer JS loading in prerendered pages79b6ee51 — fix: use DOM APIs to strip js-ready instead of fragile regexSeven commits to recover from a single architectural decision. The AI spent an entire afternoon debugging it wrong — checking static HTML output (which was perfect) instead of checking what happened when JavaScript actually executed. The HTML was correct; createRoot was wiping the DOM on load. I had to step in and tell it to actually render the page in a browser instead of inspecting markup.
The lesson that became a rule: when debugging rendering or SEO issues, step 1 is always to serve the built site, load it in headless Chromium, wait for JS, and check if the content is still visible. Never trust static HTML alone.
\nThe AI called stripe.retrievePaymentMethod — a method that doesn't exist in the Stripe SDK. This is hallucination. The AI generated a plausible-looking API call that would have crashed in production with a payment flow.
57484e22 — Fix: replace non-existent stripe.retrievePaymentMethod with setupIntent.payment_method
Related Stripe issues caught during manual QA and code review — none of these made it to production:
\nc3d9fb36 — Fix: Payment portal records confirmed Stripe payment instead of double-charging — the payment portal would have double-charged customers if it had shipped87b07872 — Fix: Stripe Connect status bugsf83da2ac — Fix: Stripe Connect status not updating after onboarding completionEvery one of these was caught before a single customer was affected. But that's exactly the point — when your AI writes payment code, the audit and QA steps aren't optional. They're the only thing standing between your users and a billing disaster.
\nThe AI tried to add a uniqueness constraint to the barcode field on equipment. I had to explain that manufacturer barcodes (UPC/EAN) are unique per product variation — not per physical item. Ten fire extinguishers of the same model all have the same barcode. Only system-generated QR codes (KOMP-XXXXXXXXXX) are unique per item.
0571aa6a — fix: barcodes are not unique and show actual validation errors
This is domain knowledge that no amount of code review would catch. You need to know your business.
\nThe deployment pipeline was configured to delete old assets during deploy. This meant that users who had the old version cached would request assets that no longer existed — resulting in blank pages.
\n914e73a3 — Fix: Stop deleting old assets during deploy to prevent blank pages
Related infrastructure commits:
\n1af83559 — Fix: Update deploy workflows for manifest.webmanifest (was manifest.json)cb58feed — Fix: Merge service workers — VitePWA injectManifest + push notifications19bbad96 — Fix: Ensure sw.js and workbox files are never cached in deployse12a1212 — Fix: Remove apex domain from www CloudFront aliasesFive commits of deploy fixes. The AI built the entire AWS infrastructure — Terraform for ECS Fargate, RDS, ElastiCache, S3, CloudFront, multi-AZ VPC — so it's not that it can't do infrastructure. The problem is that deploy issues only surface when you actually deploy to a real environment. You can't unit test whether CloudFront will cache your service worker or whether deleting old S3 assets will blank-page users who still have the previous version loaded. These are the kinds of bugs that require a deploy cycle to discover, and each cycle takes time.
\nRadix UI's Select component has a subtle behavior: onValueChange fires with an empty string when the user clears the selection. If you don't guard against it, your form state corrupts. The AI also kept adding ?? '' coercion and using useEffect + form.reset() instead of useForm({ values }).
This is now Lesson 9 in CLAUDE.md, preserved for eternity:
\n\n\nGuard
\nonValueChangeagainst empty strings:if (v === '') return;. Passfield.valuedirectly (no?? ''coercion). UseuseForm({ values })notuseEffect + form.reset().
AI agents are prolific copy-pasters. They'll build a filter bar for the Clients page, then build a nearly identical one for Buildings, then another for Jobs, then another for Equipment — each with its own state management, its own debounce logic, its own API call pattern. Same thing with dashboards: three role-based dashboards with 80% identical widget code, duplicated rather than composed.
\nThe frontend required a dedicated DRY pass — 833cfea9 — DRYING the frontend — to extract shared patterns. Filter logic got consolidated into a reusable factory (64577aaf — add DRY filter-helpers factory for list page filters). Dashboards got refactored to share components (0ae6ddf5 — Refactor UI to reuse dashboards). Duplicate CSV exports, duplicate review sections, duplicate form patterns — all found and consolidated after the fact.
The backend was worse. The AI produced \"god services\" — single service classes handling entire workflows that should have been decomposed. The SOLID refactoring required 8 dedicated phases:
\nApplicationService base class and ServiceResult for all servicespaginated_json and parse_boolean into concernsThat's a full SOLID refactoring arc on code that was only weeks old. The AI knew what SOLID meant — it could explain every principle. It just didn't apply them while writing the code. It defaulted to the fastest path: one class, one method, everything inline. The principles only got applied when I explicitly audited for them.
\nOn top of the SOLID violations, the AI-generated Ruby code had 1,129 RuboCop style violations across 407 files. This required a single massive cleanup commit:
\nf786de96 — Fix all RuboCop offenses: 1129 → 0 across 407 files
Followed by 11 more refactoring phases to bring code quality ratings from F/D to B or better:
\nThis is what happens when you let an AI write code without enforcing style and architecture from the start. After the cleanup, both DRY and SOLID became explicit CLAUDE.md rules. The DRY section requires searching for existing shared code before creating new components, hooks, or utilities — and mandates composition over copy-paste. The SOLID section spells out each principle with concrete examples: controllers are thin (~10 lines per action), services have single responsibility, strategy patterns replace conditional chains, and dependencies are injectable. RuboCop with zero offenses is a pre-commit gate. The AI doesn't get to merge code that violates any of these — they're not guidelines, they're hard rules enforced on every commit.
\nHere's the most important pattern in the entire codebase: every single feature, without exception, has required post-implementation auditing to be considered actually done.
\nThe git history has explicit \"audit wave\" commits:
\n| Audit | Findings | Commit |
|---|---|---|
| Wave 4 | 107 findings | 3ec1bda6 — Wave 4 code review: Fix all 107 findings |
| Wave 4 (follow-up) | 38 findings | 1afde870 — Fix: Address all 38 Wave 4 code review findings |
| Wave 10 | 30 findings | c3f3a509 — Fix all 30 Wave 10 audit findings |
| Wave 12 | All remaining | 8683c6fa — 0 F-rated files, 0 zero-coverage files, score 84.79 |
| Full system audit | 16 bugs + 18 regression tests | 8b14a1aa — Full system audit — 16 bug fixes, 18 regression tests |
| Rails audit | Critical + High | eb302af9 — SQL injection, N+1 queries, controller refactoring |
| Backend audit | 2 Critical + 5 High | 0c4c7e0d — resolve 2 Critical + 5 High audit findings |
The pattern is always the same:
\n100% of the time, the first implementation is not done to spec. Not 80%. Not 90%. 100%. I have never, in 6 weeks of building with AI agents, had a feature come back from implementation without requiring an audit cycle.
\nThe issues aren't trivial:
\nBut the most common audit finding — the one I see on literally every feature — is backend work that's complete but never wired into the UI. The AI builds a service, writes a controller action, adds the route, writes tests for all of it — and then the frontend page that's supposed to call it either doesn't exist or calls a different endpoint entirely. When asked to verify, the AI would check that a route exists in the React router config and call it done — without checking whether a user can actually navigate there from the sidebar, navbar, or any link in the UI. A page that exists in the router but has no navigation path to it is functionally invisible. The backend code is fully functional and fully orphaned.
\nThe inverse is equally common: frontend components that accept props nobody passes. A BarcodeField component with an equipmentContext prop that no parent ever provides. A callback handler wired to onClick that triggers a service method that was never finished. Buttons that render perfectly and do absolutely nothing when clicked.
This is the AI's version of \"works on my machine.\" Each layer — backend, frontend, tests — is internally consistent. The service has tests. The component has tests. They both pass. But nobody checked whether the service and the component are actually connected. The AI builds vertically within each layer and never verifies the horizontal integration across layers.
\nOrphaned methods are the other telltale sign. During audits, I regularly find service methods that are fully implemented, fully tested, and called by nothing. They were part of the plan, the AI wrote them, but it moved on to the next task before wiring them into a controller or a frontend hook. The code is dead from day one — not deprecated, not leftover from a refactor. Just never connected.
\nThis is why I have to prompt for an audit after every feature. The AI doesn't audit its own work, and when it self-reviews, it misses the same things a junior developer would miss — because it wrote both the code and the review with the same mental model. The layers look complete from the inside. You only see the disconnection when you trace a user action end-to-end: click button → API call → controller → service → database → response → UI update. If any link in that chain is missing, the feature doesn't work — no matter how many tests pass.
\nA perfect example of \"done but not done\": the AI updated pricing tiers across the platform. Backend ✓. Frontend pricing page ✓. Done, right?
\nNo. The pricing was also referenced in:
\nindex.html meta tagsIt took three separate fix commits to propagate a price change:
\ndc8bafb5 — fix: update stale pricing in CompetitiveMatrix, FaqPage, SignupPage, PricingFaq9bffb17a — fix: code review fixes — stale pricing in index.html, blog tier labels8f72f014 — fix: update stale pricing across all documentation filesThe AI updated the obvious places and called it done. The audit found the rest.
\nAfter enough corrections, I stopped trying to tell the AI not to do things and started building systems that make it structurally harder to do them. These are implemented as \"skills\" — structured workflow instructions that the AI follows before writing any code.
\nI use the open-source Superpowers framework as the foundation. It provides structured agentic workflows:
\nI wrote two custom skills that replaced the default agent dispatching with Team mode — a structured approach where agents coordinate through shared task lists and messaging instead of working in isolation.
\nteam-driven-development — Replaces standalone subagents with a team-based workflow:
TeamCreate)The spec reviewer has a critical instruction that addresses the audit problem directly:
\n\n\n\"CRITICAL: Do Not Trust the Report. The implementer finished suspiciously quickly. Their report may be incomplete, inaccurate, or optimistic. You MUST verify everything independently. Read the actual code they wrote. Compare actual implementation to requirements line by line.\"
\n
This is the audit-by-default system. Every task gets audited twice before it's accepted — once for spec compliance, once for code quality.
\nteam-parallel-dispatch — For when you have 3+ independent problems (different test files failing with different root causes, multiple subsystems broken independently). Dispatches all teammates in parallel with worktree isolation, then integrates the results.
For Rails-specific quality, I use Thoughtbot's audit skill which runs comprehensive audits against Thoughtbot's best practices across seven categories: testing, security, models, controllers, code design, views, and external services.
\nThis is the tool that discovered the 107-finding waves. It runs RubyCritic (code quality scoring), Reek (code smell detection), and Flog (complexity measurement) under the hood. Any file rated F gets fixed before new features ship on top of it.
\nEvery recurring mistake eventually becomes a rule in my CLAUDE.md file — the engineering handbook for AI agents. Some highlights:
16 Lessons Learned — concrete mistakes documented with the specific anti-pattern and correct approach. These cover everything from \"never guess field names\" to \"Radix Select fires onValueChange with empty strings\" to \"test mocks must match API signatures after type changes.\"
\n7 Banned Playwright Patterns — the timeout addiction required the most explicit rule in the entire file, listing every creative way the AI tried to sneak timeouts back in.
\nMonkey-patching ban — with specific examples of what counts as monkey-patching vs. legitimate test doubles.
\nMandatory regression tests — every bug fix must include a test that reproduces the original bug. No exceptions. This prevents the \"fix one thing, break another\" cycle.
\nMemory updates — after completing any task that changes routes, schema, models, services, serializers, types, components, hooks, or factories, the AI must update the corresponding memory file. This is institutional knowledge management.
\nPre-commit build check — tsc -b (not --noEmit) before committing frontend code, because the deploy pipeline uses the stricter flag and the AI kept shipping code that passed locally but failed in CI.
Beyond the CLAUDE.md rules, I maintain persistent \"feedback memories\" — corrections that survive between sessions:
\nEach of these represents a real incident where the AI did the wrong thing and I had to correct it — sometimes multiple times.
\nThe mental model most people have is wrong. AI isn't a junior developer. A junior developer can't architect a multi-tenant SaaS platform with offline-first sync, design a 74-tool AI assistant with confirmation workflows, or implement a real-time GPS tracking system with geofencing. A junior developer doesn't know how to set up Terraform for a multi-AZ AWS deployment, configure Stripe Connect with ACH and dunning, or build a bidirectional QuickBooks sync.
\nThe AI can do all of that. It can research problems it's never seen, propose architectures, evaluate tradeoffs, and implement complex systems across the full stack. That's staff engineer territory — the ability to take an ambiguous problem, break it down, and ship a working solution.
\nBut the mistakes it makes are junior-level:
\nwindow.alert)This is the paradox of working with AI: you're managing something that can design a system a senior engineer would respect, but will put a window.confirm() in the middle of it. It can implement a state machine with 6 transitions and edge case handling, then forget to wire the button that triggers it. It can write a service with 95% test coverage where every test passes and the service is called by nothing.
The gap isn't capability — it's discipline. And that's exactly where human engineering leadership comes in. The AI provides the horsepower. You provide the judgment, the quality bar, and the end-to-end verification that turns fast-but-sloppy into production-ready.
\nThe 42% fix rate isn't a failure of the model. It's a failure of process — specifically, the process I was using at the beginning. As I added more guardrails (CLAUDE.md rules, superpowers skills, team-driven development, mandatory audits), the quality improved.
\nThe fix rate for early features was probably 60%+. The fix rate for recent features, with all guardrails in place, is closer to 20%. Still not zero — I still audit everything — but dramatically better.
\nI've tried. Every time I skip the post-implementation audit, I find bugs in production. 100% of the time. The AI will tell you it's done, the tests will pass, the linter will be clean — and there will still be missing authorization checks, stale data in a forgotten component, or a serializer that doesn't expose a field the frontend needs.
\nThe audit is not optional. It is the most important step in the entire workflow. If you're building with AI and not auditing every feature, you are shipping bugs.
\nDespite everything in this post, I'd still choose AI-assisted development over traditional development for a project like this. The 42% fix rate sounds terrible until you realize:
\nThe key insight is that AI doesn't eliminate engineering judgment — it makes engineering judgment more valuable. Every correction I made, every audit I ran, every rule I wrote — those are the things that turned fast-but-broken code into production-ready software.
\nThe AI wrote 42% of its commits as fixes. But I caught the issues. That's the job.
\nThis is a companion piece to This Isn't Vibe Coding: How I Built a $2–5M Platform in 6 Weeks with AI Agents. That post covers the process and toolchain. This post covers the failures.
\nIf you're building with AI and want to compare notes, connect with me on LinkedIn.
", "url": "https://docs.komplyos.com/blog/the-real-cost-of-ai-code", "title": "42% Were Fixes: The Real Cost of Building Production Software with AI Agents", "summary": "733 commits. 308 fixes. 11 refactoring phases. 17 recorded corrections. This is what actually happens when you build a production platform with AI agents — and the skills, guardrails, and process I built to stop the bleeding.", "date_modified": "2026-04-01T00:00:00.000Z", "author": { "name": "Ali Sarkis", "url": "https://linkedin.com/in/alisarkis" }, "tags": [ "engineering", "ai", "claude-code", "lessons-learned", "process", "superpowers", "quality" ] }, { "id": "https://docs.komplyos.com/blog/how-we-build-komplyos-with-ai", "content_html": "Over 80% of companies report no productivity gains from AI — despite billions in investment. In my last role as VP of Engineering, I introduced AI into my team's workflows and got a 20%+ increase in velocity, quarter over quarter, year over year. I kept asking myself: why did it work for us, and what would it look like if you designed an engineering org around AI from day one?
\nSo I started building KomplyOS to find out. Six weeks later, I have a production-grade compliance platform that a traditional team of 10 would need 14–18 months and $2–5M to build. This post is the full, uncut version of what I've learned — the process, the tools, the failures, and the specific practices that made the difference.
\nThe first version was garbage. I didn't do proper market research — just ran with a 30-minute call with my first client about what they needed for building compliance inspections in Manhattan. I started with Python on the backend because \"AI is good at Python.\" That was a mistake.
\nI scrapped it and rebuilt in Ruby on Rails — because that's what I've spent the last 10 years doing. The reason was simple: you can't effectively review AI-generated code in a language you don't deeply know. AI agents are fast, but the quality of their output is only as good as your ability to catch what's wrong. If you're reviewing code in a language where you can't smell a bad pattern from 50 lines away, you're going to ship bugs. That was lesson one.
\nHere's the actual codebase inventory, measured directly from the repository:
\n| Component | Files | Lines of Code |
|---|---|---|
| Backend Controllers | 144 | 6,372 |
| Models | 75 | 2,132 |
| Services (52 directories) | 434 | 43,613 |
| Alba Serializers | 92 | 1,928 |
| Pundit Policies | 47 | 1,388 |
| Background Jobs (Sidekiq) | 55 | 1,053 |
| Frontend Feature Modules (29) | 396 | 71,638 |
| Shared Components | 73 | 10,330 |
| Custom Hooks | 24 | 5,045 |
| Lib / Utilities | 27 | 7,758 |
| Infrastructure (Terraform + CI/CD) | 34 | 5,351 |
| Component | Files | Lines of Code |
|---|---|---|
| RSpec Backend Tests | 787 | 140,235 |
| Vitest Frontend Tests | 389 | 113,037 |
| Playwright E2E Tests | 95 | 17,074 |
acts_as_tenantI ran a detailed cost estimate against four traditional team structures:
\n| Approach | Timeline | Build Cost |
|---|---|---|
| US Senior Team (10 people) | 14 months | $3.7M |
| US Agency (Top-Tier) | 14 months | $4.9M |
| US Leads + LATAM Devs | 16 months | $2.8M |
| Offshore + US Oversight | 18 months | $2.1M |
The raw development effort is approximately 426 person-weeks (98 person-months). With standard overhead (architecture, project management, design, code review, meetings, PTO), that becomes roughly 149 loaded person-months.
\nI built it in 6 weeks. One engineer. AI agents.
\nOpus 4.6 is great, but what actually moved the needle was process. I treat AI agents like a real engineering team. Here's what that means in practice.
\nAgents can't just start coding. Every task follows a structured workflow:
\nrubocop + tsc --noEmit + npm run build + vitest + playwright test + parallel:spec. Then manually test as Admin, Client, and TechnicianThis is the same workflow you'd run on any well-managed engineering team. The only difference is the engineers are AI agents.
\nCode doesn't go from agent to production. It goes through a review pipeline:
\nThis mirrors how any healthy engineering org works: peer review before tech lead review.
\nAfter every significant chunk of work, agents update a shared set of memory files so the next agent picking up work has full context. These memory files cover:
\nThis is the AI equivalent of onboarding docs and team wikis. When a new agent starts a task, it reads the memory files and has full context — no guessing at field names, no hallucinating import paths, no making assumptions about how the codebase is structured.
\nI maintain a living \"Lessons Learned\" document of concrete mistakes from past sessions. Every time an agent makes a significant error, it gets documented with the specific anti-pattern and the correct approach. Some examples:
\nusePermissions for visibilitymockResolvedValue calls and update themThis is institutional knowledge, the same way you'd build it on a real team. The difference is that with AI agents, you can enforce it programmatically through the CLAUDE.md configuration.
\nI use Claude Code's team mode with extensively customized agent rules defined in a CLAUDE.md file. This file is essentially the engineering handbook for AI agents — it defines:
The CLAUDE.md is over 250 lines of specific, enforceable rules. It's not vague guidance — it's the equivalent of a team's coding standards doc, style guide, and architecture decision records rolled into one.
\nI adopted the open-source Superpowers framework for structured agentic workflows. This provides:
\nFor Rails-specific code quality, I use Thoughtbot's audit skill which runs comprehensive audits against Thoughtbot's Ruby Science and Testing Rails best practices. This integrates three underlying analysis tools:
\nThese run on every significant change. Any file rated F gets fixed before new features ship on top of it.
\nAll backend code must pass bundle exec rubocop with zero offenses. Key rules: 120-char max lines, 30-line max methods, 200-line max classes, single-quoted strings, guard clauses, find_each for batching, pluck over map. This catches the mechanical issues so code review can focus on logic and architecture.
AI-generated code needs the same security scrutiny as human-written code — arguably more, because agents tend to take the path of least resistance and may introduce subtle vulnerabilities. My CI pipeline includes:
\nbrakeman.ignore file, no suppressions.The key rule: never suppress scanner findings. No brakeman.ignore, no # nosec comments. If a scanner flags something, the code gets fixed. This is especially important with AI-generated code because agents will sometimes generate patterns that technically work but have security implications they don't flag.
The overall target is 85%+ test coverage, but it's broken down by component type:
\n| Component Type | Coverage Target |
|---|---|
| Models | 90% |
| Controllers | 80% |
| Services | 95% |
| Mailers | 100% |
| Jobs | 90% |
The Playwright E2E test suite has a strict \"zero tolerance on timeouts\" policy. These patterns are banned:
\n{ timeout: N } on any Playwright callpage.waitForTimeout(N) — this is a sleep, there's always a better alternativetest.setTimeout(N) — if a test is slow, fix the test or the production codenew Promise(r => setTimeout(r, N)) — another sleep patternInstead, every navigation and state change waits for a specific element on the target page. This makes tests faster, more reliable, and prevents the kind of flakiness that wastes hours of debugging time.
\nWhy is this important for AI-generated tests? Because agents love timeouts. They're the easiest \"fix\" for a test that's not waiting for the right thing. Every timeout an agent adds is technical debt that hides a real bug. The CLAUDE.md makes this explicit: if you see an existing timeout in test code, remove it.
\nEvery bug fix must include a test that reproduces the original bug and verifies the fix. No exceptions. This applies to backend (RSpec), frontend (Vitest), and user-facing bugs (Playwright E2E). This is especially critical with AI-generated code because without this rule, agents will sometimes \"fix\" a bug in a way that breaks something else — and without a regression test, you won't know until it hits production.
\n95%+ test coverage. Full CI pipeline. Full security scanning suite. 87 Playwright E2E test journeys across all three user roles. And I still manually log in as every user role — Admin, Client, and Technician — and click through every flow myself.
\nWhy? Because even with a full end-to-end test suite in Playwright, AI-generated tests can pass while the product is broken. Tests validate what the agent thinks the code should do, not what the user actually experiences. The agent wrote the code AND the tests based on its own understanding. If its understanding is wrong, both the code and the tests will agree with each other — and you'll ship a bug.
\nManual QA is the one thing that keeps you honest when your entire codebase is AI-assisted. There is no substitute for a human being looking at the screen and asking \"does this actually work the way a user would expect?\"
\nHere's a concrete example of why human judgment is irreplaceable.
\nI had two Ruby gems with a dependency relationship. One of them got updated and its error classes changed — the class names were different in the new version. This caused a cascade of test failures.
\nThe AI agent's fix? Monkey patch the old error classes back into existence. It reopened the gem's module, defined the missing constants, and pointed them at the new classes. Every test passed. Green across the board.
\nThe right fix? Just update the other gem. The dependency had a newer version that was already compatible with the updated error classes. A one-line Gemfile change and a bundle update.
The agent's fix was technically correct — it made the tests pass. But it was the wrong fix. It added complexity, hid the real issue, and would have broken again on the next gem update. This is exactly the kind of thing that slips through if you're not reviewing AI output with the same rigor you'd apply to a junior engineer's pull request.
\nThis incident is now in the Lessons Learned doc: \"No monkey-patching in tests. No exceptions. If a test needs monkey-patching to pass, the production code has a bug.\"
\nKomplyOS itself includes a production AI assistant — not just as a feature for users, but as a case study in building AI-powered tools with the right guardrails.
\nThe assistant can manage the entire business through natural language:
\n| Category | Tools | Examples |
|---|---|---|
| Client Management | 5 | Create, list, update clients; view client buildings |
| Building Management | 5 | Create, update buildings; view building equipment |
| Equipment Management | 5 | Track equipment, decommission assets |
| User Management | 4 | Create, update users across roles |
| Job Management | 13 | Full job lifecycle from creation to completion, proposals, follow-ups |
| Invoice & Billing | 9 | Generate invoices from jobs, record payments, batch billing |
| Subscriptions | 4 | Create, renew, track subscriptions |
| Inventory | 4 | Monitor stock levels, low-stock alerts |
| Messaging | 3 | Send messages, view threads |
| Reporting & Analytics | 7 | Revenue, jobs, technician performance, equipment status, audit logs |
| Scheduling | 3 | Technician schedules, availability, workload balance |
| Search & Analytics | 7 | Cross-entity search, issue detection, unbilled job tracking |
| Batch Operations | 5 | Bulk assign/reassign jobs, bulk send invoices, bulk renew subscriptions |
Nothing destructive happens without human approval. The system has four confirmation levels:
\nThis is the same principle I apply to the development process: AI agents are powerful, but they need guardrails. The AI assistant can schedule 50 jobs in one command, but only after the admin reviews and approves each one.
\nThe assistant's system prompt is dynamically constructed from seven knowledge files:
\nThis gives the assistant deep context about the domain without relying on the model's training data. When an admin asks \"schedule a fire pump test for Building A next Tuesday,\" the assistant knows what a fire pump test requires, which inspection template to use, and which technician certifications are needed.
\nThe 20% velocity boost I got with my previous team was just the starting point. The real unlock comes when you stop treating AI as a tool and start treating it as a team that needs the same things any engineering team needs:
\nMost organizations bolt AI onto broken processes and wonder why nothing changed. The process is the product.
\nKomplyOS started as an exercise to pressure-test these ideas. It's now a real product — I'm onboarding my first customer and going live soon, serving building compliance businesses in the Tri-State area. But the bigger outcome is a playbook for what AI-native engineering leadership actually requires — one I've been living, not theorizing about.
\nI'm building KomplyOS and I'm looking for my next engineering leadership role. These aren't competing goals. The best engineering leaders have always stayed close to the work. This is me staying close to the work.
\nIf you're building a team that needs to actually ship with AI — not just adopt it — let's connect on LinkedIn.
\n