Scott Hanselman’s Microsoft Build demo showed a better way to code with AI: start weird, stay grounded, review everything, and turn useful AI work into reusable tools.
The loudest narrative around AI coding right now looks like a tokenmaxxing scoreboard: tokens burned, pull requests opened, commits shipped, leaderboard screenshots posted.
Scott Hanselman’s version starts with a better question: what problem does a human actually want to solve?
In this Microsoft Build 2026 livestream with Corey Noles, Hanselman walks through his real development setup, his GitHub Copilot workflow, Windows Terminal, some cool demos like Tiny Tool Town, how he uses GitHub Actions workflows, and a live experiment that connects Copilot to his blood sugar data.
Scott Hanselman is one of the rare people who can explain software to beginners without making them feel like they missed a prerequisite course in 2007.
Scott is a developer, teacher, speaker, author, longtime podcaster, and VP / Member of Technical Staff at Microsoft and GitHub, where he works on open source, Windows developer tools, and agentic coding tools like GitHub Copilot.
His takeaway point from this stream is simple: AI can help you build faster, but speed only helps when the loop still includes taste, tests, review, grounding, and human judgment.
Hanselman opens with the thing everyone feels right now: AI coding tools are powerful enough to change the way software gets made.
At (1:08), he says he wants to spend the next “thousand days” teaching AI-augmented software engineering. At (1:23), he calls AI a “freaking chainsaw.”
A chainsaw makes the work faster. It also makes mistakes louder.
AI-augmented software engineering means using AI inside the real software workflow: planning, coding, testing, reviewing, shipping, and maintaining. Vibe coding means prompting an AI tool to build software quickly from plain-language instructions.
Vibe coding is great for exploration. The upgrade is putting it inside a process that can survive contact with users.
At (4:36), Hanselman pushes back on token leaderboards and “token maxing.” Burning more tokens can look productive while the actual work stands still.
He cares less about pull request count, commit count, lines of code, and token volume. He cares about the user story that moved.
That distinction matters because AI makes motion cheap. You can generate ten branches, five prototypes, and a pile of code before lunch. The work starts counting when a human problem gets smaller.
Hanselman’s Hansel Projects dashboard, shown around (5:09), adds a more human operating system. It looks across his projects and helps him choose work based on energy and emotional state.
Some days are good for pull requests. Some days are good for one hard problem. Some days are good for small automations.
AI can accelerate the work. The human still chooses the work worth doing.
At (3:13), Hanselman talks about containers, pull requests, and multiple Copilots running in parallel. At (3:21), he says three to five Git worktrees is probably the sweet spot.
GitHub is a place where people store code, track changes, discuss bugs, review updates, and ship software together. A repository, or repo, is a project folder tracked by GitHub. A pull request, or PR, is a proposed change to the code.
A diff shows exactly what changed. A Git worktree gives you another working copy of the same project, so separate changes can stay separate.
That setup keeps AI work visible. One agent can try one path. Another can try another. The human compares the results, reads the diff, and decides what survives.
The practical rule: ask AI to build one change at a time. Keep each change separate. Review the diff before accepting it.
At (7:34), Hanselman shows an “emoji bake” fix. Emoji bake happens when text encoding breaks and turns an emoji or Chinese character into several stray ASCII characters.
The fix is only half the story.
At (8:15), his teammate adds 188 lines of tests so the same bug stays fixed. At (8:18), Hanselman says his job is reading PRs, looking at issues, and applying code smell.
Code smell means something in the code feels suspicious. The code might run today while its structure hints at future bugs, complexity, or maintenance pain.
Automated tests are code that checks other code. A good test catches the same bug if it returns later.
Use AI to fix the bug. Then use AI to write tests that would have caught it.
You just fixed this bug. Now write tests that would fail before the fix and pass after it. Then explain each test in plain language, including what case it protects against.
At (12:47), Hanselman says AI is good at making features and weaker at making architecture.
Features are local. Architecture is the shape of the system.
A model can add a button, create a form, write a script, or implement a helper function. Architecture asks a larger question: how should this whole thing fit together so the next change still makes sense?
Hanselman steers with documentation. At (13:03), he describes writing docs for how localization should work, then checking PRs against those docs.
Architecture documentation is a short set of rules for the project. It can describe:
A file called ARCHITECTURE.md gives the AI something stable to obey. Without that, it solves the immediate request in whatever way seems plausible.
Hanselman’s Tiny Tool Town demo starts from a small, weird place.
At (13:29), he talks about Baby Smash, a silly game he made for his kid. Then it got hundreds of thousands of users. At (14:01), he introduces Tiny Tool Town, a homepage for small tools made for an audience of one.
That shape works: small enough to finish, specific enough to care about, weird enough to keep going, real enough to force decisions.
Tiny Tool Town includes coloring tools, terminal utilities, custom pages, light mode, dark mode, and Geocities mode at (16:08).
Geocities mode is the joke. The lesson is the permission structure. People learn faster when the project feels like theirs.
Corey makes that connection at (17:25). Early web development often started with “I need to do this thing.” Then people learned HTML snippets, links, images, and little pieces of code because the project demanded them.
AI brings back that path. Make the thing. Ask why it works. Follow the next layer down.
At (14:55), Hanselman shows Tiny Tool Town submissions happening through GitHub issues. Then he says the line that explains the whole architecture: “There’s no database. The database is GitHub.”
At (20:37), he says every project does not need Supabase or Cosmos DB. Tiny Tool Town runs on GitHub Pages, Astro, and a giant JSON file.
JSON is a common text format for storing structured data. It uses names and values, like title, url, and description. XML is an older structured text format. Hanselman’s blog uses one XML file per post.
At (21:45), he says his 24-year blog is 5,300 XML files in a folder. At (22:28), he says 22 years of writing fits into about 300 MB of memory.
Many apps need structured data long before they need a real database.
Start with a JSON file, a spreadsheet, a Notion database, or GitHub issues. Upgrade when the project proves it needs more.
Tiny Tool Town gets more useful when submissions arrive.
At (15:20), Hanselman shows a GitHub workflow that checks new tools, looks at stars, detects whether the submitter is a bot, and generates summaries.
At (18:22), he runs a triage skill that checks for duplicates, license, images, commercial submissions, and fit.
Then he gives the operating move at (18:46): ask the AI for its confidence and make it explain why.
He adds the next piece at (19:04): give it your own rubric.
A rubric is a scoring guide. It tells the AI what “good” means for this project.
For Tiny Tool Town, a rubric might check whether a submission has:
At (19:44), Hanselman keeps the boundary clean. The agent tags and triages. A human approves.
The Nightscout demo turns the workflow into personal software.
At (24:22), Hanselman says he logs into interfaces less and asks agents to do things through APIs more.
An API is an interface that lets software talk to software. A REST API is a common web-style API where a URL returns data or performs an action. A skill is a packaged set of instructions, scripts, or tools that teaches an AI assistant how to do a repeatable task.
At (25:54), Hanselman explains that he has Type 1 diabetes. He has an insulin pump in one arm and a sensor in the other. At (26:28), he explains the open-source artificial pancreas community, Loop, and Nightscout.
A CGM, or continuous glucose monitor, reads blood sugar every few minutes.
At (27:18), he realizes he has a REST API and can turn it into a skill. Then at (27:39), he dictates the instruction to Copilot:
Take this GitHub repository. It has a skill. Bring the skill down, install it, ask me what you need to ask me, and then we’re going to check my blood sugar.
If your data has an API, your AI assistant can help you build a tool around it.
For a first pass, use safe, non-sensitive data: weather, reading lists, invoices, workout logs, task lists, or public spreadsheets. Medical and financial data raise the stakes fast.
Hanselman uses dictation because of hand surgeries. At (27:57), he mentions voice options, including Windows dictation and voice in GitHub Copilot.
AI coding is becoming multimodal in ordinary ways. You can type a prompt, speak a prompt, review files visually, ask for a diagram, use a terminal, or use a graphical app.
At (31:53), Hanselman says command-line intimidation is fine. If you prefer the GitHub Copilot app, you can open the same folder graphically.
A terminal is a text-based place to run commands. PowerShell, Bash, and ZSH are command-line shells. They receive commands and run programs. A TUI, or text user interface, is a visual interface that runs inside the terminal.
Use the interface that lets you understand the work. Then learn one layer deeper when the moment calls for it.
When Hanselman switches to dictation, he casually drops the important part: the voice system happens locally. Your personal voice does not need to stream to someone else’s server just to become text.
The two NVIDIA model families to know here are Parakeet and Nemotron Speech.
Parakeet Unified English 0.6B is the easiest place to start. It turns speech into text, supports punctuation and capitalization, and can run in offline mode for normal transcription or streaming mode for live voice input.
Nemotron Speech Streaming 0.6B is built for the low-latency case: voice agents, live captions, and interruptible conversations where the system needs to hear you while you are still talking.
Both run through NVIDIA NeMo, NVIDIA’s open framework for speech and multimodal models.
Use this when you have an audio file and want a transcript.
python -m venv .venvsource .venv/bin/activatesudo apt-get update && sudo apt-get install -y libsndfile1 ffmpegpip install Cython packagingpip install "git+https://github.com/NVIDIA/NeMo.git@main#egg=nemo_toolkit[asr]"
Then save this as transcribe_parakeet.py:
import nemo.collections.asr as nemo_asrasr_model = nemo_asr.models.ASRModel.from_pretrained( model_name="nvidia/parakeet-unified-en-0.6b")output = asr_model.transcribe(["audio.wav"])print(output[0].text)
Run it:
python transcribe_parakeet.py
That gives you the basic version of Scott’s workflow: speak, transcribe locally, then send the text into Copilot, Codex, Claude Code, or whatever agent you are steering.
Use this when the timing matters. Parakeet is great for normal transcription. Nemotron Speech Streaming is the model to test when you want something closer to live voice control.
Install the same NeMo stack, then test a whole-file transcription first:
import nemo.collections.asr as nemo_asrasr_model = nemo_asr.models.ASRModel.from_pretrained( model_name="nvidia/nemotron-speech-streaming-en-0.6b")output = asr_model.transcribe(["audio.wav"])print(output[0].text)
For real streaming, clone NeMo and use NVIDIA’s cache-aware streaming script:
git clone https://github.com/NVIDIA-NeMo/NeMo.gitcd NeMopython examples/asr/asr_cache_aware_streaming/speech_to_text_cache_aware_streaming_infer.py \ model_path= dataset_manifest= batch_size=1 \ att_context_size="[70,13]" \ output_path=outputs/
The important knob is att_context_size. It controls the latency tradeoff. Smaller right context gives faster responses. Larger right context gives the model more audio to work with, which usually improves accuracy.
For a voice-agent experiment, start with the safer setting:
att_context_size="[70,13]"
Then try lower-latency settings as the demo gets stable:
att_context_size="[70,6]"att_context_size="[70,1]"att_context_size="[70,0]"
This is the same idea as Scott’s broader workflow: start with the working version, then tighten the loop.
Once local speech-to-text works, voice becomes another input layer for the agent.
You can say:
Open the repo, read the failing test, explain the error in plain English, then propose the smallest fix.
Or:
Review the diff in this pull request and tell me what looks risky before I merge it.
Or:
Take this messy voice note, turn it into an issue, add acceptance criteria, and suggest the first implementation step.
That is the practical version of Scott’s point. Voice removes friction from the prompt. Local ASR keeps the input closer to your machine. The agent still needs the same engineering guardrails: tests, docs, diffs, and human review.
Side note: NVIDIA, you need a desktop app to run these models for beginners to use! I'm willing to bet y'all could vibe-code something... just saying...
At (30:30), Hanselman asks Copilot to check whether his blood sugar suggests he was stressed on stage.
Then he changes the request while talking. He moves from a simple chart or Markdown file to a “cool local website report.” Corey points out at (31:01) that the extra context helps.
Treat the first prompt as the start of the conversation. Add constraints. Explain how you will use the output. Change your mind out loud.
At (32:32), Copilot says it is writing a single self-contained local HTML report.
At (32:44), Hanselman names the pattern: just-in-time UI generation.
Just-in-time UI generation means creating the interface when you need it, shaped around the task in front of you. Instead of opening a dashboard someone designed months ago, you ask for the exact report, chart, or page the question requires.
At (33:51), the report lands: “maybe a stage adrenaline bump,” with a chart showing his blood sugar rose during the stage window and fell later.
The loop is simple:
At (34:59), Hanselman says tools can be reused. At (35:10), he gives the rule:
If this doesn’t need to be an LLM anymore, I need to move it immediately into a Python script.
LLMs are useful for ambiguity. Scripts are useful for repeatability. Once the steps are clear, move the stable pieces out of the fuzzy reasoning layer and into deterministic code.
Deterministic means the same input should produce the same output every time.
Use the AI to discover the workflow. Then ask it to turn the stable parts into a script.
This workflow now works. Identify which parts still require judgment and which parts are repeatable. Convert the repeatable parts into a script. Keep the judgment steps as clear checkpoints for a human.
The Nightscout report only matters if the numbers are real.
At (36:19), Hanselman shows that the data came from JSON pulled from the API. At (36:36), he checks the current serum glucose value against the command line.
Grounding means connecting the AI’s answer to a real source of truth: a file, database, API, document, or live system.
Then he shows the opposite.
At (38:18), he demos a local chatbot completing a sentence with probabilities. “Park” and “beach” are plausible because language models predict likely next words.
At (38:48), he adds context about being from Portland, his dad being a firefighter, and his mom being a zookeeper. The model follows that context to “zoo.”
At (39:15), he says these systems are improv partners, not fact machines.
Then he asks for his own birthday at (39:40). The model gets it wrong. When he tells it to try again, it keeps making things up.
Use the model for brainstorming. Use grounding for facts. Use verification when the cost of being wrong is high.
Corey asks what someone should learn if AI brought them into coding.
Hanselman answers with a driving analogy at (41:38). His dad made him learn to change oil, change a tire, and drive stick shift before driving.
Then he adds the balance at (41:47). Requiring assembler, C, and years of prerequisites puts a wall in front of creativity.
Start where you are, then pop the hood one level deeper.
At (42:10), he tells people to learn HTTP, DNS, JSON, and the basics.
HTTP is the protocol browsers and servers use to send webpages and data back and forth. DNS is the internet’s address book. It turns a name like example.com into the server address your computer needs. Localhost means a server running on your own computer.
Corey describes his learning loop at (42:24): build something with AI, then ask another AI to walk through how it works.
Hanselman sharpens that at (43:04): make junior engineer specific docs. Ask for diagrams. Interview the code.
Explain this code as if I am a junior engineer joining the project today. Start with what problem it solves, then draw the data flow in words, then explain the key files, then list what I should learn next.
Interview this codebase. Ask the code what it was designed to do, what assumptions it makes, where it is fragile, what inputs it expects, and what would break if the project grew 10x.
Make the thing. Understand the thing. Then use that understanding to make the next thing less mysterious.
Hanselman’s workflow reduces cleanly:
Vibe coding gives people a reason to learn. A person who would never finish a textbook chapter on HTML might spend three hours getting a weird personal tool to work.
That energy is useful. It also needs a path.
Hanselman’s demos show the path from prototype to practice: small projects, simple architecture, AI help, human review, tests, docs, grounded data, and repeatable scripts.
The open question is whether coding tools will make that path feel natural. The industry loves screenshots, demos, and activity metrics because they are easy to celebrate. The craft lives in quieter places: the diff, the test, the doc, the rollback plan, and the moment a human says, “I understand why this works.”
That is the real shift. AI coding makes software easier to start. AI-augmented software engineering makes it easier to keep up.
Grant Harvey is the Lead Writer of The Neuron, where he continues to lead the publication's daily coverage of AI news, tools, and trends.
Don't fall behind on AI. Get the AI trends & tools you need to know. Join 700,000+ professionals from top companies like Microsoft, Apple, Salesforce and more.
Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved
Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.
