I had the chance to speak twice at Prairie Dev Con Winnipeg 2026 — billed as the largest AI and software development conference on the Prairies, and after two days in the room, I believe it. 70+ sessions, six concurrent rooms, 50+ speakers, a keynote from Craig Shyjak (VP of Architecture, Laivly) on AI's role in software development, and a crowd that stuck around for sessions well past the point most conferences lose the room.
None of that happens without D'Arcy Lussier, who's been building Prairie Dev Con into one of the most consistent developer conferences on the Prairies for years. Organizing a two-day, six-track conference is unglamorous, relentless work — the kind nobody claps for until the room is full and the wifi works. D'Arcy, thank you for having me back.
What's Inside
- "The Agentic Shift" — a live vibe-coding demo, the catch nobody specifies, and why one agent on one platform beats five tools across three clouds
- The independent data behind it: adoption up, trust down, and Gartner's cancellation forecast
- "One File to Forty" — a real legacy .NET app, modernized live: SQL injection fixed, characterization tests, containerized, re-platformed to PostgreSQL
- Five failure patterns that burn the most engineering time, and the harness that stops each one
Talk One: The Agentic Shift
Everyone in the room had heard "vibe coding." Some are doing it, some are funding it, and most are somewhere between excited and quietly terrified about what it means for how software actually gets built. The talk's argument: vibe coding is the symptom. Agentic engineering — autonomous agents as first-class members of the team, not a feature you turned on — is the actual shift.
Four steps, live
The session ran on a live demo, not static slides — a plain-English brief turned into a working app called the Dinner Group Splitter, built in minutes. Then the catch: one harder requirement (live sync across devices) went in, the app kept working, and only then came the question nobody had written down anywhere — what happens on a server restart? Every room vanished. Not a bug in the tool. A consequence of skipping the spec.
"It didn't fail. It quietly made twenty decisions I never wrote down."
From there: containerizing the vibe-coded app locally with Podman — non-root, no secrets baked in, no cloud account needed — and finally orchestration: a plan subagent writing a real spec (with a security section) before anything gets built, then build and review subagents executing it autonomously, each in its own context window, with a human as the only box on the diagram that can say no.
That chain — plan, build, review — generalizes into something bigger: graph engineering, bounded-task nodes with real dependency edges and parallel fan-out, which is what Anthropic ships in Claude Code as "dynamic workflows." The real-world proof point: Bun 1.4's Zig-to-Rust rewrite — 535,496 lines across 1,448 files, ported in 11 days using up to 64 parallel agents for roughly $165K, every batch reviewed twice before merge. Fountain used the same orchestrator/specialist pattern to cut new-site staffing to under 72 hours. The honest caveat, from Anthropic's own research: in one test, 18 of 30 unmanaged agents independently named the identical git branch. A graph without a harness doesn't fail slower — it fails faster, together.
The numbers, from independent sources
This wasn't framed as opinion — three independent sources landing on the same gap:
| Metric | Then | Now |
|---|---|---|
| Code merged to Anthropic's own production codebase, written by Claude | Low single digits (Feb 2025) | 80% (May 2026) |
| Developer AI tool adoption (Stack Overflow) | 76% | 84% |
| Trust in AI-generated output (same survey) | 40% | 29% |
| Agentic AI projects Gartner predicts cancelled by 2027 | — | Over 40% |
Anthropic's own framing for the first row: a textbook example of Amdahl's law — the bottleneck didn't vanish, it moved to review. The scarce skill now isn't typing code; it's knowing when the output is wrong.
The market vote was just as pointed. SpaceX paid $60 billion for Cursor — the largest startup acquisition ever, closed August 2026. In the same six months, Cursor's own developer adoption fell from 18% to 12% (JetBrains Developer Ecosystem Survey, 15,000+ professional developers). Claude Code sits at 39% globally, 47% in the US, with zero acquisition headlines. Valuation is a bet on the future; adoption is a vote happening right now — and they didn't agree.
The investment framework that falls out of this: hedging across five tools and three clouds isn't the safe bet, because nobody's actually watching all of it. One agent on one platform means a small team can watch everything — that's not caution, it's the only way real oversight is possible at all.
A 90-day starting point
- Days 1–30 — pick one real workflow, put an agent on it, stand up the harness basics: a
CLAUDE.md, a first hook. - Days 31–60 — expand to a second team, turn what worked into shared Skills and MCP servers instead of tribal knowledge.
- Days 61–90 — measure, cut what isn't earning its keep, standardize the harness across teams.
Infrastructure, not a trend
A few data points that moved this from "interesting tool" to "infrastructure" in the space of a year: MCP was donated to the Linux Foundation in December 2025, no longer Anthropic's to control. SKILL.md has been open since the same month and now runs on 27+ tools, including Copilot, Codex, and Gemini CLI. And in August 2026, six companies — OpenAI, AWS, Microsoft, GitHub, Cursor, Vercel, and Google — standardized Agent Plugins 1.0, packaging Anthropic's own Skills and MCP work, without Anthropic in the room. When rivals formalize the same skill and jointly govern the standard it runs on, that's not a trend anymore.
The closing argument is one I'd make to any engineering team today: agents work the way Unix always has — shell, files, processes, pipes. A terminal-first setup is composable in exactly the way agentic tooling expects; GUI-heavy, point-and-click workflows fight it at every step. Serious money agrees — DHH's Omacom Foundation, launched to fund Omarchy's development, raised $12.6M in under two weeks in August 2026, with $1M founding patrons including Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell, Jack Dorsey (Block), Matthew Prince (Cloudflare), and Jason Fried (37signals). If you want to feel the difference yourself this weekend rather than take my word for it, Omarchy gets you to a fully configured, terminal-first machine in one command.
The tools are ready. Is your team? The exact brief, the ship-it steps, and the slides are public alongside Talk Two's demo: github.com/codetocloudorg/prairie-dev-con-2026-talks.
Talk Two: One File to Forty
Legacy modernization isn't a one-time cost — it's a monthly bill. Windows Server, IIS, licensed SQL Server, billed every month for an app nobody wants to touch. This talk didn't argue that point. It modernized a real app live to prove it.
This isn't hypothetical at scale, either — the Government of Alberta is already doing exactly this. Their published case study with Anthropic (July 2026) reports 466 million lines of government code reviewed in 20 hours against an estimated 6.5 years by hand, one ministry consolidating 185 legacy applications down to 16, and a 25-year-old Java subsidy portal — five months to build originally — rebuilt in four to five days. It's the same order-of-magnitude story Deputy Minister Janak Alford described directly when I spoke with him about Alberta's AI transformation. What we were about to do to one small app, live, on a conference stage, was the same motion at a much smaller scale.
Meet the patient
Prairie Ledger is a real, seeded internal expense-report tool — Bootstrap 3, from a CDN, exactly as dated as it looks — running on localhost for the whole room to see. Reading the actual codebase surfaced real problems, not staged ones: a SQL injection in the search box (string-concatenated queries, not parameterized), a hardcoded database connection string committed to appsettings.json, the app connecting to the database as sa instead of a scoped account, no CSRF protection on the forms, and an out-of-support .NET 6 runtime with zero tests, no container, and no pipeline.
Seven steps, one file to forty
| Step | What happened |
|---|---|
| 1. Read | Claude Code ingests the legacy repo cold, on stage, and drafts a modernization spec — security section included |
| 2. Approve | A human reviews the plan in Plan Mode. Nothing executes until it's signed off |
| 3. Net | The agent writes characterization tests against current behavior first — the safety net, before any refactor |
| 4. Containerize | A Dockerfile is written; the app runs in a container for the first time in its life |
| 5. Pipeline | CI/CD stood up with blocking security gates — secret scan, SAST, dependency scan, image scan. A red gate stops the deploy |
| 6. Re-platform | The database moves off licensed SQL Server onto PostgreSQL; the app keeps its shape — same screens, same data — while the ground underneath it changes |
| 7. Scale | The remaining mechanical changes run live and unattended across the rest of the codebase, while we talked through where this kind of loop actually breaks |
We opened cold on a single file. We closed with a migration touching roughly forty files in total once every category of change — controllers and views for the framework bump, a Dockerfile and CI config that didn't exist before, characterization tests, and per-environment config — was counted. Verified against the fully built result: 20 of 20 tests passing (the original 17 plus 3 new ones), the exact SQL injection payload that used to leak every report now returns nothing, the container runs as an ordinary user rather than root, and dependency scanning turned up zero known-vulnerable packages.
The honest part: five failure patterns
The real lesson isn't the demo — it's harness engineering: the guardrails, context files, hooks, and permissions that separate an impressive demo from something you'd trust near production.
| Failure pattern | What stops it |
|---|---|
| No spec → scope creep | A Plan Mode approval gate |
| No safety net → silent regression | Characterization tests, written before any refactor |
| Vague tool descriptions → hallucinated destructive calls | Tight MCP tool descriptions and read-only credentials |
| Unbounded permissions → unauthorized actions | Pre-tool-use hooks and scoped credentials |
| Context loss on long runs → self-contradiction | Progress-file checkpointing and git history |
That's the same discipline behind everything we've written about running agentic AI at enterprise scale and containerization and app modernization on Azure — the pattern holds whether the room is a conference ballroom or a production rollout. The agent that wrote the pipeline doesn't get to grade its own work; the gates do. And a harness is also what it refuses to decide on its own — adding authentication to Prairie Ledger was flagged as a decision only a human should make, not something quietly folded into the migration.
Spec first. Human approval. Then execution. The opposite of vibe coding.
The demo ran in Claude Code, with integrations on MCP — an open protocol you can audit and check into source control, not a black box you have to trust. Per the talk's own closing line, the full spec, both apps, and the reusable harness plugin are now public: github.com/codetocloudorg/prairie-dev-con-2026-talks.
What This Adds Up To
Two talks, one underlying argument: the tools for agentic engineering are real and available today, but the thing that actually determines whether they help you or burn your quarter is the harness around them — the specs, the approval gates, the guardrails — not the model. That's the same principle behind every governed agent platform we build at Code To Cloud, just demonstrated live instead of described in a deck.
If your team is deciding what to actually do about agentic AI right now rather than just talking about it, that's exactly the conversation we have on the Agentic DevOps page — or take the 5-minute readiness scorecard first if you want a quick read on where you stand before you talk to anyone.
Thanks again to D'Arcy Lussier and everyone at Prairie Dev Con for having me back — already looking forward to the next one.
Kevin Evans
Fractional CTO & Founder, Code To Cloud Inc.
Kevin Evans is a fractional CTO and technology advisor based in Calgary, Alberta. He spent nearly five years at Microsoft — rising to Senior Solutions Engineer — leading cloud and AI platform strategy, and now leads enterprise and mid-market engagements at Code To Cloud. More about Kevin
Frequently Asked Questions
What is Prairie Dev Con?
Prairie Dev Con is billed as the largest AI and software development conference on the Canadian Prairies. The Winnipeg 2026 edition ran September 21–22 at the Canad Inns Destination Centre Polo Park, with 70+ sessions across six concurrent rooms and 50+ speakers from industry and enterprise backgrounds.
Who organizes Prairie Dev Con?
Prairie Dev Con is run by D'Arcy Lussier Enterprises Ltd., with D'Arcy Lussier as the conference's organizer and primary point of contact. D'Arcy has been organizing Prairie Dev Con events across the Prairies for years, building one of the region's most consistent developer conferences from the ground up.
What was "The Agentic Shift" talk about?
It used a live vibe-coding demo as the entry point into a bigger argument: the real shift in 2026 is from AI-assisted development to genuinely agentic engineering, where autonomous agents act as first-class members of the team. The talk covered why one agent on one platform beats five tools across three clouds, a 90-day starting point for teams, and independent data (Stack Overflow, Gartner, JetBrains) on the gap between AI adoption and trust.
What did the "One File to Forty" talk demonstrate?
A live, on-stage modernization of Prairie Ledger, a real legacy .NET 6 expense-report app running on Windows Server, IIS, and licensed SQL Server, with a genuine SQL injection vulnerability. An agent read the codebase, drafted a modernization spec with a security section, waited for human approval in Plan Mode, then executed — characterization tests first, then containerization, a CI/CD pipeline with blocking security gates, and a re-platform to PostgreSQL.
What is "harness engineering"?
Harness engineering is the discipline of building the guardrails around an AI agent — hooks, scoped credentials, approval gates, and progress checkpoints — that separate an impressive demo from something you'd trust near production. The talk's five failure patterns (no spec, no safety net, vague tool descriptions, unbounded permissions, context loss on long runs) are what a harness is built to stop.
Is the Government of Alberta application-modernization data in this post independently verified?
It's a real, published case study — Government of Alberta and Anthropic, July 2026 — not a Code To Cloud claim. We've cross-checked the headline figures (466 million lines reviewed in 20 hours versus an estimated 6.5 years by hand; one ministry consolidating 185 legacy applications to 16) against the primary source, and we're not repeating the unrelated dollar-figure claim that only appears in secondary coverage.
