DEV Community: Teamvoy

Most of You Should Not Be Custom-Building an Ecommerce Store

Teamvoy — Mon, 31 Aug 2026 12:08:25 +0000

Ecommerce projects rarely get hard because of the storefront. They get hard when the storefront has to meet the needs of the rest of the business.

Inventory already lives somewhere. Orders land somewhere else. Finance has its own systems. Payments drag security and compliance into scope. And the platform picked in month one defines what's easy, expensive, or impossible two years later.

Which is why the first question shouldn't be Shopify vs Magento vs WooCommerce vs custom. Starting there means arguing about features before anyone understands the constraints. The better opening question: what are we actually building, and which parts genuinely need to be custom?

For most people reading this, the honest answer is buy a platform and move on.

The phase ordering that costs the most

Seven phases: discovery, architecture and platform selection, design, build and integration, data migration, compliance and security review, launch and first optimization. Four to seven months for a mid-market build.

The sequence matters more than the labels, and one inversion is expensive above all others: choosing a platform before you've scoped compliance. Do it in that order and a compliance finding can force a re-architecture eight weeks into the build.

Two phases account for most overruns:

Build slips because discovery missed a system. The integration nobody scoped in phase 1 surfaces two months late, when the schedule has no slack left. Discovery in commerce isn't about pages — it's about finding every system holding a number the store needs, and finding who can grant access to it. That list is always longer than the brief.
Compliance review slips because it was treated as a formality. Remediation lands on a team that has already released its engineers.

Both are schedule problems created long before they appear.

Staffing note worth agreeing in writing before kickoff: phases 1, 2, and 6 need someone on the client side — a person who can get you into the ERP, whoever signs the contract, and named owners for the payment page and accessibility. Phases 3, 4, and 5 can sit almost entirely with the build team. The three phases you have to staff are the three that stall when nobody's free.

Three dates that already passed

These are no longer planning questions. They're evidence questions.

PCI DSS v4.0.1 req 6.4.3 and 11.6.1, in force since 2025-03-31. Inventory every script on the payment page, authorize each one, justify why it's there, and detect unauthorized changes to page headers and content. The catch: the scripts in question are usually marketing tags nobody in engineering added. PCI now has an owner problem — the tag manager on checkout needs a named owner and an approval step.
European Accessibility Act, Art. 2(2)(f), applying after 2025-06-28 to ecommerce services sold to EU consumers. Measured against EN 301 549, which points at WCAG. "We'll do accessibility after launch" is now a statement about legal exposure, not backlog priority.
GDPR / CCPA / CPRA, unchanged but load-bearing. Consent, access, and deletion paths wired into the customer data model rather than bolted on. If a deletion request can't be executed against the customer record without an engineer, it doesn't scale past the first hundred.

Accessibility written as an acceptance criterion in phase 3 costs days. Discovered in phase 6, it costs weeks. Same work, different bill.

Checkout: the causes are business decisions, not design problems

The average documented cart abandonment rate is 70.22% (Baymard, across 50 studies, updated 2025-09-22). Among shoppers who intended to buy, the top causes:

Extra costs shown too late — shipping, tax, fees — at 40%.
Slow delivery, 20%.
Distrust of the payment form, 19%.
Forced account creation, 18%.

Three of those four are decisions no redesign can make on your behalf. In order of what actually abandons carts: show the full total on the cart page, offer guest checkout, give a real delivery date rather than a shipping-method name, make the payment step look like a payment step, and cut every optional field.

Run A/B tests only after those five are in place. Below a few thousand checkouts a month you don't have the traffic to detect a one-point conversion change without weeks per variant, and teams routinely call the result on day four because the chart looks decided. Testing earns its place above the checkout — category layouts, product page structure, price and delivery presentation — where there's more traffic per decision.

Where AI actually earns its place

The test: does the model's output change a decision somebody was already making on worse information?

Demand forecasting and replenishment. Output is a purchase order quantity. Error is countable against what sold.
Fraud and chargeback scoring. Output is a score with a threshold. Both false positives and false negatives show up in the finance report — which means the review interface is in scope, not a follow-up.
Search and merchandising, but above roughly ten thousand SKUs, where manual merchandising already stopped covering the tail.

