Hey — I'm Sergii, I run ConnectiveOne (an AI-powered comms platform) and co-founded Evergreen, a dev shop out of Kyiv. I want to walk through, in actual technical detail, how we rebuilt our SDLC around AI agents — not the "we added Copilot" version of this story, the version where it took us over a year, we broke things, and we ended up with a setup that other engineers might actually find useful to steal from.
TL;DR: giving a coding assistant unlimited scope and just chatting with it doesn't scale past a certain point. Giving it a narrow role, a written spec of its boundaries, and a quality gate before a human ever sees the diff — that scales. This post is the "how," with the actual structure we use.
If you've used Claude Code or Cursor for more than a few weeks, you've probably hit this: you git clone, you start asking it things — "why is this erroring," "can you refactor this," "how do I wire this up" — and for the first few sessions it's magic. Then context starts leaking. It re-derives your architecture every session. It doesn't remember the convention you told it about three days ago. Token costs climb. And the output quality becomes a function of how well you phrased the prompt that particular morning, not a property of your codebase or your process.
That's not a model problem. It's an architecture problem — you're running a chat, not a system.
Here's the mental model shift that actually mattered: stop treating the agent like a chatbot you're negotiating with, and start treating it like a new hire you're onboarding. A new hire doesn't get "here's the whole codebase, go wild." They get a role, a scope, a set of docs to read, and boundaries on what they're allowed to touch.
We formalize this as a rules layer that lives in the repo, versioned like everything else. If you're on Cursor this is literally .cursor/rules and .cursor/agents; if you're on Claude Code or something else, the mechanism differs but the principle doesn't: if a convention isn't written down somewhere the agent can read it, it doesn't exist as far as the agent is concerned. Don't rely on the model "just knowing" your team's patterns from the code alone.
A simplified version of what one of our role files looks like:
role: backend-development-agent
scope:
- services/orders/**
- services/payments/** (read-only, no writes)
forbidden:
- infra/**
- CI/CD config
- anything touching auth middleware
inputs:
- architecture spec (docs/specs/orders-service.md)
- existing test suite
outputs:
- implementation + updated unit tests
- updated README section for the touched module
must_pass_before_handoff:
- lint
- full test suite (local)
- self-review checklist (see docs/agent-checklist.md)
Nothing exotic here. The value isn't in any single line — it's that this document exists at all, is checked into version control, and is the actual contract the agent operates under, instead of whatever context happened to survive to the end of a long chat session.
Rules as source of truth. Already covered above — the point is it's a versioned artifact, not tribal knowledge in a senior dev's head.
Role-based agents, not general-purpose ones. We run separate agents for backend, UI/UX, QA, architecture review, and documentation — each with its own scope file like the one above. This sounds like overhead until you compare it to the alternative: one assistant that touches everything, with quality that degrades the more creative latitude you give it. LLMs behave better with a tight job description than with "help me with anything," the same way a contractor does better with a scope of work than with "make the house nicer."
AI transforms the SDLC, it doesn't replace it. Our actual pipeline: requirements → design → dev → test → deploy, with an agent (or agent pair) per phase and an explicit handoff artifact between phases — a markdown spec, not a copy-pasted Slack message. If your team's process for sharing a good prompt is "I pasted it in our dev channel," that's not a system, that's folklore, and it doesn't survive the person who wrote the prompt going on vacation.
We tried going straight to "multiple agents running in parallel across the codebase" early on. It went about how you'd expect: fast, confident-sounding output, and a nontrivial chunk of it subtly wrong in ways that were expensive to catch after the fact.
What worked instead — and what I'd tell any team starting this today:
This is the part people get anxious about, so let me be specific instead of hand-wavy.
We run automated review (CodeRabbit, in our case) as a first-pass filter — style, obvious issues, convention violations, basic security smells. That's it. That's what it catches. It does not catch intent drift — an agent producing code that's clean, passes tests, lints fine, and still solves a subtly different problem than what was actually asked, because context drifted over a long session or an upstream agent handed off a stale spec. That class of failure needs a human, every time, no exceptions. Architecture decisions and business-logic correctness stay human. Final merge sign-off stays human.
What changes isn't whether a human is in the loop — it's what the human is actually reviewing. Less "does this line of code look right," more "does this diff match the intent, and did the agent stay inside its scope file." That's a different skill than traditional code review, and it's worth explicitly training your team on it rather than assuming it transfers automatically.
Here's the thing that bit us hardest and that I don't see written about much: when an agent-generated change causes a problem three weeks later, "why did it do this" is not something you can just ask the engineer who reviewed the PR, because they reviewed a diff, not a decision process. And re-running the same agent against old context and hoping it explains itself consistently is not a reliable debugging method.
We ended up building an internal orchestration layer (we call it C1Cursor) specifically to solve this — every agent-generated diff gets tagged at execution time with: which agent, which role/scope, what context it actually had access to (which docs, which code, which upstream agent's output), and which gates it passed or failed. This turns "why did this happen" from an archaeology project into a lookup. If you're rolling this out yourself and don't have budget for custom tooling, at minimum log this metadata somewhere queryable — even a structured commit message convention is better than nothing.
Doing all of this got ConnectiveOne to roughly +300% development velocity year over year, against our own prior baseline. I mention it because people ask, but I wouldn't lead a technical conversation with it, because velocity without the gating and provenance layer above is exactly how teams end up shipping fast and debugging blind. The metric that actually told us this was sustainable wasn't velocity — it was our quality-gate pass rate holding steady as we added more agents and more parallelism. Velocity was downstream of that staying true, not a separate win to brag about.
Don't start by picking a model. That's the wrong first decision. Start by writing down, in a file your agent can actually read, what one narrow process is allowed to touch and what it isn't. Prove that one thing works on real tickets. Then add the next role. Resist the urge to parallelize before your gates are boring and reliable — boring is the goal, not a consolation prize.
Happy to go deeper on any piece of this in the comments — the role-file format, the provenance tooling, or the QA agent setup specifically. This is still an evolving system for us, and I'd rather compare notes with people building the same thing than pretend we have it fully solved.