Engagements · 6 ways to work with Loop

The shape of the engagement matches where you are.

From a single embedded engineer to a 6–10 week transformation sprint. Every offer is built around one belief: the future of QA leadership is not owning test execution. It's owning the quality intelligence layer that helps engineering ship with confidence.

Section 01 · People

Loop SDETs and the hiring function around them.

PPL-001People

Embedded QA

A senior SDET on your team, beachheading AI-native quality.

Buyer state. “We need someone who can show our team what AI-augmented testing actually looks like.”

Loop's embedded QA engineers join your team as full members. Not contractors who throw deliverables over a wall. They're senior SDETs who understand augmented coding and AI deeply, and their job is to prove the new operating model by living it: shipping leverage every week, mentoring teammates into the practice, and turning the hiring profile of QA inside your org.

PPL-002People

Managed Hiring

Tech screenings for companies who don't yet know how to hire for AI.

Buyer state. “I have headcount, but I don't trust our pipeline to assess AI fluency.”

Most engineering orgs haven't yet retooled their interview loop for AI-augmented work. Loop runs the entire screening process. Coding interview design, technical screens, take-homes, debrief calibration. For QA and engineering hires where AI fluency, system thinking, and quality intuition all matter. You see only the candidates who pass our bar.

PPL-003People

Traditional Recruitment

Direct candidate placement at a standard recruiting fee.

Buyer state. “I just need qualified QA / engineering candidates.”

If you'd rather skip the screening engagement and just see qualified candidates, Loop also runs traditional recruiting on a standard per-placement fee. Same talent pool, same quality bar. Just a leaner contract structure for teams that already know how to interview.

Section 02 · Engagements

Diagnosis, alignment, and transformation.

AUD-001Audit

QA Leverage Review

A one-day private review of your QA team, process, automation, dashboards, and constraints. Through a leverage lens.

Buyer state. “I need a clear, outside diagnosis of our current QA setup before we buy more tools, reorganize the team, or expand automation.”

Not a generic workshop. The day is built around your current QA reality. Your people, your access, your automation, your dashboards, your team's skills, and the constraints you're operating under. Pre-work intake → curated agenda → one-day private review → takeaway packet with a 90-day plan and a boss-ready summary memo.

ALN-001Alignment

Quality Strategy & Leadership Alignment

A 3–6 week leadership engagement to align QA, engineering, product, and executives around how quality should work in the AI era.

Buyer state. “We know QA needs to change, but the change can't be made by the QA leader alone.”

Not a training day. A leadership engagement that begins with a private current-state diagnosis (intake + optional stakeholder interviews), runs a one-day core session that aligns QA, engineering, product, and executive leadership on the future operating model, and follows with three 90-minute progress reviews so the strategy turns into operating change.

SPR-001Sprint

Quality Transformation Sprint

A 6–10 week implementation sprint where we work alongside your team to move QA from test execution to a higher-leverage quality operating model.

Buyer state. “We know the current QA model isn't creating enough leverage. We need hands-on help changing it. Not another strategy session.”

Not another strategy session. Over 6–10 weeks we work alongside your QA, engineering, product, and leadership teams to change how quality actually happens. Review real QA work, redesign ownership, ship an AI/automation pilot, build the dashboard, and establish the management cadence that makes the new model stick.

Track record

Last year of engagements, in numbers.

30+

Engagements shipped

94%

On-time releases

−42%

Avg. regression CI minutes

0

Critical escapes (last 12 mo)

Numbers reflect engagements where Loop ran the operating-model reset or the transformation sprint. See the client roster for the full case set.

From past engagements

What clients say about working with Loop.

01
“The audit told me three things I'd been missing. Worth it before I argued for headcount.”
. SarahQA Director at

Series-B fintech · ~50 engineers

Engagement: QA Leverage Review

02
“The reset workshop got our VP of Eng on the same page as QA. The 90-day plan we left with is now policy.”
. MarcusHead of Quality at

Healthcare SaaS · 120 engineers

Engagement: Quality Strategy & Leadership Alignment

03
“The sprint shipped a regression-reduction pilot that reclaimed 22 engineering-hours per sprint. ROI was visible by week 6.”
. PriyaQA Director at