Where it doesn't: personalization on a 200-SKU catalog has too little behaviour to learn from and the engineering cost lands anyway. Dynamic pricing on consumer goods invites a customer to screenshot two prices and post them. Generated product copy at scale reads like generated product copy at scale, on exactly the pages you wanted indexed.

Separately — AI in the build is a different question from AI in the store. Coding assistants compress phases 3 and 4. They don't touch 1, 5, or 6, which is where the schedule risk lives, because those are constrained by other people's systems and by evidence someone has to sign.

Composable, honestly

Headless decouples the front end and is a configuration option on several hosted platforms. Composable replaces the engine with separate services. Headless is a weekend of architecture; composable is a program of work. The terms get used interchangeably and shouldn't be.

On a composable build, expect the first feature to take four to six weeks longer than on a coupled platform, and expect payback to start around the third. If your roadmap has three changes in it, the arithmetic doesn't work.

You also inherit a service layer somebody maintains, and six services that fail in more ways than one platform does. "Wanting to be modern" is not a reason. Multi-channel selling from one inventory, or business rules no vendor has productized, are.

If the reason is real, migrate incrementally: routing layer in front of the existing store, move one capability behind it, run both, move the next. Search and product content first — read-heavy, low-risk. Checkout near the end, because it handles the money and the compliance scope. Teams that move checkout first take the program's largest risk before learning anything.

The three-year number

Build cost is the number in the quote and the smaller half of the decision. A $70,000 build with $12,000 annual maintenance and $1,500 a month in platform fees is a $160,000 commitment before a single new feature ships.

Price every platform over three years, because the fee structures behave differently: revenue-percentage platforms get more expensive as you succeed, self-hosted charges you in engineering hours whether you grow or not, licence-plus-build front-loads and holds steady. Ask each vendor what the bill looks like at three times current volume, and get it in writing. That belongs in phase 2, not the post-launch review.

And then the question underneath all of it. Under roughly $5M in annual online revenue, with a standard catalog and standard checkout, buying wins on price, time, and risk. Custom development is the answer to a named business rule you can attach a cost to living without — never to a general preference for control.

Full breakdown — all seven phases, the platform comparison table, and the build-vs-buy signals: see the full guide

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.

Nobody Budgets for the Redirect Map

Teamvoy — Wed, 26 Aug 2026 20:07:58 +0000

A $5,000 template refresh and a $150,000 rebuild both get called "a website redesign." Then someone requests three quotes without scoping the project and compares numbers that don't describe the same work.

That's how a redesign that started on a small-business budget discovers halfway through that it needed enterprise scope. Not because anyone lied. Because "redesign" is a word that covers two completely different engineering jobs, and the person buying it usually can't tell which one they're in until the content migration starts.

Broad shape for 2026: roughly $3,000 at the small-business end, past $250,000 for complex enterprise builds, with most mid-market work landing between $40,000 and $100,000. Those ranges are almost useless on their own. What matters is which drivers your project actually has.

What actually moves the number

Unique page templates. Not pages — templates. A homepage, product page, service page, blog post, and landing page are five separate design-and-build efforts, each wireframed, built, made responsive, tested, and wired into the CMS. Small sites might need 3 to 5. Large ones run past 15. Figure $1,500 to $5,000 per additional template depending on complexity.
Custom features and third-party integrations. Every integration means research, API configuration, testing, and ongoing support. The ones that hurt are the ones needing custom middleware or two-way data sync, because those keep costing after launch.
Content migration. The most underestimated line by a wide margin. If content is inconsistently structured or spread across platforms, migration alone eats 10 to 20% of the project budget. Automated tools help with extraction and reformatting; manual review is still where the quality comes from. New copy runs $100 to $300 per page.
Accessibility. WCAG 2.1 AA means semantic HTML, keyboard navigation, contrast checks, ARIA attributes, and testing every template. It's real hours. Skipping it saves money up front and buys legal risk later.
Timeline. Rushed deadlines and vague scope both inflate cost, for opposite reasons — one buys overtime, the other buys rework.

The one that quietly costs the most

SEO migration. It is the cheapest thing to skip and the most expensive thing to have skipped.

You need a URL map with 301s from every old path, meta and schema carried across, header structure and alt text preserved, and performance that doesn't regress on mobile. Get it wrong and you launch a beautiful site that lost its organic traffic, which nobody notices for six weeks because everyone is looking at the design.

