Session: Scott and Mark learn... how agents reshape software engineering | BRK247

Microsoft Build 2026 featured an unusual breakout session: Mark and Scott — not next-gen engineers, but seasoned practitioners — showed live how they work with Claude on real technical challenges. What I saw, I recognized immediately.

The gap nobody talks about out loud

There is a significant leap from vibe-coded solo software to skilled engineering at world scale. AI makes it tempting to ignore that gap. You type a prompt, code rolls out, and it seems to work. But seems to work is not the same as works correctly under load, in production, across multiple teams.

Mark and Scott illustrated this honestly. What sets them apart is not speed or hype — it is deep domain knowledge, a sharp eye for when Claude goes wrong, and the discipline to stop and steer before things go off the rails.

What Mark managed to build

With careful guidance, Mark delivered two impressive things:

gRPC Shared Memory

When two gRPC processes run on the same machine, there is no reason to communicate over TCP or Unix sockets. Serialization across the network costs time and CPU. With shared memory, you can eliminate that overhead entirely.

Mark delivered a working implementation for both Go and .NET — two ecosystems, one concept, significant performance gains. This is not a hello-world demo. This is the kind of optimization that makes a difference in production systems.

Scrolling screenshots in ZoomIt

In his spare time, Mark added a scrolling screenshot feature to ZoomIt, the well-known Sysinternals tool by Mark Russinovich. A small feature, but technically non-trivial — and a great example of what becomes possible when you use AI as a tool rather than a replacement.

The skill that deserves the most attention

The most interesting part of the session was not the code being written, but the process around it. Mark demonstrated how important it is to:

• Follow Claude's thinking process — not blindly accept what is being proposed
• Stop in time — as soon as Claude heads in the wrong direction, intervene before technical debt accumulates
• Steer with precision — not start over, but sharpen the context and guide Claude back on track

This is a skill in itself. And it is precisely the skill that juniors currently lack.

The problem with junior developers in the AI era

AI agents regularly do the wrong thing. Not always spectacularly wrong — sometimes subtly. A classic example that came up in the session: adding a sleep statement to fix a race condition.

This is the kind of solution that works in a demo and fails in production. A junior without sufficient context might accept it, because the tests go green. An experienced engineer sees it immediately: this is not a fix, this is hiding the problem.

The point is not that AI is bad. The point is that juniors today need more coaching than ever, not less. They are exposed to more code, more complexity, and more AI output that sounds convincing but can be structurally wrong. Without a strong technical mentor alongside them, the risk is high that they copy bad patterns without realizing it.

What this means for how we work

If you are using AI in your engineering organization — and you are, whether you realize it or not — these are the lessons from Build 2026:

1. Domain knowledge remains irreplaceable. Mark could only steer because he understood what the code was supposed to do.
2. Stop and reorient early. The further Claude heads in the wrong direction, the more expensive it is to come back.
3. Train juniors on the process, not just the output. Teach them to read Claude's reasoning, not just accept the code.
4. Sleep statements are a code smell, not a solution. If AI suggests this: stop, and analyze the underlying race condition.

Conclusion

Mark and Scott are seasoned engineers at the top of their craft. And that is exactly what makes this session stand out: instead of another AI hype demo, they show what it actually looks like to use AI responsibly as part of serious engineering.

The gap between vibe coding and world-scale engineering is real. AI does not make it smaller — AI makes it more visible. And the people who can bridge that gap are not those who write the fastest prompts. They are the ones who know when to intervene.

Based on the Microsoft Build 2026 breakout session: Scott and Mark learn... how agents reshape software engineering | BRK247

I built a small tool to do it for you — straight from a binary .plan file, with no terraform init, no provider plugins, and no terraform CLI required. It's on PyPI as generate-imports-from-plan.

The problem

Say you have a Terraform configuration that describes resources which already exist in Azure. You run a plan, and Terraform wants to create everything — because it doesn't know those resources are already there. The fix is to write an import {} block per resource:

