The Loop Has Changed: Running Claude and GitHub Copilot with a Dev Team of 10

In a traditional development workflow, progress looks something like this:

read → understand → write → test → fix → repeat

A developer picks up a ticket, reads through the requirements, figures out what they are actually being asked to build, writes some code, discovers the gaps, fixes them, and loops back. The cycle is familiar. It works. It is also slow in specific ways — most of the time between ticket assignment and PR open is not spent writing code. It is spent building enough understanding to write the right code.

With an agent in the loop, the cycle shifts:

define → plan → execute → validate → refine

That looks similar on paper. In practice it is a fundamentally different relationship between a developer and their work. Here is what that looks like six months in with a team of ten.

The Setup

Ten developers. Mix of experience levels — two seniors, five mid-level, three junior. Stack is primarily .NET and React, Azure infrastructure, with some Python in the data layer. GitHub Copilot was already in place when we introduced Claude Teams. We did not replace one with the other — they ended up occupying different parts of the loop.

GitHub Copilot lives inside the execute step. Autocomplete, inline suggestions, function completion. It operates at line and function granularity, and developers interact with it constantly, mostly passively. It accelerates the inside-the-editor work.

Claude operates before the editor opens. Problem definition, planning, architecture. Developers bring it a problem, not a cursor position.

The tools separated cleanly without much deliberate design on our part. Copilot makes execution faster. Claude changes what you are executing and why.

Define

The first step in the new loop sounds obvious: define the problem. It is not.

Before Claude, developers often started implementation with a partially-formed understanding of what they were building. The ticket said one thing, the actual requirement was something else, and the gap surfaced two days into development. That is not a process failure — it is just how understanding accumulates when writing code is the primary mode of exploration.

When the agent is doing the writing, the developer's understanding has to come first. Vague inputs produce vague outputs. Claude will ask clarifying questions on an underspecified problem, which is less an annoyance and more a forcing function — a structured prompt to think before you build.

A useful problem definition includes context, the specific problem, constraints, and acceptance criteria:

Context: Multi-tenant SaaS app. Tenant data isolated in Cosmos DB, 
partitioned by tenantId.
 
Problem: Background job to aggregate usage metrics per tenant daily, 
writing a summary document. Must not affect read throughput for 
active tenants during business hours.
 
Constraints:
- 2-hour execution window (runs at 2am UTC)
- No cross-partition queries
- Output schema must match existing reporting model
- Idempotent — safe to re-run on failure
 
Acceptance criteria:
- Tenants with 0 events get a zero-count doc written, not skipped
- Handles tenants created after the job starts
- Per-tenant success/failure logged independently

That is a different starting point than "write a daily aggregation job." The difference in output quality is proportional to the difference in input quality.

Plan

Before any code. This is where the new loop diverges most sharply from the old one.

Claude produces a plan: the approach, key design decisions, components involved, implementation sequence, error handling strategy, testing approach, and open questions where the plan is making assumptions that need validation.

The team reviews the plan. Not the code — the plan. This is where the architecture conversation happens: Is the approach sound? Does it fit existing codebase patterns? Are there constraints the problem statement missed? Does the proposed structure create technical debt that will matter in six months?

What a solid plan covers:

• ›Component breakdown — what gets created or modified and why
• ›Data flow — what goes in, what comes out, where state lives
• ›Error handling — specifically what happens at each failure point, not "handle errors"
• ›Testing approach — what gets unit tested, what needs integration coverage
• ›Risks and assumptions — where the plan is guessing and what would change the approach

The plan is the contract between the developer and the agent. If something in the plan is wrong, you fix it here, in language, before it is encoded in implementation.

Execute

Once the plan is approved, Claude executes it.

This is not "generate some code snippets and assemble them." For a well-specified problem with a solid plan, Claude produces working, structured, tested implementation that fits the project. Not always perfect — but the starting point is substantially above what a developer produces in the same time, especially on well-understood patterns: CRUD layers, integration clients, background job scaffolding, middleware, test harnesses.

Copilot fills in alongside — as developers review the generated output, extend it, and handle the fine-grained editor work of making it fit precisely. The two tools are not redundant here. Claude sets the structure; Copilot accelerates the detail work within it.

Validate

The old loop had testing and fixing entangled in the same step. The new loop separates them. Validate is deliberate: does the implementation match the plan? Do the tests pass? Are the acceptance criteria from the define step actually satisfied?

This is where human judgment is non-negotiable, and where the loop does not reduce oversight requirements — it changes their focus.

Domain correctness. Claude does not know your business. The problem statement carries domain context, and only carries what you put into it. If acceptance criteria miss a business rule, the implementation misses it too. That is on the humans who wrote the definition.

Security. AI-generated code is not exempt from security review. We run the same checklist on generated PRs as manually written ones — auth boundaries, input validation, secrets handling. Generated code can look structurally correct and be subtly wrong in ways that standard review catches.

Integration points. When new components touch existing systems not fully represented in the problem context, verify. Generated code makes reasonable assumptions. Reasonable assumptions about undocumented internal APIs are sometimes wrong.

Code review still happens. What changed is its function. It is no longer primarily where architectural decisions get surfaced and debated — those happened in plan review. Code review is now correctness verification and implementation-to-plan conformance. Narrower scope, faster cycles, fewer revision rounds.

Refine

The old loop's "fix" step was reactive — something was wrong, find it, fix it, ship it. The new loop's refine step is more deliberate. It is where the output of validate informs the next iteration: tighten the definition, adjust the plan, re-execute a specific component, raise the test threshold.

Refine is also where the team's own practices improve over time. What made a problem definition vague? What did the plan miss? What did validate catch that could have been caught earlier? The loop is self-improving if you pay attention to it.

What Shifted on the Team

Junior developers grew faster than expected

This was the most surprising outcome. Juniors can now work on problems above their previous independent capacity, with the plan as a structural guardrail. They are not just consuming generated code — they are learning why the architecture is structured the way it is, because they participated in the plan review and watched the implementation follow from it.

The mentoring relationship shifted from "let me fix your code" to "let me help you write a better problem statement and walk through the plan together." That is a more useful interaction at every level.

The productivity gain showed up in the wrong place

We expected faster code. Implementation time on well-specified features is down significantly — features that previously took three to five days of implementation frequently close in one. But that is not where the real gain landed.

The gain is fewer wrong things built. Features that match the requirement on the first pass. PRs that do not bounce back for architectural reasons. Designs that survive the integration step because the plan anticipated it.

Implementation speed is a line item. Shipping the right thing is a program.

Where This Leaves the Developer's Role

The shift from code-writing to application architecture as the primary developer activity is not a future state. It is already the reality on this team.

The developers who are thriving are the ones who can articulate problems precisely, reason about architecture, and evaluate a plan before it becomes code. They are spending their time upstream — in the define and plan steps — where their judgment has the most leverage.

The developers who are struggling are the ones who want to go straight to the editor. That instinct is not wrong. It worked for a long time, and inside the execute step, it still works. But the highest-value contribution a developer makes right now is before the editor opens, not inside it.

GitHub Copilot makes execution faster. Claude changes the loop. Together, with a solid testing baseline and real oversight on the things that require human judgment, the combination is genuinely different from what came before.

read → understand → write → test → fix → repeat

That loop still exists. It has just moved inside the execute step, where the agent runs it at a speed and scale no individual developer matches. The human loop is now the one around it.

define → plan → execute → validate → refine

That is where the work is.