Build the redirect map during development, not during launch week. It's the artifact that makes the difference between a redesign and an outage with better typography.

What does AI actually take off the bill?

Real, but narrower than the pitch suggests. It compresses the repetitive middle of the project:

Scanning an existing site, extracting content, reformatting it for new templates — genuinely useful on large blogs and news archives.
Resizing, compressing, and tagging images. Auto-generating alt text saves dozens of hours on an image-heavy migration.
Automated passes for broken links, accessibility issues, and performance bottlenecks.

Where it stops: brand narrative, custom integrations against proprietary systems, and interpreting compliance requirements. Automate deliberately — not everywhere at once. On a small project the savings are meaningful. On a complex custom build, automation optimizes the process rather than replacing the expensive part of it.

The number nobody puts in the quote

Ongoing maintenance runs 15 to 20% of build cost, annually. Security patches, CMS updates, performance monitoring, bug fixes.

On a $60,000 build that's $9,000 to $12,000 a year, every year, and it is almost never in the proposal you're comparing. Neither is custom photography ($3,000 to $15,000), video ($5,000 to $25,000 per video), hosting, or premium plugin licensing.

Two things that make a quote comparable: insist on itemized proposals that include content migration, maintenance, and media production as explicit lines, and reserve 10 to 15% for contingency. Scope creep is not a sign anyone failed. It is the default state of a project where the content turns out messier than the audit suggested.

The design is the part everyone argues about and the part that costs the least to change. The redirect map, the integration surface, and the annual maintenance line are the ones that decide whether the number you were quoted resembles the number you pay.

Full breakdown — pricing by business size, all seven cost drivers, and a budgeting checklist: teamvoy.com/blog/website-redesign-cost

Written by Zhanna Yuskevych, CPO at Teamvoy. More engineering writing at teamvoy.com/blog.

Your Main Branch Has Code Nobody Read. Whose Name Is On It?

Teamvoy — Tue, 25 Aug 2026 12:58:20 +0000

Who is accountable for AI-generated code? The engineer who merges it. That answer hasn't changed since 2023. What changed is the volume behind it.

Google's own number: just over a quarter of new code AI-generated in October 2024, roughly half by late 2025, 75% by April 2026 per Sundar Pichai. Almost nobody's review gates, provenance records, or audit evidence moved in that same window. So the accountability gap is the distance between how much of your codebase a model wrote and how much your governance assumes a human wrote.

It stays invisible until the worst possible moment — an incident postmortem, a security review, a customer questionnaire, an examiner asking about your SDLC.

Three failure modes

The review bottleneck. Agents produce diffs faster than humans read them. Review becomes either the constraint on delivery or a rubber stamp. Watch for the tell: approval latency stays flat while actual scrutiny drops.
Provenance blindness. Someone asks "was this AI-generated, and what checked it?" and nothing in the commit history can answer. This is cheap to record now and impossible to reconstruct later.
Shadow tooling. Policy says no, engineers use personal accounts and local models anyway. The company keeps the risk and loses the visibility. We ran this exact movie with unsanctioned SaaS a decade ago.

On the review bottleneck, there's a recurring r/ExperiencedDevs thread shape worth reading: a senior engineer describes review queues doubling after agent adoption, and the replies split between "review harder" and "trust the tests." Both miss the same move. The review standard has to change shape, not intensity. A heroic reviewer and a green CI run are equally poor substitutes for deciding which changes deserve which gate.

Why banning makes it worse

Three postures, and only one of them produces a defensible answer to "who signs this?"

Ban — you get a clean-sounding policy. You pay in shadow usage with zero visibility, a senior hiring penalty, and the loss of the audit trail you were trying to protect.
Laissez-faire — you get speed and goodwill. You pay in no provenance, rubber-stamped review, and unanswerable audit questions.
Governed adoption — you get speed plus evidence that survives an audit. You pay in real setup work, roughly four to eight weeks of process and tooling change.

The ban threads on r/cscareerquestions read identically every time: the policy says no, the replies describe exactly how people route around it, and nobody believes the codebase is cleaner for it. When your engineers can narrate the workaround in public, the ban isn't a control. It's a blindfold.

The five moves