import {
  to = module.core.azurerm_resource_group.this
  id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-myapp-dev-we-01"
}

For a handful of resources, fine. For a real environment with dozens of resource groups, networks, role assignments and Entra ID apps, doing this by hand is a long afternoon of copy-pasting IDs out of the portal.

The obvious idea is to script it from terraform show -json. But there's a catch.

Why terraform show -json isn't enough

terraform show -json <planfile> does not expose all planned attribute values. Computed fields — including things you need to build the resource ID, like the resource name or the resource group name — show up as "known after apply" and are simply absent from the JSON.

The values are in the plan, though. A .plan file is actually a ZIP containing:

• tfplan — the planned changes, as protobuf
• tfstate — the prior state
• tfconfig/ — the raw HCL of your configuration

Inside tfplan, attribute values are msgpack-encoded, and they include the computed values that the JSON view drops. So instead of going through terraform show, this tool reads the binary plan directly: unzip, parse the protobuf, decode the msgpack attributes. No provider plugins needed, because nothing is being evaluated — the values are already sitting in the plan.

How IDs get resolved

Azure resource IDs come in a few flavours, and the tool handles each differently:

1. Formula-based IDs. Most ARM resources have a deterministic ID you can assemble from their attributes — subscription, resource group, provider namespace, name. These are built from a formula and emitted immediately, no prompting.

2. Cross-plan IDs. Some resources have an ID that depends on another resource in the same plan — a subnet association needs the subnet ID, a DNS-servers resource needs the VNet ID. The tool reads the HCL references in tfconfig/ and derives those IDs from the sibling resource, again without any external calls.

3. Live IDs. A few resource types only get their ID assigned at creation time — Entra ID resources, Azure role assignments. For those, the tool calls the Azure CLI (az) to look up the real ID, and it shows you the exact command before running it.

There's one more nice detail: the correct subscription ID is determined per resource by following the azurerm provider chain through the config. A plan that spans multiple subscriptions gets the right subscription on each resource — no single global assumption.

Using it

The tool is published to PyPI, so the quickest path (nothing installed permanently) is uvx:

uvx generate-imports-from-plan terraform.plan > imports.tf

If you don't have uv, install it (pip install uv, or winget install astral-sh.uv on Windows), or install the tool directly with pip/pipx:

pipx install generate-imports-from-plan
generate-imports-from-plan terraform.plan > imports.tf

You'll need Python 3.11+ and — only for the live lookups — the Azure CLI.

The workflow

# 1. Generate the plan
terraform plan -out terraform.plan

# 2. Generate import blocks interactively
generate-imports-from-plan terraform.plan > imports.tf

# 3. Fill in any remaining placeholder IDs, then re-plan and apply
terraform plan -out terraform.plan
terraform apply terraform.plan

The tool is interactive and decides what to do per resource:

Use --yes to accept everything without prompting, or --no for a dry run.

Sample output:

import {
  to = module.core.azurerm_resource_group.this
  id = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-myapp-dev-we-01"
}

import {
  to = module.core.azuread_application.default["my-app"]
  id = "/applications/00000000-0000-0000-0000-000000000000"
}

# import not supported for azuread_application_password:
# module.core.azuread_application_password.default["my-app"]

Extending it

Adding support for a new resource type is usually a one-line formula. For example, in generate_imports/ids.py:

"azurerm_my_resource":
    lambda a, s: _arm(s, _str(a, "resource_group_name"),
                      "Microsoft.MyNamespace/myResources", _str(a, "name")),

For the trickier cases there are also cross-plan resolvers (derive an ID from a sibling resource) and live resolvers (az CLI). The repo's docs/resolvers.md walks through all three.

Links

• 📦 PyPI: generate-imports-from-plan
• 💻 Source & docs: github.com/cveld/terraform-importer

If you try it on your own environment, I'd love to hear which resource types you hit that aren't covered yet — issues and PRs are welcome.