E-commerce platform · 200+ engineers

Engagement: Quality Transformation Sprint

Names + companies anonymized at the speakers' request.

Watch · Companion videos

Talks behind the engagements

Subscribe on YouTube · @benfellows-dev
Set Up Policy as Code in 1 Hour (Control AI Code Fast)

Apr 28, 2026

Set Up Policy as Code in 1 Hour (Control AI Code Fast)

If you want to start controlling AI-generated code today, this is the simplest way I’ve found to do it. In the previous videos, I talked about why agentic development breaks at scale and introduced the concept of policy as code as a way to fix it. In this video, I’m showing how to actually get started. The idea is straightforward. Instead of relying only on prompts, rules, or memory to guide AI, you introduce a deterministic layer that scans your codebase and flags violations. Think of it as a much more comprehensive, fully customizable linting system that works alongside tools like Claude. What surprised me is how easy it is to get a first version working. In this walkthrough, I show how you can go from zero to a basic policy as code setup in a very short amount of time. We start by generating a small set of rules, wire up a simple scanner, and immediately run it against a real codebase. Even with a basic setup, you’ll start catching issues and inconsistencies right away. This is not the full system I use in production. At scale, this turns into hundreds or even thousands of rules, with more advanced concepts like evidence layers, caching, and reporting. But the goal of this video is to show that you don’t need any of that to begin. If you’re using AI to write code and you’re starting to see drift, inconsistency, or quality issues over time, this is a practical way to start putting guardrails in place. Over time, what I’ve found is that as you add more rules, the amount of drift drops significantly, and the system becomes more reliable without slowing development down. If you haven’t watched the earlier videos in this series, I’d recommend starting with those for more context on why this approach exists and how it fits into a larger agentic workflow. If you try this yourself, I’d be interested to hear what kinds of rules you end up writing and what it catches in your codebase.

Watch on YouTube →
I Tried Building with Agentic Factories. They Failed. Here’s What Worked Instead.

Apr 27, 2026

I Tried Building with Agentic Factories. They Failed. Here’s What Worked Instead.

I spent time building with “agentic factories” - multi-agent pipelines that promise fully autonomous workflows. On paper, they look like the future. In practice, they broke down in ways that matter: reliability, coordination, and real-world constraints. In this video, I break down where these systems failed, why they fail structurally, and what actually worked instead in production. If you're building with AI agents, this will save you time (and probably some pain).

Watch on YouTube →
How We Use Policy as Code to Control Claude and AI Agents

Apr 24, 2026

How We Use Policy as Code to Control Claude and AI Agents

Claude and other AI agents are incredibly good at writing code. The problem is they don’t stay consistent over time. In the first few iterations, everything looks great. Output is fast, patterns are mostly correct, and it feels like you’ve unlocked a new level of development speed. But as the codebase grows, small inconsistencies start to compound. Patterns drift, structure degrades, and eventually the system becomes harder to maintain than it was before. That’s the problem this video is about. In this walkthrough, I break down how we use a concept called policy as code to control AI-generated code in real systems. Instead of relying only on prompts, rules files, or memory, we introduce a deterministic layer that enforces how code is allowed to be written. Every time an agent makes changes, those changes are checked against a large set of rules. If something doesn’t match the expected patterns, it fails. The agent has to fix it before moving forward. This ends up acting like a much more comprehensive version of linting, but tailored specifically to your architecture, your patterns, and your codebase. The result is that we’re able to keep the speed benefits of AI while dramatically reducing drift and long-term degradation. This video focuses on how the system works in practice. What kinds of rules we write, how they’re structured, and how they integrate into an agentic workflow using tools like Claude. If you’re experimenting with AI coding and running into issues with inconsistency or quality over time, this is one approach that has worked well for us. I’ll also be doing follow-up videos on how to implement this from scratch and how it fits into larger agentic pipeline systems. If you’ve tried something similar or have different approaches to controlling AI-generated code, I’d be interested to hear about it.

Watch on YouTube →

Not sure which one

Start with the public course or the audit.

The public course gives you the framework and a 90-day plan. The audit applies it to your team. Most clients move up the ladder from there.

Template

90-Day QA Leverage Plan