Name the owner, per merge. One sentence of policy: the engineer who merges a change owns it, regardless of what produced the draft. The model proposes, the engineer signs. No autonomous merges.
Tag provenance at commit time. Commit trailers, PR labels, or tool-native attribution. Record which changes are substantially AI-generated and by which tool.
Harden the gate where it counts. Risk-tier your repos. AI-drafted changes to payment logic, authz, and data migrations get a second reviewer and a required test diff. AI-drafted changes to internal tooling get the standard gate. Uniform strictness is how review becomes theater.
Give non-deterministic code a CI gate. An eval harness is a CI suite for code whose output isn't reproducible. If your agents write code that calls models, evals gate the merge the way unit tests gate deterministic changes.
Write the evidence file as you go. Tool inventory, policy, provenance stats, gate configs, exception log — one folder. When the auditor asks, you hand over a folder instead of a promise.

The objection we hear on move 2: provenance tagging slows engineers down and they'll skip it. In practice the tag is a commit trailer the tooling adds, not a form someone fills in. That objection describes the policy-PDF version of governance, not the tooling version.

What it looks like six weeks in

Composite from rollouts inside client deliveries — fintech scaleup, 30 to 80 engineers, high agent adoption, no provenance, a customer security questionnaire sitting unanswered because nobody could describe the AI share of the SDLC.

Six weeks later: a bot tags model-drafted changes at commit time, so the AI-drafted share of merges is a dashboard number instead of a guess. Repos are risk-tiered. Anything calling a model at runtime runs an eval job in CI. The evidence file exists.

The outcome worth copying is counterintuitive. Review time per diff spikes in week one, then settles at or below baseline — because reviewers stop treating every change as equally suspect. The stalled security questionnaire gets answered from the evidence file in a day. And the tooling debate changes tone, because arguments about impressions become arguments about a dashboard.

None of it required slowing the agents down.

What this is not

It is not a case for treating model-drafted code as suspect by default. Model-drafted code that passed a real review and a real test suite is production code. The vibe-coding failure mode — shipping unread model output — is a review failure, not a tooling failure.

The tools are already in your building and the volume is already in your main branch. The only open question is whether the signature on the merge still means anything. Governance that lives in a document drifts. Governance that lives in the pipeline holds.

Full breakdown — the three postures compared, the rollout timeline, and the legal accountability question: teamvoy.com/blog/ai-generated-code-accountability-2026

Written by Zhanna Yuskevych, CPO at Teamvoy. More engineering writing at teamvoy.com/blog.

Your GenAI Pilot Didn't Fail. Your Data Layer Did.

Teamvoy — Fri, 21 Aug 2026 10:29:44 +0000

MIT found that 95% of enterprise GenAI pilots returned no measurable P&L impact, and only 5% reached production at scale. Almost none of those failures were model failures.

The stalled pilots we get called into look identical from the inside. Someone spent three months on prompts and model selection. Nobody looked at the pipeline feeding it. When we trace a bad output back, it is a brittle query pulling stale or wrong records — the model was working correctly on garbage. Fix the pipeline and the same model suddenly looks smart.

The model is the kernel. The integration layer is the operating system around it, and that is where pilots die. Gartner forecast $644 billion in global GenAI spend for 2025, up 76.4% in a year, against that 95% figure. Big spend is not safe spend.

The demo-to-production cliff

A demo runs on clean, hand-picked data. Production does not. That is the entire gap, and it has three concrete failure modes once an agent gets write-access:

Runaway cost. An agent stuck in a retry loop runs unattended for hours and burns thousands in API spend before anyone wakes up.
Prompt injection. The top agentic risk, and not hypothetical — one arXiv study cut attack success from 73.2% to 8.7%, but only after layering multiple defenses. A single successful injection exfiltrates a secret in minutes.
Quadratic token growth. Cost can scale with the square of context length, not linearly. "Just add more context" gets expensive fast, and past roughly the 40% context-fill mark many models get less accurate anyway. More context is not free, and it can make the system dumber.

None of these are model-quality problems. They are control problems, and NIST's GenAI Profile (AI 600-1) names all of them.

Three questions before anything gets write-access

Ask these of any partner, internal team, or yourself:

Where is the circuit breaker that stops a runaway agent, and who set the spend cap?
Who owns the audit trail when the agent writes to production data?
What requires human approval before the agent executes a sensitive action?

