iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Mikael Krief’s method for AI-assisted development divides the work by stage. Claude handles refinement, architecture reasoning and specification before any code is written. GitHub Copilot, run as an agent from VS Code, executes narrow prompts that are stored in Git. Krief summarizes the split as “The boundary is clear: Claude thinks, Copilot executes.” He presents it as the author’s framing from one team’s experience, not as a vendor recommendation or an independently validated rule. His account was published on DEV Community on September 23, 2026.
The project behind the method
The team built a full-stack web application with a .NET backend, a Vue 3 frontend, a PostgreSQL database and hosting on Azure. The application handled payments, electronic invoicing, AI-based candidate scoring and automated multilingual translations. Those details matter for reading the method correctly. It was developed for a business system with security requirements, data-integrity rules and legal or regulatory constraints, not for a demonstration project. Everything about the project comes from the author’s own description.
What each tool owns
The split is easiest to see as a division of responsibility between planning and execution.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →| Stage | Claude | GitHub Copilot (agent in VS Code) |
|---|---|---|
| Feature definition | Refines scope, dependencies, data model and business rules into a versioned template | Not used for scoping |
| Architecture | Reasons through the design and records the architectural decision record | Works within the design it is given |
| UI direction | Sketches a UI mockup during refinement | Implements the screen or component named in the prompt |
| Code change | Not used for direct edits in the described workflow | Reads the listed files, produces the requested delta, runs tests and stops |
| Documentation | Part of the refinement template | Updates the technical references the prompt requires |
The division is a working rule for this team. It is not a claim about what either tool can or cannot do.
#1 Best Overall
Step one: refine the feature before any code
Each feature starts as a conversation with Claude that produces a versioned template. According to the article, the template covers:
- Scope and dependencies
- Data model
- Business rules
- Frontend components
- Tests and acceptance criteria
- Documentation to be updated
- The architectural decision record
Refinement is where the team settles the open questions. Once the template is complete, the implementation work is mostly a matter of applying it, which is why the author treats upfront refinement as the source of the reduced back-and-forth described later.
Rank #2
Step two: treat each prompt as a project artifact
Prompts are not improvised chat messages. They are *.prompt.md files kept in Git and triggered from VS Code, so they can be reviewed, versioned and reused like code. The author describes four constraints on how each prompt is written:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall- One scope per prompt. Each prompt addresses one functional scope and one technical layer, either backend or frontend.
- Declared tools and inputs. The prompt names only the MCP servers it needs and lists the files Copilot should read.
- Delta-only edits. The prompt asks for the change itself rather than a regenerated file.
- A fixed output format. The response shape is specified in advance.
In the author’s description, Copilot then reads the specified files, makes the requested change, runs the tests and stops. Stopping at a defined boundary is what keeps a single prompt reviewable.
Step three: protect the rules the model should not infer
Some knowledge should never be left to the model’s judgment. The team handles it in two ways.
Business invariants
Security rules, data-integrity rules and legal or regulatory constraints are written down as shared invariants. They are included in every prompt where they apply, rather than being assumed or remembered from earlier sessions.
Rank #4
UI references and Figma
Versioned UI reference files hold module-specific rules for components, colors, typography and interaction. The team connects Figma through MCP selectively, only when a screen or component is implemented for the first time. Later changes rely on the reference files instead of the design tool.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step four: count documentation as part of completion
Each prompt requires updates to the relevant technical references. The author says the project publishes that documentation to GitHub Pages on merge. The principle is stated directly in the article: “Documentation is not a separate step. It is part of the definition of done for every prompt.”
Best Value
What the author reports, and what it does not show
Prompt-size reduction of 50–60%
The author estimates that delta-only instructions reduced prompt size by 50–60%. This is the author’s own estimate. The article does not describe how it was measured and does not offer independent corroboration, so it should be read as one team’s result rather than a general benchmark.
Less rework over several months
The author says that over several months the clearer division of roles, shared conventions, constrained output, reference files and upfront refinement reduced rework and back-and-forth with the tools. These are qualitative observations from a single project. They are not controlled measurements, and the article does not separate the effect of each practice.
Limits of this account
- The article does not compare Claude and GitHub Copilot on common tasks, and it does not compare this process with any other team’s workflow.
- It does not measure output quality, review effort, security outcomes, integration effort or cost for either tool.
- Product behavior changes. The setup described reflects the author’s configuration at the time of writing, so check the current behavior of Claude, GitHub Copilot, VS Code, MCP and Figma integration before copying the setup.
- No product prices or plan details appear in the article.
A fair test of this approach would compare output quality, review and rework, data handling and cost on the same tasks with and without the structure. The article supplies none of that evidence.
Recommended Free Tools
The Bottom Line
The separation is the transferable part: decide who plans and who executes, keep each prompt to one scope and one layer, write business invariants down, and make documentation part of done. The percentages and productivity impressions are one team’s reported experience. As Krief puts it, “AI doesn’t replace architectural rigor. It amplifies it — in one direction or the other.”
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

