Scaffolding before agents — AI tooling for Azure DevOps work
In June I gave a Polish webinar for AI Now Polska #2 — Utilizing AI Tooling as Azure Cloud DevOps, or, on the slide deck, from autocomplete to AI-native engineering. Same SysOps Polska orbit as the January SysOps meetup write-up (after all, it’s organized by the same team), but different audience: less Terraform-on-Foundry, more “how do I actually use this Monday morning when pipelines fail and three repos need the same fix.”
This post is the English version of what I was talking about during my presentation; you do not need to clone the repo to follow the ideas.
Most of the talk was not model benchmarks or “top ten prompts.” It was organisational maturity — where your team sits on the adoption curve, not whether you personally can paste a clever instruction into chat. That framing comes partly from Cursor’s Forward Deployed Engineer bootcamp I attended earlier this year: four rough stages (autocomplete → synchronous agentic IDE use → asynchronous cloud agents → something like a software factory built on top of the platform). The detail in their deck is enterprise sales shaped; the bit I kept for my own work is simpler — you cannot skip scaffolding and still expect async agents to behave.
Even when individual engineers are already comfortable with Plan mode and MCP, the gain multiplies once that setup is shared — a common instructions repo, checked-in MCP templates, the same review step before pipeline edits. In delivery I optimize for making good practice portable across the team, not tied to whoever happens to be in the IDE that afternoon.
Where teams actually get stuck
Phase 1 is uneven adoption — some people use agents daily, others never open the panel, every squad invented its own prompt doc in OneNote. Phase 2 is where I think most platform-minded DevOps teams want to be: synchronous agentic work in the IDE, with guardrails, skills, and enough trust that a plan gets reviewed before code lands. Phase 3 is cloud agents and automations running while you are in a meeting. Phase 4 is custom tooling — SDK, internal MCP servers, your own copilots on shared primitives. On the slide deck I also showed a capstone layer — trust and governance: read-only defaults, human gates before writes, and risk posture that matches what security and delivery actually accept. That is not a separate “AI project”; it is what makes Phases 2–4 survivable in enterprise delivery.
The mistake I wanted to warn against: jumping to Phase 3 because leadership read an article about overnight refactors. Without a versioned config repo, without AGENTS.md in the repos people actually touch, without MCP wired (at least) read-only so the agent can see Azure DevOps instead of guessing — async agents just burn concurrency budget on confident nonsense.
That is not an argument against cloud agents. I use synchronous agents heavily. It is an argument for treating AI adoption like platform engineering: foundations first, then higher layers.
Context is the product
For the webinar I walked through a fictional multi-repo workspace — the kind of shape you see on Azure platform engagements: application repos, an IaC repo, pipeline definitions, documentation checked in as markdown (including wiki content cloned to Git). Nothing in that layout is meant as a copy-paste for an already existing project; it is a teaching shell so the audience could see how an assistant behaves when the topology matches what a platform engineer already holds in their head — which repo owns CI, where environment config lives, where runbooks sit.
The point is not the sample app names. It is wiring context so the model stops guessing.
Treat the machine like a knowledge graph built from plain text. A workspace-level AGENTS.md is the entry point: environments, branching rules at a high level, “prefer MCP over ad-hoc CLI when gathering facts,” pointers into runbooks. Path-scoped instructions under .github/instructions/ for the stacks you actually run — Terraform, .NET, front-end, wiki markdown. Reusable prompts for work that repeat commonly used operations: triage a failed pipeline run, map a change across repos, review a Terraform plan without auto-apply. Cursor skills can mirror the same domains if your team uses Agent mode.
None of this is novel computer science. It is the same discipline as good internal docs, except the consumer is now an agent that forgets everything unless you spell it out again. Text files, committed, reviewed like code.
One slide line that I would like to emphasize even more: do not write AGENTS.md alone. Describe what the repo contains and let the agent draft the file, then you edit it. Meta, but it saves an hour and surfaces gaps in your own mental model.
Plan mode as a team habit
The workflow I demoed is intentionally slow. Intent in chat → agent produces a markdown plan → human reads and edits → only then implementation. For platform work that touches pipelines and IaC, “slow” is faster than reverting a half-right YAML change at 17:45.
We already plan non-trivial Terraform in short markdown plans under docs/ before touching pipelines or modules; Plan mode is the same muscle with the agent holding the pen first. Teams that skip the plan step tend to get flashy diffs that miss approval gates or environment ordering — same failure mode as before AI, just produced quicker.
What’s pretty cool, when I showcased that workflow in Cursor, it was still not available as a feature of the Cursor IDE, but present in Claude. During the last few weeks, the Plan Mode is now officially available in Cursor as well. As always with those AI meetup talks - three weeks later they are already obsolete.
MCP — stop making the model guess your platform
The other half of the demo was MCP servers, where the aim is for the assistant to query real systems instead of inventing pipeline names.
In the webinar configs I showed read-only defaults:
- Azure DevOps MCP — work items, builds, logs, wiki, PR search
- Azure MCP — resource graph style reads with
--read-only - Terraform MCP — provider-aware help and, if you run it, TFE-facing operations
That --read-only flag matters in enterprise conversations. Security teams worry about LLMs deleting resource groups; showing read-only MCP as the default posture gets further than philosophical arguments about prompt injection. When write access is justified, it should be deliberate — scoped tool, scoped identity, human gate — not “give the agent full az because it is convenient.”
Without MCP, every “why did build 4812 fail?” question becomes a paste of log fragments and hope. With MCP, the agent pulls the log, correlates to the commit, checks the wiki runbook page you linked in AGENTS.md. Still wrong sometimes — but wrong with citations you can verify.
I also mentioned CLI-style agents for work that is not “open this repo” — summarising incident threads, drafting comms, chewing through spreadsheets. IDE for code-shaped context; terminal agent for everything else. Pick the surface by shape of work, not loyalty to one vendor tab.
Shared config is a team sport
The pattern I demoed is a central ai-tooling package — one repo or monorepo folder owned by whoever owns developer experience, plus a sync step to push instructions and MCP templates into application repos. Curate prompts from community lists like awesome-copilot rather than importing every marketplace plugin because it exists.
I had to trim content hard for the webinar — Terraform on Azure, ADO pipelines, .NET, a front-end stub, wiki-style runbooks. Not a dump of every GitHub marketplace item. The public repo captures that shape for attendees who want templates, plus a handful of demo scenarios in docs/ — we only ran part of them live; the rest are there as food for thought if you clone it on your own time. Your org’s real branching, environments, and release flow belong in your own AGENTS.md, not in a conference clone.
If prompts live only on your laptop, you are not doing platform engineering; you are doing performance art.
Token pragmatism (without the sermon)
A few operational habits from the Q&A slice of the deck, as few people had further questions about it:
Default model selection does not have to track every launch tweet. “Auto” or mid-tier models handle most DevOps investigation; reach for the expensive tier when the plan is approved and the task is genuinely gnarly. Re-read what actually landed in context — repeated full-repo scans are how budgets die. If the agent keeps rewriting the same helper script, ask it to save the script and point AGENTS.md at it. If it ingests a huge PDF once, store a summary markdown and tell future sessions to read the summary first.
You don’t need Claude Opus 4.8 or Fable for every small query - unless you want to wake up on 3rd of the month reaching the limit of your license (if you are reading it my dear collegaue, yes it’s about you - start using cheaper models!).
What the repo is for
The GitHub materials are templates and config samples for the webinar audience — MCP JSON, instruction stubs, workspace layout ideas. They are anonymised stubs, not a production system to deploy or a reference implementation of any live engagement.
So, in case you would like to review the materials, here they are:
The post above should be enough if you only care about the written summary.
For the viewers of the webinar I left the homework that is small and unglamorous: one AGENTS.md in a repo your team touches every week, one shared config repo (even if it is only instructions and MCP templates at first), one workflow that uses Plan mode before pipeline edits — and MCP read-only so the agent sees your world instead of hallucinating it. Async agents and “software factory” hype can wait until that baseline is boring enough that juniors use it without you in the room.
That is the same lesson I keep learning on the infrastructure side: the exciting layer is only as good as the boring layer underneath. AI tooling is not an exception.