A clean answer to those three tells you more than any benchmark. Build the circuit breaker before you grant write-access, not after the first incident.

Name your pattern

A demo says "we use AI." A production system names its pattern, and each one has a caveat you inherit:

Self-RAG — the model rewrites its query and checks its own retrieval. Good for messy queries. Extra model calls add latency.
Corrective RAG — filters or rejects weak retrieved chunks. Use when wrong context is costly. Needs a tuned relevance scorer.
Adaptive RAG — routes simple and complex queries differently. Routing logic is its own complexity.
GraphRAG — retrieves over a knowledge graph instead of flat text. Strong on relational data. Graph build and upkeep is real, ongoing work.
Agentic orchestration — bounded tool calls with control flow. Untrusted output must never call tools directly.

These stack into retrieve, rank, generate, verify. Latency compounds at every layer, so caching and tight chunking are not optimizations you defer.

How do you know it works, rather than sounds confident?

Evals. This is the phase teams skip and the reason pilots die on real data.

Automation is safe when you can specify the objective and verify the output against it. No verification, no safe automation — you are shipping on vibes. The phased path that survives contact with production data:

Scope one narrow workflow with a measurable outcome.
Prove it on messy production data, not a clean sample, so you find out where it actually fails.
Add evals and guardrails, so failures get caught before users do.
Harden for latency, cost, and edge cases under real load.
Hand over documented, with rollback in place.

Step five matters more than it sounds. A model has no memory of your system between sessions, so the knowledge has to live in documentation and code rather than in one engineer's head. "Done" means it still works in six months.

What it costs, and where the budget actually leaks

Roughly $50K for a proof of concept, $2M+ for a production system at scale with compliance. But the build is rarely what blows the budget — the runtime is. Quadratic token billing and cloud shock, the penalty for running elastic AI infrastructure with a static data-center mindset. Right-size compute before you scale, not after.

The most expensive AI code is not the broken kind. It is the code that almost works — it runs, it looks fine in review, and it writes to the wrong data while the screen looks correct. That is also true of the pilot itself. It demos beautifully and returns nothing, and the reason is never the part everyone spent three months tuning.

Full breakdown — integration patterns, NIST AI RMF mapping, and how to evaluate a delivery partner: teamvoy.com/blog/generative-ai-implementation-services

Written by Taras Voytovych, Founder & CEO at Teamvoy. More engineering writing at teamvoy.com/blog.

Claude Code vs Copilot Is the Wrong Question

Teamvoy — Mon, 17 Aug 2026 12:59:51 +0000

The most expensive mistake in AI tooling procurement right now is treating Claude Code and GitHub Copilot as substitutes and picking one.

We watched a team standardize on autocomplete alone, then hand it a service restructure. The code compiled, read fine in review, and shipped with the wrong invariants — the kind of plausible-looking output you get when a tool designed to finish a line is asked to make a design decision. Nobody was misusing the tool. They just bought one product and assumed it covered both jobs.

They don't overlap the way the comparison posts imply. Copilot is an IDE assistant that helps a human type faster, with an agent layer bolted on top. Claude Code is a CLI agent that reads your repo, edits files, runs your tests, and commits. Different category, different workflow, different budget line.

Where each one actually wins

Per-line autocomplete and IDE chat: Copilot. Years of telemetry-driven tuning and native reach across VS Code, JetBrains, Visual Studio, Neovim, and Xcode. Claude Code's canonical interface is a terminal, not a cursor in a buffer. The trade-off: the autocomplete surface is shallow by design. Good at finishing a line, mid-quality on a function, wrong tool for restructuring a service.
Multi-file refactors and long autonomous tasks: Claude Code. A 1M-token context window, real shell access, and Agent Teams coordinating through a shared task file and git worktrees. We've run multi-service migrations with one instance on API contracts, one on migrations, one on the test suite, all through a shared TASKS.md. The trade-off: agent loops burn tokens. A documented Express.js refactor came in roughly ten times more expensive than a cloud-sandboxed equivalent. On a narrow, well-scoped issue, Copilot's coding agent often gets there for less.
Code quality on hard diffs: Claude Code. In blind review — reviewers shown unlabeled diffs from Claude Code and leading cloud-agent peers — Claude Code's output was preferred 67% of the time. The trade-off: on easy, well-scoped work the gap is small and closing.
Per-seat cost for a broad rollout: Copilot, not close. Roughly five to ten times cheaper at the daily-driver tier. Claude Code's daily driver sits at $100 per seat per month after the April 2026 reset, $200 for parallel agent workflows. The trade-off: Copilot's headline seat price excludes the agent surfaces, which meter separately. A team living in Workspace closes the gap.

Security and audit: this one genuinely splits

Claude Code wins source-code residency. Code stays on the developer's machine, so a CISO at a bank or insurer isn't signing a data-handling agreement to let source leave the network.

Copilot wins day-one governance. Content exclusions, IP indemnity, audit logs in the GitHub admin surface, and the compliance alignment procurement already accepts.

For a NYDFS-regulated bank or a DORA-scoped insurer, the split we deploy: Claude Code on hardened dev environments for source-bearing work with explicit egress controls and audit hooks through MCP servers, Copilot inside GitHub for review, draft PRs, and the long tail of non-source-bearing work.

What doesn't split: prompt injection through code comments, README files, and dependency metadata hits both tools identically. Same mitigations — confidence thresholds, sandboxed test environments, human-in-the-loop gates.

So how do you actually spend the budget?

Split the seats instead of picking a winner.

Copilot for every engineer, on the tier your governance review clears in under a month.
Claude Code Max layered on top for the ~20% who do refactors and platform work.
Both behind one guardrails layer — audit log routing, secrets access, human-in-the-loop gates — so the tool choice stays reversible.

That third point is the one teams skip, and it's the one that determines whether you can change your mind in a year without re-litigating the whole rollout.

The head-to-head framing is comfortable because it produces a decision. It just produces the wrong one. Pick the lane each tool wins, instrument both, and stop pretending an autocomplete engine and an autonomous agent are competing for the same job.

Full category-by-category breakdown, pricing tables, and the decision matrix: teamvoy.com/blog/claude-code-vs-github-copilot-cto-guide

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog.

Your CI Agent Should Not Have Write Access Yet

Teamvoy — Mon, 17 Aug 2026 09:43:19 +0000

An agent in your pipeline does not fail the way a script fails. A script fails the same way every time. An agent fails creatively, and then tries again.

We watched one retry the same broken fix eleven times against a failing build. No retry limit, no memory of the previous attempt, so every loop looked like a fresh problem to it. It burned compute for most of an afternoon and left the build exactly as broken as it found it. The pipeline never errored. It just never finished.

That is the thing tech leads underestimate: agentic CI/CD is not automation with better judgment. It is a non-deterministic system with commit rights, and it needs guardrails that traditional CI never needed. Confidence thresholds, sandboxes, retry limits, and observability on the agent's own decisions.

The four failure modes scripts don't have

Looping. Without a retry ceiling and memory of prior attempts, the agent repeats itself indefinitely. Cost and wall-clock time, no progress.
Hallucinated fixes. On an unfamiliar error it will invent a fix — a flag that doesn't exist, a config key from a different version. This breaks the pipeline further, or worse, passes and creates a subtle bug downstream.
Non-determinism. Same input, different action across runs. Reproducibility was the whole basis of trusting CI, and probabilistic agents remove it. Debugging gets much harder.
Prompt injection through your logs. This is the one that should stop you. If the agent reads error logs and has execution permissions, a crafted string in a log line is an instruction. Destructive commands, leaked API keys. Your logs are now untrusted input.

Maturity is genuinely low here. Only a small fraction of agent-driven pipeline changes land successfully today. Treat agents as assistants with a review queue, not as replacements for the engineer who owns the deploy.

What to put in place before the agent can commit

Read access and proposals first. Write access after you have evidence.

A confidence threshold. Above roughly 90%, the agent acts. Between 60 and 70%, the action is flagged and waits for a human. Nothing uncertain executes silently.
A sandbox. Let it try to fix the broken build in full isolation. Even a failed attempt produces logs and debugging context an engineer can use. Nothing it does can touch production data.
Retry limits and prior-attempt memory. The cheapest fix for the most expensive failure mode.
Strict input validation on anything the agent reads. Logs included. Especially logs.
A dashboard on the agent's own behaviour. Error rates, rollback frequency, resource utilisation, and drift in decision patterns. Correlate agent decisions against build events so anomalies surface early instead of in the invoice.

Where agents actually earn their place

The wins are real, and they cluster in the same area: deciding what to run rather than running everything.

Test selection. Analyse the change, run the tests it can actually affect, skip the rest. Shorter feedback loops without dropping coverage where it matters.
Flaky test prediction. Historical failure patterns tell you which tests fail for no reason, which is maintenance work nobody wants to do manually.
Risky commit flagging. Build history and error logs predict failures before code reaches production.
Deploy timing and rollback. Pick the window based on load, auto-trigger rollback on post-deploy signals.
Incident triage. Root-cause insight and a suggested corrective action before a human opens the dashboard.

Continuous learning is the headline benefit, but it has a precondition: the agent can only improve if the evaluation harness and observability exist to teach it. That instrumentation is the part most teams skip, and they find out they skipped it when the agent makes a decision nobody can explain.

How do you scope the first agent?

In this order, and skipping either of the first two is how you ship something that works perfectly and changes nothing:

Name the business outcome — release frequency, change failure rate, mean time to recover. Not "adopt AI."
Identify the specific bottleneck, and state how an agent removes it.
Sequence the work so the first agent ships against one measurable bottleneck, not five.
Track the KPI you named in step 1.
Feed what you learn back into scope and guardrails.

The rule we hold: no agent gets write access to a repo before it has spent a sprint proposing changes that a human approved or rejected. The rejection rate is the only honest readiness signal you get.

None of this shows up in a demo, where the agent fixes the broken build on the first try and everyone claps. It shows up on the afternoon it tries the same fix eleven times, or the afternoon a log line convinces it to do something nobody asked for. Guardrails are not the exciting part of agentic CI/CD. They are the part that decides whether you keep the agent.

Full playbook — architecture, benefits, pitfalls, and the guardrail set in detail: teamvoy.com/blog/building-ai-agents-into-your-ci-cd-pipeline

Written by Alyona Kakora, Project Manager at Teamvoy. More engineering writing at teamvoy.com/blog.

Your Rails App Isn't Too Old for AI. It's Too Untested.

Teamvoy — Thu, 06 Aug 2026 14:25:16 +0000

When an AI feature fails to land on a legacy Rails app, it is almost never the model. It is that nobody could safely change the code underneath it.

We picked up an app running Rails 5.2 with 11% test coverage and a Sidekiq queue nobody had looked at since 2021. The team had already built an LLM classifier. It worked on a laptop and had been sitting in a branch for five months, because merging it meant touching a controller that three people were afraid of.

That is the whole argument: modernization is not a rewrite and it is not a version bump. It is the sequence that makes a legacy Rails app changeable again, and then puts AI in the places where the numbers move. Skip the sequence and you get a prototype that lives in a branch forever.

The sequence, and why you don't get to reorder it

Audit, upgrade, test, refactor, then integrate. Every step exists because the next one is unsafe without it.

Audit. Map dependencies, security posture, and tech debt against business priorities. You are deciding what not to touch as much as what to fix.
Upgrade, one major at a time. 4.2 → 5.0 → 5.2 → 6.0 → 6.1 → 7.0 → 7.2 → 8.0. Resolve deprecations at each stop and enable new defaults gradually through config.load_defaults. Skipping a version to save a sprint buys you a month of breaking changes.
Test. Unit, integration, and system coverage, running on every push in CI. This is not hygiene. It is the precondition for everything after it.
Refactor. Extract business logic into service objects and concerns. This is where the seams for AI actually get cut.
Integrate. Only now.

Incremental work also wins on cost - rebuilds have been measured at up to three times the feature development cost of upgrading in place. And there are still over 560,000 live Rails sites, so the population of teams making this decision is not small.

What the AI layer actually looks like

Four components, and none of them are optional if the feature is going to survive a production week.
A provider client. Wrap OpenAI, Anthropic, Hugging Face, or your self-hosted model behind one abstraction. Swap vendors without touching business logic. Swap in a mock during CI so tests are fast and deterministic.
A service object. All AI logic lives here. Testable, replaceable, out of the controller.
A background job. Sidekiq or equivalent. Model calls never sit in the request path. A recommendation engine can chew through user data without adding a millisecond to page load.
**An audit table. **Inputs, outputs, and confidence scores in JSONB on Postgres. When a classification is wrong, you pull the exact pair, fix the prompt, and version the change.

The trade-off nobody puts in the proposal: that audit table grows fast and someone has to own retention on it.

How do you keep the AI layer from quietly costing you money?

Set confidence thresholds before launch, not after the first invoice. When confidence drops below the line, fall back to deterministic logic, a cached prior answer, or a human review queue. Enforce a per-tenant daily cost cap at the job layer, where you can actually stop the work.
Then treat prompts as versioned, testable code and mock model responses in the suite. An untested prompt change is a production change with no rollback story.

When to bring someone in

In-house works when the team ships weekly, has bandwidth for a 20% side program, and the AI use case is scoped tightly. Bring in help when:

Rails is two or more majors behind and no engineer on the team has run an upgrade this decade.
A live prototype never got past staging because nobody owns operations for it.
A board or regulator has set a date, and missing it has a number attached.
The one senior Rails engineer who understood the plan just gave notice.

What to push back on in a vendor quote: any multi-month discovery phase that ends in a slide deck, any proposal naming juniors on delivery, any pricing without a locked scope.
None of this shows up in a demo. It shows up five months later, when the classifier still works perfectly on someone's laptop and the branch has 400 commits of drift behind main. The upgrade sequence is not the interesting part of adding AI to Rails. It is the part that decides whether the AI ever ships.

Full breakdown of the assessment, upgrade path, and integration patterns: teamvoy.com/blog/how-to-transition-legacy-ruby-on-rails-apps-to-ai-enabled-architectures

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog

Your AI Agents Aren’t Failing Because the Model Is Bad

Teamvoy — Wed, 05 Aug 2026 19:23:23 +0000

When your AI agents fail in production, it is almost never because the model got dumber. It is because nobody coordinated them.

On a Tuesday, two of our agents looped through document storage while a third waited for a message that never came. They burned a month of API budget in 90 minutes. Nobody noticed until the finance dashboard turned red.

That is the whole argument: production AI systems break at the coordination seams, not the model. Lost context, duplicated work, silent errors, unbounded cost. Orchestration is the layer that fixes it, and it lives or dies on four unglamorous things: state management, messaging, fault tolerance, and horizontal scale.

The five patterns, and which one to actually start with

Start with sequential or handoff. Both are the easiest to reason about, evaluate, and operate when something breaks at 2am.

Sequential: agent output feeds the next agent. Tight accuracy control on document review and approvals. Higher latency.
Handoff: a router agent classifies the request and passes it to a specialist. Great for tiered support and tool routing. The router becomes a single point of failure.
Concurrent: parallel independent subtasks for research and data enrichment. You pay for synchronization and merge.
Group chat: a shared conversation for strategic diagnosis. Higher token cost and painful to audit.
Magnetic: agents iterate with feedback loops for adaptive monitoring. The hardest to bound on cost and stop conditions.
Choose the pattern per task, not per project. Most teams over-engineer here and reach for group chat when a two-step sequence would have shipped in a week.

How do you catch an agent quietly degrading in prod?

You wire the metrics in before launch, not after the incident. One fintech client watched a classification agent slide from an F1 score of 0.89 to 0.72 over six weeks, and nobody noticed until we rebuilt the evaluation harness against labeled tickets. By then the drift was live in front of users.

What to instrument on day one:

BLEU for generation quality.
Precision and recall for classification and retrieval.
F1 for the balance between them.
Cost per task, latency per agent, and drift over time, on a dashboard that alerts on regressions.
The rule we hold on every engagement: no agent ships to production without a documented fallback path.

What it costs to do this seriously

A scoped first workflow runs four to twelve weeks. That covers pattern selection, framework choice (LangChain, IBM Granite, and friends), infrastructure setup, agent development, and the evaluation and audit layer. If you are staffing it properly, budget 80,000 to 250,000 dollars before the ongoing model and infra costs that scale with volume.

None of these failures show up in a demo. They show up on a Tuesday, three weeks in, when the dashboard turns red and nobody can say which agent did it. Orchestration is not the exciting part of building with AI. It is just the part that decides whether the thing survives contact with real traffic.

Full breakdown of all five patterns and the infrastructure behind them: teamvoy.com/blog/ai-agent-orchestration

Written by Bohdan Varshchuk, CTO at Teamvoy. More engineering writing at teamvoy.com/blog