Workshop Notes — Keno Vigil

Agentic Software Engineering: What Changes When Agents Do the Implementation

Mon, 07 Sep 2026 08:37:00 GMT

Agentic software engineering is what changes when an AI system doesn't just suggest code but runs the loop itself: reading a task, writing the implementation, running it, checking the result, and deciding what to do next, with a person setting the boundaries instead of typing every line. As of September 2026, the shift isn't about the model getting smarter. It's about four jobs moving to a different owner: the spec has to be precise enough for a machine to execute without asking a follow-up question, someone has to orchestrate which agent does what and in what order, verification has to happen on code nobody personally wrote, and accountability for what ships still has to land on a person, not the tool that typed it.

What is agentic software engineering?

Agentic software engineering is the practice of building software where an AI system runs an autonomous loop, deciding an action, executing it, checking the result, and repeating, to implement code rather than only suggesting it one line at a time. A person still defines the task, the constraints, and what counts as done.

The clearest definition I've found for what actually counts as "agentic" comes from Simon Willison, a developer well known for tracking this space closely: an agent is a system that runs a loop of deciding an action, taking it, and checking the result, repeating until the job is done or it gives up. That loop, not the size of the model behind it, is what separates an agentic coding tool from an autocomplete-flavored assistant. Tools like GitHub Copilot started on the assistant end of that line, finishing a line you were already typing. Tools like Cursor and Claude Code can sit further along it, taking a task, editing multiple files, running the tests, and iterating on the failures without you approving every intermediate step. This is the mechanism behind the shift I wrote about in Will AI Replace Software Engineers in 2026?: it's not that a smarter model replaces the engineer, it's that the loop moves from human-typed to agent-run, and the job becomes running that loop well.

How is agentic software engineering different from AI-assisted development?

AI-assisted development keeps a person driving: they write most of the code and use AI for suggestions, boilerplate, or explanations, staying in the editor the whole time. Agentic software engineering hands the driving to the agent for a bounded task, and the person's job moves to setting up that task and checking the result.

Here's the comparison I actually walk a team through when someone asks whether we're "doing AI" or "doing agents," because the two get treated as the same thing and they aren't:

Question	AI-assisted development	Agentic software engineering
Who writes each line of code	The developer, with suggestions from the tool	The agent, inside boundaries the developer set
Where your attention goes	The code as it's typed	The task definition and the finished diff
What has to be specified upfront	Not much: you can course-correct line by line	Acceptance criteria and edge cases, before the agent starts
How a mistake surfaces	Usually right away, mid-keystroke	After the agent finishes, in review or in tests
Who is accountable for what ships	The developer, by default	The developer, by explicit decision, named rather than assumed

Neither column is the "better" way to build software. In my experience, most real work still sits in the assisted column, and it should: a lot of engineering is small, contextual, and faster to just type than to specify. The agentic column earns its keep on bounded, well-defined tasks, a migration script, a test suite for an existing module, a defined feature with a clear spec, where the cost of writing a precise task description is lower than the cost of typing the implementation by hand.

What changes about specification when an agent writes the implementation?

A spec written for a human engineer can lean on shared context and a follow-up conversation to fill gaps. A spec handed to an agent has to state the acceptance criteria, edge cases, and constraints up front, because the agent will execute exactly what's written rather than pause to ask a clarifying question the way a teammate would.

I've watched this go wrong the same way more than once: a task description that would have been perfectly fine handed to a mid-level engineer, because that engineer would ask "wait, what should happen if the input is empty?" before writing a line, produces confidently wrong code from an agent that just picks an answer and moves on. The gap isn't intelligence. It's that a person absorbs a hallway conversation's worth of unstated context, and an agent only has what's in the prompt and the repository in front of it. The honest fix is unglamorous: write down the edge cases, the acceptance criteria, and the definition of done before the agent starts, the same discipline behind test-first and behavior-first specification, just enforced earlier and more literally than it used to be.

Who orchestrates the work once an agent is doing the typing?

Orchestration becomes a named job once agents do the implementation: someone has to decide which task goes to which agent, in what order, and what happens when one agent's output feeds the next step. That job used to live implicitly in whoever picked up the ticket; with agents it has to be explicit or the work stalls or duplicates.

One thing nobody talks about enough: a single agent working one task at a time doesn't need much orchestration, you just wait for it to finish. The job shows up the moment more than one task is in flight, because agents don't naturally know that the database migration another agent is writing needs to land before the feature branch that depends on it. On a small team, this can be one person's judgment call, made explicitly instead of assumed. On a larger one, it starts to look like planning work that used to be distributed across a team's shared understanding of the codebase, now concentrated into whoever is sequencing the agents. The same bounded-pilot discipline I laid out in an AI adoption framework, start small, prove workflow fit, then scale, is the safest way I've found to hand a team its first orchestration job instead of turning every agent loose on the backlog at once.

How do you verify code that no person on the team actually wrote?

You verify it the same way you'd verify code from a contractor you've never met: tests that actually exercise the behavior, a human review focused on the decisions rather than the syntax, and running it against real data before it reaches production. The agent's confidence in its own output is not evidence; the tests and the review are.

The honest answer is that this shifts what review time is for. Reviewing a human teammate's pull request, you're often catching style, naming, and small logic slips, because you trust they understood the problem the way the team understands it. Reviewing an agent's diff, the style is usually fine and consistent; what needs checking is whether it solved the right problem, handled the edge cases the spec actually named, and didn't quietly change behavior somewhere the diff doesn't draw your eye to. That's a different skill than line-by-line code review, closer to auditing a decision than proofreading a paragraph.

Who is accountable when an agentic system ships a bug?

The person who approved the change is accountable, the same as if they had merged a junior engineer's pull request without reading it. An agent can draft the fix, but a name has to be attached to the decision to ship it, or accountability quietly disappears the moment something breaks in production.

I spent years leading engineering through acquisitions inside a regulated clinical research organization, where "who approved this and on what evidence" wasn't a philosophical question, it was an audit question with a real answer expected. That habit is the one I'd bring into agentic work before any other: the agent can write the code, but the merge, the deploy, and the decision to trust the tests still belong to a person whose name is on the approval. It depends, but in every version I've seen work, the team that kept a clear, boring answer to "who approved this" was the one that could actually use agents for more of the implementation over time, not less, because nobody was quietly hoping the tool would absorb the blame if something went wrong.

AI Product Strategy: Start With the Decision, Not the Model

Fri, 04 Sep 2026 08:39:00 GMT

An AI product strategy is the portfolio-level decision about where AI investment can build a durable advantage in a product, and where it's a commodity everyone can buy the same way, made before any single feature or rollout gets funded. As of September 2026, after 15 years leading product and engineering teams, including through eight acquisitions inside a regulated clinical research organization, I keep seeing companies confuse this with a features list: a slide of things AI could do, ranked by how impressive the demo looks. That's not a strategy. A strategy says which parts of the roadmap AI is even allowed to touch this year, and why those parts and not the others, before anyone opens a chat window to check what's possible.

What is AI product strategy?

AI product strategy is the decision about which parts of a product roadmap deserve AI investment, and which don't, made at the portfolio level before any single feature is scoped. It answers where AI can build a durable advantage versus where it's a commodity anyone with API access can copy by next quarter.

I've sat through this pitch a dozen ways over eight acquisitions and as many product reviews: a target company or an internal team has a list of things AI could plausibly help with, and the strategy conversation stops at ranking the list. What's usually missing is the harder question underneath: which of these would still matter if a competitor stood up the same model in a weekend? A roadmap has room for both kinds of ideas. Conflating them is how a company spends its differentiation budget on something anyone can buy off the shelf, and calls the receipt a strategy.

How is AI product strategy different from an AI adoption framework?

An AI product strategy decides whether AI belongs on the roadmap at all and where. An AI adoption framework decides how a tool that's already been chosen moves from a bounded pilot to full rollout inside one team. Strategy picks the arena. Adoption runs the sequence once you're standing in it.

I wrote the five-stage version of that sequence, readiness, a bounded pilot, workflow fit, evidence, scale, in an AI adoption framework. That framework assumes the arena question is already settled: someone has decided this team, this workflow, is worth testing a tool against. Strategy is the layer above it. It's where a company decides which two or three workflows across the whole roadmap are even candidates for that framework this year, and which aren't, no matter how enthusiastic the internal pitch is. Skip straight to adoption without a strategy first, and a company ends up running five bounded pilots in five unrelated corners of the business, none of them chosen because they mattered more than the ones that never got tried.

How is AI product strategy different from AI product discovery?

AI product discovery tests one feature-level decision: whether a real user pain, real data, an acceptable risk, and workflow fit line up for a specific idea. AI product strategy decides which decisions are even worth putting through that test, and in what order, based on where the company already holds an advantage a competitor can't copy quickly.

I laid out the four discovery checks, pain, data, risk, workflow fit, in AI product discovery. Every one of those checks assumes you already know which feature you're testing. Strategy is what decides that queue. Without it, discovery turns into first-come-first-served: whoever pitches loudest gets tested first, and the team spends a quarter validating something that was never going to be defensible even if every check passed. Strategy doesn't replace discovery. It decides which ideas earn a discovery cycle before a model ever gets picked.

Where does AI actually create a durable advantage in a product?

A durable advantage shows up where a company holds data, a workflow, or a cost of being wrong that a competitor can't replicate by calling the same API: proprietary usage data that compounds over time, a workflow embedded deep enough that removing it breaks real work, or hard-won practice managing a failure mode a newcomer hasn't seen yet. Generic model capability, alone, is not an advantage.

This is close to what investors call an economic moat, the term Warren Buffett made famous for judging which businesses can defend their profits once everyone can see how they're made. The same test applies to a single AI feature, at a smaller scale. Here's the version I actually walk a roadmap through:

Signal	Commodity capability	Defensible position
Data	Public or generic training data; a competitor's model performs about the same	Proprietary usage data that compounds with every real customer interaction
Workflow depth	A bolt-on feature, easy to switch off or replace	Embedded deep enough that removing it breaks a real, daily workflow
Cost of a wrong answer	Low; a bad output is quietly ignored or redone	High, and already understood, from a company with years of practice managing that exact failure
Speed to copy	A competitor ships something similar within a quarter	Requires years of the same data or workflow position to replicate, not just the same model

I ran this test constantly across acquisitions, usually against the target's own AI slide: which of these four rows was actually true for the feature in front of me, versus which ones the pitch assumed were true because the demo was impressive. That's an inference I've drawn from watching the same pattern repeat across a specific, regulated industry, not a law that holds everywhere AI touches a product. But inside it, a capability that scores commodity on all four rows isn't a bad idea. It's just not a strategy. It's a feature, and it should be scoped, built, and shipped as one, quickly, because a slow build of something anyone can copy is the worst use of a differentiation budget.

How do you sequence an AI product strategy across a roadmap?

Sequence it top-down: strategy picks the two or three workflows on the roadmap that score highest for durable advantage, discovery tests the specific decision inside each one, and an adoption framework rolls out whichever tool passes that test. Running the steps in the other order is how companies adopt tools for problems discovery never validated, in workflows strategy never chose.

None of this makes the individual pitches wrong. A team asking to prototype a support-ticket summarizer, a smarter search feature, or a drafting assistant is usually right that the underlying capability works. The question a strategy is supposed to answer, before any of those pitches gets a discovery cycle, is why this one and not the four others sitting in the same backlog. In my experience the honest answer is almost always about data, workflow depth, or the cost of getting it wrong, and only rarely about which idea got the best applause in the room where it was pitched.

AI Product Discovery: Find the Decision Worth Improving

Tue, 01 Sep 2026 08:36:00 GMT

AI product discovery is the work of finding the one decision worth improving with AI, before anyone touches a model: a real user pain, data that actually exists to support the fix, the risk if the system gets it wrong, and whether the fix fits how people already work. As of September 2026, after 15 years leading product and engineering teams, including through eight acquisitions inside a regulated clinical research organization, I've watched teams start with the model and work backward to a problem that fits it. That's discovery in reverse. The model is the last decision in this process, not the first, and skipping ahead to it is why so many AI features ship that nobody asked for.

What is AI product discovery?

AI product discovery is the work of testing whether an AI feature is worth building before you build it: confirm a real user pain exists, check that the data to support it exists, weigh the risk of a wrong answer, and test workflow fit. The model comes after those four checks pass, not before.

I've sat in enough of these meetings to know the order usually runs backward. Someone has access to a model, or a mandate to "do something with AI," and the search starts from there: what could we point this at? That question always finds an answer, because almost any workflow can be described in a way that makes AI sound relevant to it. The four checks below exist to stop that search early, before a team spends a quarter building a feature that was really a solution looking for its problem.

How do you find the user pain worth solving with AI?

Find a pain someone already works around today, by hand, often enough that they can describe the workaround without thinking. If the honest answer to "why this matters" is "a competitor has it" or "it would be impressive," the pain isn't real yet, whatever the model can do.

This is the same discipline behind Eric Ries's build-measure-learn loop: you're not allowed to build until you can state, in advance, what you'd need to see to know you were wrong. During the acquisitions I led product through, the target companies almost never lacked ideas for what AI could do. What they lacked was a person who could name, specifically, the task they currently do by hand that they'd stop doing tomorrow if a machine did it for them. When I found that person, the project had a shape. When I couldn't find them, I'd usually stumbled onto a feature someone wanted to have, not a problem anyone wanted solved.

How do you know if the data exists to support an AI feature?

Pull a real sample the feature would run on and read it yourself before writing a spec. If you can't find enough labeled, representative examples of the exact case you're building for, the data problem is the actual project, not a footnote to the AI project.

This step gets skipped more than any other, because it's the least fun one. It's easier to sketch the feature than to spend an afternoon reading two hundred real support tickets or clinical notes and asking whether they actually contain the signal you're assuming is in there. In a regulated environment, this check gets harder, not easier: the data that would make the feature good is often the data with the most restrictions on who can see it and how it can be used, and "we'll figure out access later" is how a promising pilot dies in month four instead of week one.

What risks do you need to test before you pick a model?

Test what a wrong answer costs and who sees it first. A wrong suggestion in a private draft is cheap. A wrong answer sent straight to a customer, or one a person can't easily check, is expensive, and the model choice changes completely depending on which one you're building.

I wrote about this same reversibility test in decision-making under pressure: a decision that's cheap to undo deserves less ceremony before you take it, and one that's expensive to undo deserves more. An AI feature is a decision, made by software, at scale, usually faster than any one person could make it by hand. That's the whole appeal, and it's also the whole risk. Before picking a model, I want to know exactly where a human still checks the output, and what happens the first week that check gets skipped because the queue is long and the model has been right ninety times in a row.

Here's the table I actually walk through before any model gets named:

Check	Question it answers	What a pass looks like	What happens if you skip it
User pain	Is there a real, named workaround today?	One person describes it without prompting	The feature gets built and quietly ignored
Data	Does the signal actually exist in real examples?	A read sample confirms it, before the spec is written	The data problem surfaces mid-build, as a delay
Risk	What does a wrong answer cost, and who sees it first?	The blast radius is named and someone owns the check	A bad output reaches a customer with nobody watching
Workflow fit	Is the full loop faster than what it replaces?	Prompting, checking, and fixing together beat the old way	The model adds a task instead of removing one

The same table doubles as the proof a proof of concept is supposed to produce: not a demo of what the model can do, but an answer to the one question that decides whether it's worth building at all.

How do you test workflow fit before committing to a model?

Time the whole loop a person actually runs: prompting, checking, correcting, and redoing the work when the model is wrong. If that full loop is slower than what it replaces, the feature doesn't fit yet, no matter how good a single output looks in a demo.

I wrote the same test into an AI adoption framework at the rollout stage, and it applies just as hard here, one step earlier. A model that drafts something in ten seconds but needs twenty minutes of correction hasn't saved the twenty minutes it looks like it saved in a demo. It's added a new task, checking the model's work, on top of the old one. The only honest way to know is to hand the loop, start to finish, to the person who'd actually run it, and time it against what they do now.

None of this is a case against building with AI. It's a case against letting the model pick the project. The four checks above are slower than opening a chat window and asking what's possible, and that's the point: they cost an afternoon or a week, and they're supposed to. The alternative costs a quarter, on a feature that was never solving anyone's actual problem, and that bill always comes due later than the checks would have.

What a Robotics Software Engineer Actually Builds

Mon, 31 Aug 2026 08:38:00 GMT

A robotics software engineer builds the software that turns a sensor reading into a physical action: perception code that makes sense of what a camera or sensor reports, planning and decision code that turns that read into a choice, and control code that turns the choice into a specific motor command, on a deadline the real world sets, not a sprint calendar. As of August 2026, after 15 years leading software and product teams, and years of turning motors, sensors, and LEGO mechanisms into small robots on my own bench, the pattern I keep running into is this: robotics software engineering is regular software engineering with one constraint stacked on top. The code has to be right close to the first time, because a motor doesn't wait for a retry.

What does a robotics software engineer actually build?

A robotics software engineer builds three connected layers: perception code that interprets sensor data, planning and decision code that turns that read into a choice, and control code that turns the choice into an exact motor command. The job is the software chain between what the robot senses and what it does.

That's a wider job description than it sounds. Perception alone can mean reading a distance sensor or making sense of a noisy camera feed. Planning can mean picking a next move on a fixed rulebook or weighing several options against a goal. Control can mean a simple loop that nudges a motor toward a target, or a tuned system that keeps a whole machine stable while it moves. What ties the three together isn't the specific code. It's that each layer only matters because the one after it eventually has to move something.

I've spent more of my career leading software and product teams than building robots for a living. But I build small ones on my own bench, out of LEGO, motors, and sensors, and the honesty of that loop is what pulled me toward this work. A wheel turns or it doesn't. A sensor sees the object or it doesn't. An arm reaches the thing or misses it completely. Most software I've shipped in 15 years gets to be wrong in private first: a bad build fails in CI, a bad release gets a hotfix. A robot's mistake happens in front of you, in real time, on a table.

Where does the software-to-hardware boundary actually sit?

The boundary sits at the last software decision before a physical action happens: the moment a planning decision becomes a specific motor command sent to real hardware. Everything upstream is still ordinary, forgiving software. Everything at that line gets one real-time shot before the robot has already moved.

Above that line, the work looks a lot like the software career most robotics engineers came from. You write a perception module, you write tests, you fix a bug, you rerun it. Nothing physical happens yet. Below the line is a different discipline: a control loop running on a fixed clock, a motor driver with real current limits, a mechanism with backlash and friction that doesn't match the model in your head. I wrote about this same gap between deciding and acting, at a much faster pace, in Decision-Making Under Pressure: the closer a decision sits to an irreversible action, the less room there is to be wrong and fix it later. Robotics puts that principle into hardware. A planning bug is a bad plan. A control bug at the wrong moment is a robot arm hitting something it shouldn't.

What does the robotics software stack look like, layer by layer?

It runs perception, then planning and decision, then control, then actuation and drivers, with simulation and testing tooling wrapped around all four. Each layer hands a narrower, more time-sensitive decision to the one below it, until the last layer is a voltage on a wire.

Here's the version I actually think in when I'm debugging my own bench setup:

Layer	What it does	What breaks if it's wrong	Side of the hardware boundary
Perception	Turns raw sensor data into a model of the world: distance, position, what's in view	The robot acts on a world that isn't the real one	Software
Planning & decision	Picks a goal or next move from what perception reports	The robot does something technically safe but pointless, or the wrong thing entirely	Software
Control	Turns a decision into a specific, timed motor command	The motion overshoots, oscillates, or arrives too late to matter	The boundary itself
Actuation & drivers	Delivers that command to a real motor, servo, or actuator	The robot stalls, strips a gear, or draws more current than the hardware allows	Hardware
Simulation & testing	Runs the stack above against a modeled or replayed environment before it touches real hardware	Bugs that were cheap to catch in simulation get expensive to catch on the bench	Wraps the whole stack

Most robotics teams don't write the driver and messaging layer underneath all of this from scratch. They build on ROS, the open-source Robot Operating System project, the same way most web teams build on a framework instead of hand-rolling their own HTTP server. It doesn't remove the layers above. It just means you're not also reinventing how a motor command gets from one process to another.

What does a robotics software engineer need to know that a web engineer doesn't?

Real-time constraints, basic control theory, and how to debug a system where the bug might be a sensor, a wire, or a timing race instead of a line of code. The iteration loop is slower and more physical, and a fix isn't verified until the hardware actually does the right thing.

The real-time part surprises people who come from web or product software. A web request that's 200 milliseconds late is a bad metric. A control loop that's 200 milliseconds late can be a robot that's already moved past where the correction still helps. That changes how you write code: you start caring about worst-case timing, not just average timing, because the average is not what gets you in trouble.

The debugging part is its own skill. In most software, a wrong answer means a wrong line of code. On a robot, a wrong answer might mean a wrong line of code, a loose connector, a sensor reading drift, a battery sagging under load, or a mechanism that doesn't move the way the CAD model says it should. I've lost more evenings than I'd like to a "software bug" that turned out to be a servo horn that had slipped half a spline on its shaft. You learn to hold your own code as a suspect, not the culprit, until the hardware clears it.

Is robotics software engineering a good next step from regular software engineering?

Yes, if you like the software-to-hardware boundary more than you dislike a slower iteration loop. The core skill, systems thinking under uncertainty, is the same skill regular software engineering already builds. What's new is real-time constraints, physical testing, and code that only gets one shot.

I wrote about what's changing inside regular software work in Will AI Replace Software Engineers in 2026?: the parts of the job that are pure typing are getting automated fast, and the parts that require ownership and judgment aren't going anywhere. Robotics leans hard into that second category, because a model can draft a control loop, but it can't stand next to the bench and tell you the arm just clipped the table because the coordinate frame was off by one joint. Somebody has to own that, in the room, with the hardware in front of them.

The honest tradeoff is speed. Software iteration is nearly free. Hardware iteration costs a rebuild, a re-flash, sometimes a part you have to wait on. If you're drawn to that constraint instead of annoyed by it, the transition is less about learning a new field and more about adding a layer most software careers never touch: the one where the code finally has to move something in the room with you.

A Technical Due Diligence Checklist Built Around Questions, Not Documents

Fri, 28 Aug 2026 12:00:00 GMT

A technical due diligence checklist is the structured set of items an acquirer works through when examining a target's product, codebase, infrastructure, and engineering team before close. As of August 2026, having run this exercise from inside eight acquisitions, my view is that nearly every published checklist is a list of documents to request — and documents are the easy part. They describe what someone intends to be true. The checklist below has two columns per stage: what to request, which everyone already has, and what to ask, which is where the actual findings live. The full version is free to copy at the bottom.

What is a technical due diligence checklist?

A technical due diligence checklist is the structured set of items worked through when examining a target's product, codebase, infrastructure, and team before close. Most published versions are inventories of documents. The useful part is the second half: the questions that have to be asked of people, because no document answers them.

Checklists are popular because diligence is frightening and a list feels like control. That is not nothing — a shared list does prevent things being dropped. But completeness against a list and understanding of a business are different achievements, and it is easy to reach the end of one while having none of the other.

Why do document-based checklists miss the important things?

Because documents describe what someone intends to be true. An architecture diagram, a roadmap, and an issue list are all statements of intent. The commit history, the on-call rotation, and what an engineer says when asked what they would fix first describe what is actually true. Only the first set gets gathered by default.

The asymmetry is structural. Documents can be requested in bulk, reviewed by people who were not in the room, and produced on a schedule. Conversations require someone senior enough to interpret the answers, in a room with people who have every incentive to be reassuring. One of those scales and one does not, so the timeline eats the one that does not.

Worth being clear: the request column is not optional. You do need the contracts and the P&L and the security posture. The argument is about which column gets cut when six weeks becomes three.

What are the seven stages of a diligence checklist?

Customer, product, technology, team, economics, risk, and integration — the same frame as the diligence hub. Each stage has two columns. The order matters because each stage constrains the next.

Stage	Request	The question that earns its place
Customer	Revenue by account, renewals, churn	Who inside the customer championed this, and are they still there?
Product	Roadmap, issues, releases	What does the team believe the roadmap is, asked separately from leadership?
Technology	Diagram, spend, dependencies	Which part of this system does exactly one person understand?
Team	Org chart, comp, retention terms	Who is staying for the money, and what is their date?
Economics	P&L, unit economics	Which work is a founder currently doing for free?
Risk	Compliance, legal, key contracts	What are you most worried about that has not come up in this process?
Integration	Tooling, cadence	Name the mechanism by which this product got good, in one sentence.

Two of those are worth calling out. "Who is staying for the money, and what is their date?" gets asked far too rarely, and the answer is usually known. And the integration question is aimed at your own side, before close — if nobody can name the mechanism, the integration plan is being written blind.

How do you use a diligence checklist in a compressed timeline?

Cut the request column before the ask column. Document review scales with people and can be delegated or parallelised; the conversations cannot. If there is time for only one thing, spend it talking to the engineers who will still be doing the work after close, without their leadership in the room.

That last clause does real work. The same engineer gives a materially different answer to "what would you fix first" depending on who is listening, and neither answer is dishonest. One is the answer they can defend in front of their CTO. The other is the one you needed.

What should you do with the answers?

Sort them into priceable and unpriceable. Technical debt, infrastructure cost, and integration effort all get numbers and go into the model. Undocumented judgment concentrated in one or two people does not, and it is the finding most likely to determine whether the acquisition works.

The failure mode is letting the unpriceable findings stay a feeling. They get described in a meeting as "some key-person risk," everyone nods, and it never reaches the memo because there is no column for it. Write it as a sentence with a name attached and a date: if this person leaves within a year, these three things stop working. That is a claim someone can disagree with, which is what makes it useful.

The checklist

Copy it, fork it, paste it into whatever you actually use. It is deliberately plain Markdown so it survives being pasted into a doc, a ticket, or a wiki.

Download the full checklist — seven stages, both columns, roughly forty questions.

Two rules travel with it. Reserve time for unstructured conversation with the people who will still be doing the work after close — it is the cheapest instrument available and the first thing cut. And write down what you decided to leave alone, and why, because a playbook without stated reasons is a list, and lists get executed by people who were not in the room when the judgment was made.

If you only take one line from this: the request column tells you what the company says it is. The ask column tells you what it will be like to own.

Integration or Independence: The Decision That Damages Good Products

Fri, 28 Aug 2026 09:00:00 GMT

Post-merger integration is the work of combining an acquired company's product, systems, teams, and processes with the acquirer's after a deal closes. As of August 2026, having led product through eight of these from inside the organization, I think integration damages more good products than any other decision after close — and almost always through choices that were entirely rational when they were made. Nobody wrecks an acquisition on purpose. They consolidate a tool, align a roadmap, standardise a deployment process, and eighteen months later the thing they bought is still running and no longer getting better.

What is post-merger integration?

Post-merger integration is the work of combining an acquired company's product, systems, teams, and processes with the acquirer's after a deal closes. It covers consolidating infrastructure and tooling, merging roadmaps and reporting lines, and it is where most of the value an acquisition was supposed to create is either realised or lost.

It is also the stage with the least diligence attached to it. Enormous effort goes into deciding whether to buy. Comparatively little goes into deciding what to do on the Monday after, and the second decision has more effect on the outcome than the first.

Why does integration damage products that were working?

Because consolidation usually removes the mechanism that made the product good, not the product itself. Small teams decide fast because the whole system fits in a few heads and nobody needs permission. Integration replaces that with process that is correct, defensible, and slower. The product does not break; it stops improving at the rate that made it worth buying.

This is the part that is genuinely hard to see coming, because every individual decision survives scrutiny. Standardising on one CI pipeline is defensible. Moving the acquired team onto the acquirer's release calendar is defensible. Requiring architecture review for changes above a certain size is defensible. Each one adds a small amount of latency and removes a small amount of autonomy, and none of them is the decision that did the damage.

The damage is cumulative and nobody owns it. That is a structural problem, not a failure of judgment.

What should an M&A integration playbook contain?

A list of what will be consolidated, what will be left alone, and the reason for each — written before close, when the answer is still a judgment rather than a reaction. Most playbooks are inventories of systems. The useful part is the second column: what made this product valuable, and does consolidating this particular thing preserve or destroy that.

Here is the frame I actually use:

Layer	Default	Why
Billing, identity, HR, procurement	Consolidate	Nobody bought a company for its expense reporting. Real cost, no differentiation.
Security and compliance tooling	Consolidate	In a regulated environment this is not optional, and the acquired team usually knows it.
Observability and CI	Case by case	Cheap to consolidate, and the first place latency creeps in unnoticed.
Deployment cadence	Leave alone	Almost always part of why the product was good.
Roadmap and prioritisation	Leave alone, longest	The moment this merges, the acquired product competes for attention against things with bigger numbers.
Who can talk to a customer	Leave alone	Proximity to the customer is frequently the entire advantage.

The column that matters is the third one. A playbook without stated reasons is a list, and lists get executed by people who were not in the room when the judgment was made.

When is consolidation genuinely worth it?

When the thing being consolidated is genuinely undifferentiated. Nobody bought a company for its expense reporting. Consolidation goes wrong when it reaches the layers where the advantage actually lived: deployment cadence, who can talk to a customer, and how a decision gets made.

The test I apply is narrow and it works: name the mechanism. Not the feature, not the team — the mechanism by which this product got good. If you cannot say it in a sentence, you are not ready to decide what to integrate, because you cannot tell which consolidations threaten it.

Sometimes the mechanism is a person who answers support tickets personally. Sometimes it is a deployment process nobody would approve on paper. Sometimes it is that the whole system is small enough for one engineer to reason about end to end, which means the honest integration plan is do not add to it.

How do you know integration is going wrong?

Watch the decision latency, not the milestone tracker. If a change that used to take a day now takes three weeks and two approvals, the integration is succeeding on its own terms and failing on the reason for the acquisition. That signal appears months before it shows up in revenue, and almost nobody measures it.

Integration programmes report on completion — systems migrated, teams onboarded, tools retired. Those are all real and all beside the point. The number that predicts whether the acquisition worked is how long it takes the acquired product to make a change, and it is trivially measurable from the moment of close if anyone thinks to start.

This is the same reversibility test I use everywhere else: a decision that is cheap to undo deserves less ceremony, and one that is expensive to undo deserves more. Most integration decisions are quietly one-way. Once a team is on the shared release train, getting them off it is a political act rather than a technical one.

This is stage six of the seven in the diligence frame. It is the one that runs longest, receives the least scrutiny, and does the most damage — and unlike the earlier stages, you are no longer deciding whether to buy. You are deciding whether what you bought survives being owned.

A Personal Operating System

Fri, 28 Aug 2026 08:41:00 GMT

A personal operating system is a repeatable cadence, capture, orient, decide, review, for turning a head full of half-formed obligations into an honest next move. As of August 2026, after 15 years building products for people who have to decide under real stakes, and a 36-hour mountain effort at 29029 Snowbasin that stripped my own habits down to what actually holds up, I keep landing on the same four steps. Capture gets the noise out of your head and onto something you trust. Orient tells you the truth about what actually matters this week, not what feels loudest. Decide picks the smallest next move, not the whole plan. Review is the step almost everyone skips, and it's the one that keeps the other three honest.

What is a personal operating system?

A personal operating system is four repeatable steps, capture, orient, decide, review, run on a fixed cadence, that turn scattered obligations into a trustworthy next move. It isn't a single app or planner. It's the rhythm you run those tools through, whether the week is calm or on fire.

The homepage of this site names a framework I use professionally: land, orient, act. It's built for the moment someone hits a product under pressure and needs to know what to do next, fast. The personal version runs slower and adds a step, because ordinary life doesn't hand you one crisis at a time. It hands you forty of them, all at once, most of them small.

Capture, orient, decide, review is that four-step version. I wrote about the orient-decide-act loop in Decision-Making Under Pressure for the moments when the clock is the enemy. This is the version for the week you're not on a mountain, when the obligations arrive quietly instead of all at once, and the risk isn't panic. It's letting things pile up until nothing gets your best attention.

Why does capture have to come before anything else?

Capture comes first because an obligation you're only holding in your head costs attention whether or not you're working on it. David Allen's Getting Things Done calls this an open loop, an unresolved commitment your mind keeps rechecking. Writing it down somewhere you trust closes the loop, even before you've decided what to do about it.

I learned this the expensive way running product teams through eight acquisitions. Every reorg produced its own flood of half-finished threads: decisions waiting on someone, promises made in a hallway that never made it into a system anywhere. The ones that got dropped weren't the big ones.

Nobody forgets a launch date.

It was the small hallway promise that quietly turned into a broken one, because it only ever lived in someone's head.

At home it looks smaller and just as real. A shoe nobody can find, a permission slip due Friday, a repair I keep meaning to get to on a boombox that's been sitting on the bench for three weeks. None of that is urgent enough to remember on its own. Capture means it goes into one place I actually check, the moment it shows up, before I've decided what, if anything, to do about it.

How do you turn a captured list into an honest orientation?

Orientation means sorting what you captured against what's actually true this week: your real energy, your real deadlines, and what's reversible if you're wrong. It's the same honest self-check I describe in decision-making under pressure, run at a slower pace and a longer interval, against a to-do list instead of a heart rate.

Pressure isn't the only thing that distorts a read on yourself. So does a full inbox. The email that arrived ten minutes ago always feels more urgent than the deadline three weeks out, even when the deadline matters more and the email doesn't. Orientation is the step where you catch that, on purpose, instead of working whatever showed up last.

The habit is the same one I rehearsed on a mountain and wrote about in Decision-Making Under Pressure: an honest read of your actual state before you touch a decision. At a desk, the read is different. It's not a heart rate number. It's asking which of these ten open items would actually matter if I only got to one, and admitting the honest answer is usually a smaller item than the one making the most noise.

What does the decide step need to produce?

The decide step needs to produce one concrete next action, not a category or a vague intention. Handle onboarding isn't a decision. Draft the onboarding email, twenty minutes, before three o'clock is. If the item leaving orientation can't fit that shape, it hasn't been decided. It's been renamed.

This is where most systems quietly fail, and I've watched it happen in product reviews as much as on a Tuesday morning at home. A backlog full of items like improve onboarding or deal with the garage isn't a decided list. It's a list of categories wearing a to-do list's clothes.

Nobody can act on a category. Somebody can act on draft the onboarding email, twenty minutes, before three.

Here's the version of the cadence I actually run, written the way I'd hand it to someone else:

Step	What it answers	Minimum cadence	What breaks if you skip it
Capture	What's competing for my attention right now?	The moment it shows up	The same worry resurfaces at 2am because nothing closed the loop
Orient	What's actually true about this week?	Daily, five minutes	You work the loudest item instead of the one that matters
Decide	What is the smallest next move?	At orient time, per item	Tasks stay vague, so they stay undone
Review	Is the system still telling me the truth?	Weekly, same day	The system turns into a list nobody trusts, then nobody opens

How often should you review the system, and why do most people skip it?

Review on a fixed weekly slot, not whenever you remember to. Its only job is to catch what capture and orient missed that week. Skip it and the system doesn't fail loudly. It quietly stops being trusted, which is worse than never building one, because now you've also lost the habit of using it.

Mine happens Sunday evening, after the kids are down, fifteen minutes with the captured list from the week. I'm not doing the work in that slot. I'm checking whether the system told me the truth: did the important thing actually get the decide step, or did it get buried under six loud small ones again.

Some weeks the honest answer is no. That's fine. The review is what tells you, instead of finding out three weeks later when something you cared about quietly missed its window.

The metric I care about professionally is time-to-confidence: how long before someone under pressure knows what to do next. The personal version of that question doesn't need a mountain to matter. Most days the pressure is smaller: a full inbox, a house full of people who all need something at once, more open loops than hours in the day. Capture, orient, decide, review doesn't make any of that disappear. It makes sure the next move you take is an honest one, not the loudest one that happened to be standing closest.

The Customer Isn't Always Right. Their Behaviour Usually Is.

Thu, 27 Aug 2026 18:00:00 GMT

The say-do gap is the distance between what customers tell you they want and what they actually do when it is in front of them. As of August 2026, after fifteen years building platform products in healthcare and clinical education, the sharpest lesson I have on this came from being wrong in public. Customers told us they did not want advertising. I did not want advertising either. The business shipped it anyway, and the usage data disagreed with all of us — not by proving the customers liars, but by revealing that what people say about a hypothetical and what they tolerate in practice are two different measurements of two different things. Both were true. Only one of them paid for the platform.

What is the say-do gap?

The say-do gap is the distance between what people tell you they will do and what they actually do. In product work it is the difference between survey responses, interview answers and support tickets on one side, and usage data on the other. Both are real evidence. They frequently disagree, and the disagreement is the useful part.

The gap is old enough to have a founding study. In 1934, the sociologist Richard LaPiere published Attitudes vs. Actions, reporting on two years spent travelling the United States with a Chinese couple during a period of open anti-Chinese prejudice. They were refused service at one of 251 establishments. Surveyed months afterwards, roughly 92% of those same businesses said they would not serve Chinese guests.

The study has real problems — six months separated the visits from the survey, the people who answered were often not the people who had served them, and LaPiere himself noted his companions were affluent, Westernised and disarming. Worth saying plainly, because an article about weighing evidence should not wave through its own.

But the shape of the finding survived ninety years of methodological argument, and it is the shape that matters: stated attitude and observed action came apart, dramatically, and the people involved were not lying.

Why does customer feedback disagree with customer behaviour?

Because they measure different things. Feedback captures what someone believes about a hypothetical, filtered through how they want to be seen. Behaviour captures what they chose when something was actually in front of them and the cost was real. Neither is dishonest. People genuinely do not know in advance what they will tolerate.

Ask a clinician whether they want advertising in a reference tool they use between patients and you will get a clear answer. It is a sincere answer. It is also an answer about an imagined product, given by someone with no reason to model the economics of the thing they are being asked about, at a moment when the cost of saying no is zero.

Then ship it, and the same person has a different question in front of them: is this still the fastest way to get what I need right now?

Those are not the same question. We kept treating the first answer as a forecast of the second.

What happened when we shipped it anyway

I was against it. So was most of the product organisation, and we had the feedback to back us up. The commercial argument won, as commercial arguments do when the alternative is a platform that does not pay for itself.

What I expected was a visible cost — people leaving, engagement falling, the feedback getting louder and being proven right.

What happened was quieter and more uncomfortable. People stayed. Usage held. The tool was still the fastest way to answer the question they had, and the advertising was a thing they navigated past on the way. The revenue was real, and it funded work that made the product materially better for the same people who had said they did not want it.

I have thought about that for years and I still do not think the customers were wrong. They were answering the question they were asked. We were the ones who mistook a preference for a prediction.

Should you ignore what customers say?

No. Feedback is the best early signal you have about what people value and where the friction is, and it arrives long before usage data exists. The mistake is treating it as a prediction of behaviour rather than as a statement of preference. Preferences are real — they are just not the same thing as choices.

Here is the frame I use now, and the reason I stopped arguing about which source to trust:

Source	Strong at	Silent on	Fails when
What they say	Why. Where the friction is. What they value.	Whether they will actually change what they do.	Treated as a forecast
What they do	Whether. Under real conditions, with real cost.	Why. What it cost them internally.	Treated as approval
What the business needs	What the company can survive doing.	What anyone actually wants.	Treated as strategy

Every one of those is evidence. None of them is an answer. Product judgment is what you do when they point in different directions — which is most of the time, and is precisely the part no framework hands you.

What is the risk of trusting behaviour over feedback?

That tolerance gets mistaken for approval. People staying does not mean they are happy. It can mean the alternative is worse, or that leaving is expensive, or that they have not yet found the thing that makes leaving easy.

This is the part of the story I would emphasise if I were telling it to a room of product people, because it is the part that gets skipped. Behaviour tells you what someone accepted under conditions you created. It does not tell you what they would choose if a better option appeared. And a better option always eventually appears.

So the honest reading of what we learned is not customers say one thing and do another, therefore discount what they say. It is narrower and more useful:

Feedback told us what people would prefer. Behaviour told us what they would tolerate. The distance between those two was our margin — and margin built on tolerance is borrowed, not earned.

That is a genuinely uncomfortable conclusion for a product person, because it means being right about the revenue and still carrying a debt.

How do you decide when the evidence disagrees?

Ask what each source is actually good at measuring, then ask which question you are trying to answer. Feedback is strong on why and weak on whether. Behaviour is strong on whether and silent on why. Commercial reality tells you what the business can survive. Judgment is deciding what to do when those three disagree.

The practical move is small and almost nobody makes it: write down, before you ship, what result would change your mind. Not the success metric — the disconfirming one. If engagement had fallen, how far, for how long, before we pulled it? We did not have that number, which meant that whatever happened next, we were always going to be able to tell ourselves a story where we had been right.

That is the same discipline I have written about for deciding under pressure and for running a bounded AI pilot: name the stop condition while the answer is still unknown, because afterwards it is not a decision any more, it is a narrative.

Twenty years in, the frameworks I trust least are the ones that promise to resolve this for you. Listen to your customers and follow the data are both advice that stops working at precisely the moment you need advice — the moment the sources disagree.

That moment is the job.

Before You Buy It: A Product and Technology Diligence Frame

Thu, 27 Aug 2026 09:00:00 GMT

Technical due diligence is the examination of a target company's product, codebase, architecture, and engineering team before an acquisition closes. As of August 2026, after fifteen years building platform software in regulated healthcare and leading product through eight acquisitions from inside the organization rather than the deal team, I've come to think diligence rarely fails for lack of data. It fails on the questions asked. The deal asks whether the asset is as described, and answers that well. The operator asks what this will be like to own on a Tuesday eighteen months from now, and almost nobody has time for that question during the window when it could still change the price.

What is technical due diligence?

Technical due diligence is the examination of a target company's product, codebase, architecture, and engineering team before an acquisition closes. It exists to price risk the financial model cannot see: what the system actually costs to run, what it will cost to integrate, and whether the people who understand it will still be there in a year.

Technology due diligence and software due diligence describe the same exercise with different emphases — one leans toward architecture and infrastructure, the other toward the codebase itself. In practice the boundary matters less than who is asking. A firm running the process for a lender wants a defensible report. An operator who will inherit the system wants to know what is going to hurt.

Both are legitimate. They produce different documents.

Why does technical due diligence miss what matters?

Because it usually answers the deal's questions rather than the operator's. The deal asks whether the asset is as described. The operator asks what this will be like to own on a Tuesday in eighteen months. Both are legitimate; only one of them predicts what happens after close, and the window is almost always spent on the first.

The structural reason is that diligence is scoped by people who will not operate the result. That is not a criticism — it is how the incentive works. The deal team is measured on getting to a defensible close. The operators arrive afterward, inherit whatever was true, and have no mechanism to send questions backward in time.

So the artifacts requested are the ones that are easy to request. An architecture diagram. A roadmap. A list of open issues. Each of those is a description of what someone intends to be true. The commit history, the on-call rotation, and what an engineer says when you ask what they'd fix first are descriptions of what is true. Only one set gets gathered by default.

What are the seven stages of product and technology diligence?

Customer, product, technology, team, economics, risk, and integration. The order matters, because each stage constrains the next. A technology finding means something different depending on what the customer stage revealed, and an integration plan built before the team stage is a plan resting on an assumption about who will still be there to execute it.

Stage	The question	What it looks like when skipped
Customer	Who actually uses this, and will they stay?	The logo list survives; the champions who renewed it leave
Product	What has been promised, to whom?	Commitments surface after close, priced at zero
Technology	What will this cost to run and to change?	Integration estimates built on the diagram, not the system
Team	Who understands this, and what happens to them at close?	Retention holds bodies; the knowledge leaves anyway
Economics	Which costs are structural, and which are unpaid founder labour?	Margin evaporates on contact with a real org chart
Risk	What is load-bearing that nobody wrote down?	Discovered during the first incident
Integration	Consolidate or leave it alone?	A rational decision that quietly damages the thing you bought

I keep this frame in my head on every one of these now. The moment a diligence workstream cannot say which stage it is answering, it has usually drifted into gathering documents.

What is the difference between the deal's questions and the operator's?

The deal's questions are answerable from documents: what exists, what it earns, what it owes. The operator's questions are answerable only from conversation: what is load-bearing that nobody wrote down, what the team believes the roadmap is, and which departures would actually hurt. Documents are gathered; the other kind has to be asked for.

That distinction is the whole argument of this series. It also explains why diligence quality correlates poorly with diligence volume. A four-hundred-page data room and six weeks of review can leave every operator question untouched, because none of them have a document that answers them.

The practical move is small: in every diligence, reserve time for unstructured conversation with the people who will still be doing the work after close. Not a presentation. A conversation, without their leadership in the room, about what they would fix first and what they are worried about. It is the cheapest instrument available and the first thing cut when the timeline compresses.

When should you walk away from an acquisition?

When the thing being bought turns out to be a person rather than a system, and that person's incentives end at close. Technical debt is priceable. Integration cost is estimable. Undocumented judgment concentrated in one or two people who are about to become wealthy and unmanaged is the risk with no number attached to it.

That is not an argument against acquiring small teams. It is an argument for knowing which one you are doing. Buying a system and buying a capability are different transactions with different failure modes, and the diligence that serves one is close to useless for the other.

The same discipline shows up elsewhere in how I think about building: reduce the uncertainty, establish the evidence, then make the next decision. An acquisition is that loop run once, expensively, with a signature at the end of it.

The rest of this series takes the seven stages one at a time.

When Do Virtual Reality Simulations in Healthcare Education Actually Help?

Tue, 25 Aug 2026 08:37:00 GMT

Virtual reality simulations in healthcare education are immersive, headset-based scenarios built to put a learner inside a clinical moment, an OR, a patient room, a mass-casualty scene, so they can rehearse a decision with a sense of presence a screen or a mannequin can't fully replicate. As of August 2026, after years building VR healthcare education experiments and virtual patient products at WebMD and Medscape, I think the technology gets judged on the wrong question. The question isn't "does the VR look real." It's "does this specific lesson need presence to land." Most clinical learning goals don't. Some genuinely do. The programs that get value from VR are the ones that can tell the difference before they buy the headsets, not after.

What are virtual reality simulations in healthcare education?

Virtual reality simulations in healthcare education are immersive, headset-based scenarios that put a learner inside a clinical environment, a patient room, an OR, a disaster triage scene, so they can rehearse a decision with a sense of presence a screen or a mannequin can't fully replicate.

I built products in this exact category. A VR scene isn't a video with extra steps. It puts the learner's body in the scene, their head turns and the room turns with it, their attention has to find the crashing vital sign instead of having it framed for them by a camera angle. That's the actual capability VR adds over a screen-based case: attention has to work the way it works in a real room, scattered, competing for focus, not curated.

That capability is real. It's also expensive, and it's only worth the expense when the lesson specifically depends on it.

When does VR actually outperform a lower-fidelity method?

VR earns its cost when the learning goal specifically needs spatial awareness, environmental pressure, or the physical feeling of a scene, situations a branching case or a mannequin can't reproduce. For most decision-based learning, a cheaper method teaches the same lesson.

Here's the table I actually use when someone asks whether a program should build in VR:

Learning goal	Best-fit modality	Why
Clinical decision reasoning (what to order, what to rule out)	Branching virtual-patient case (screen-based)	The decision is in the reasoning, not the room. A screen presents it cheaper and lets you iterate content faster.
Procedural muscle memory (a specific hands-on skill)	High-fidelity mannequin or task trainer	The learner needs to feel the physical resistance and repeat the motion. VR controllers don't replicate that yet.
Situational awareness under environmental pressure (triage, a crashing room, competing alarms)	VR	The lesson is what the learner notices and prioritizes in a chaotic space. That's the one thing a screen can't stage.
Communication and bedside manner	Standardized patient (a trained human actor)	The lesson is reading a real human's affect and responding to it. Nothing synthetic replaces that yet, VR included.
Rare, high-stakes, low-frequency events (a mass-casualty scenario, an OR fire)	VR	Real rehearsal is impossible or unsafe to run often. VR is the only affordable way to get repetitions.

The pattern in that table: VR wins when the room itself is the teacher, spatial pressure, environmental chaos, an event too rare or dangerous to rehearse physically. It loses, on cost and speed, whenever the lesson lives in the reasoning or the relationship instead of the space.

What is instructional fit, and why does it decide whether VR works?

Instructional fit is whether the modality matches what you're actually trying to teach. VR fits goals built on presence and spatial pressure. It's a poor fit for goals built on judgment and reasoning, where the immersion adds cost without adding learning.

I've watched programs buy VR because it demos well in a stakeholder review, then discover the actual content is a straightforward decision tree that would have worked identically as a web-based case, at a fraction of the build cost and with faster content iteration. The headset didn't make the lesson worse. It just didn't make it better, and it made everything slower to update.

This matches how the healthcare simulation researcher David Gaba framed the whole field in his 2004 paper on simulation's future: simulation is "a technique, not a technology." The guided experience is the thing; the equipment is whatever delivers it. That distinction has stayed contested for twenty years — a 2026 review in JMIR Medical Education revisits it directly, arguing that learner engagement, not physical realism, is what actually carries the learning.

The honest test I use: write the learning objective first, in one sentence, before choosing the modality. If the sentence is about a decision, a screen usually wins. If the sentence is about a scene, VR usually wins. Picking the modality before the objective exists is how budgets end up spent on the wrong fidelity.

How does feedback design change what a VR scenario actually teaches?

A VR scene without a clear signal for what the learner's choice did teaches the room, not the decision. The feedback, a change in the scene, a debrief afterward, is what turns the immersive experience into a lesson instead of a demo.

This is the same stack I've written about for healthcare simulation technology generally: rehearsal only becomes learning once feedback and facilitation are attached to it. VR doesn't get an exception to that rule. It's actually more exposed to the risk, because immersion is so convincing that a learner can walk out of a VR scene feeling like they learned something, when what they actually got was a vivid experience with no signal attached to it.

The fix isn't more fidelity. It's a scene that visibly responds to the choice, a deteriorating vital sign, a colleague's reaction, and a debrief afterward that connects what happened in the headset to the reasoning behind it. Presence without feedback is a very expensive memory, not a lesson.

Does the learning from a VR scenario transfer to a real patient encounter?

Sometimes, and it's the question most programs skip. Transfer depends on whether the scenario matches the real decision closely enough and whether a facilitator connects the rehearsal to the next real case afterward. Immersion alone doesn't guarantee it, and a vivid scene with no follow-up debrief often teaches nothing that survives past the headset.

Presence and transfer aren't the same thing. A learner can feel completely present in a VR OR and still fail to apply the lesson three weeks later on the actual unit, because nobody closed the loop between the scenario and the next real decision. That's a facilitation problem, not a hardware problem, and no amount of visual fidelity fixes it.

Before scaling a VR program, I'd test the smallest version of the loop first: one scenario, a real debrief, and a before-and-after check on the learner's confidence and decision-making on a follow-up case. If that small loop doesn't move the number, more realistic hardware won't fix it, it'll just make the same non-result more expensive.

The same discipline applies here that I've written about for AI product interfaces: the interface, headset or otherwise, isn't the product. What the learner trusts themselves to do differently afterward is the product. VR is one way to build that. It's not the only way, and it's rarely the cheapest one.

I'm not offering clinical guidance here, and none of this is that. It's a product and instructional-design view from someone who spent years shipping this category, and where a claim goes beyond my own build history, I've kept it qualitative rather than attaching a number I can't stand behind.

The headset is a delivery mechanism. Whether it was the right one was always a question about the lesson, not the technology.

I write more about the fifteen years of specific programs behind these calls on the About page.

An AI Adoption Framework That Starts With Trust

Sun, 23 Aug 2026 03:43:00 GMT

An AI adoption framework is the sequence you run before an AI tool touches real work: confirm readiness, run a bounded pilot, test workflow fit, collect evidence, then decide whether to scale it or kill it. As of August 2026, after 15 years leading product and engineering teams through eight acquisitions inside a regulated clinical research organization, I've watched most AI rollouts skip straight to the last step. Someone buys the license, mandates the tool company-wide, and calls adoption a seat count. That's backward. Trust isn't a feature you switch on with a license key. It's something a small group earns with the tool, in a contained space, before anyone extends it to people who never got to watch it fail safely first.

What is an AI adoption framework?

An AI adoption framework is a five-stage sequence, readiness, a bounded pilot, workflow fit, evidence, and a scale decision, that a team runs before rolling an AI tool out past the people who tested it. Each stage has to pass before the next one starts; skipping ahead is where most rollouts go wrong.

I think of this the same way Everett Rogers described technology diffusion in Diffusion of Innovations back in 1962: adoption moves through a curve, not a switch. A small group tries something first, under conditions everyone agrees to watch closely, and the rest of the organization follows only if that group's experience holds up. Most AI rollouts I've watched treat adoption as a procurement event instead. The tool clears legal and security review, someone announces it in an all-hands, and the curve gets skipped entirely. The framework below is my attempt to put the curve back in, deliberately, instead of hoping it happens on its own.

What does readiness mean before you adopt an AI tool?

Readiness means you can name the specific workflow problem the tool is supposed to fix, and someone in that workflow agrees it's a real problem. If the honest answer to "why are we doing this" is "competitors are doing it" or "the budget exists," the team isn't ready yet, whatever the tool can do.

I've sat in enough vendor demos to know a capable tool and a ready team are different questions. During the run of acquisitions I led product through, the technology being folded in was rarely the hard part. The hard part was whether the people inheriting it could name what problem it solved for them specifically, not for the org chart. When nobody in the room could answer that in one sentence, the rollout stalled no matter how good the demo looked, and it should have. A tool without a named problem doesn't get adopted. It gets tolerated until someone quietly stops using it.

Why should the first rollout be a bounded pilot, not a launch?

A bounded pilot limits the blast radius of being wrong: one team, one workflow, real work, with a stop condition set in advance. A launch mandates the tool for everyone before anyone has proven it earns the trust it's asking for, so the first bad output lands on people who never chose to test it.

This is the same discipline behind a good proof of concept: the pilot exists to answer one question, not to be a smaller version of the eventual rollout. Pick the team with the clearest workflow problem, give them a real stop condition, "if error rate crosses X or the team asks to stop, we stop", and write it down before the pilot starts, not after something goes wrong. Gartner's hype cycle names the failure mode this guards against: the trough after inflated early expectations, when a company-wide mandate meets its first bad week and trust collapses everywhere at once instead of in one contained place.

How do you test whether an AI tool actually fits the workflow?

Test fit by timing the whole loop, not just the AI's output: prompting, checking, correcting, and redoing the work when the tool is wrong. If that full loop takes longer than the manual version did, the tool doesn't fit yet, no matter how good a single output looks in a demo.

This is the same failure mode I wrote about in AI UX patterns: a system that looks fast in a demo but hides the real cost in the checking step. A tool that drafts a first pass in ten seconds but needs twenty minutes of correction hasn't saved anyone twenty minutes; it's added a new task on top of the old one. Workflow fit isn't measured by what the tool produces. It's measured by what the person using it has to do before they'll actually trust the output enough to ship it.

What evidence do you need before you scale an AI pilot?

You need evidence measured against the workflow's real baseline, not against no tool at all: time saved per task, error rate compared to the manual process, and whether the pilot team would keep using it without being told to. An anecdote from the loudest advocate isn't evidence.

Here's the table I actually use when I'm deciding whether a pilot has earned the next stage:

Stage	Question it answers	What a pass looks like	What happens if it fails
Readiness	Is there a named problem, not just a tool budget?	One team can state the problem in a sentence	The rollout stalls or gets ignored
Bounded pilot	Can this be tested without touching every user?	One team, real work, a written stop condition	A bad output reaches people who never opted in
Workflow fit	Does the full loop save time, checking included?	The loop is faster than the manual version	The tool adds a task instead of replacing one
Evidence	Do we have numbers, or just enthusiasm?	Time, error rate, and voluntary continued use	The scale decision is really a guess
Scale decision	Does the evidence hold past one team?	A second team gets the same result	Scale amplifies a fluke instead of a fix

The cost of skipping this stage shows up in the aggregate numbers. MIT's Project NANDA found that about 95% of enterprise generative AI pilots delivered no measurable P&L impact, against $30–40 billion in spending, and attributed the gap not to model quality but to workflow integration and the absence of a defined outcome before the build started. That is a description of stages one through four being skipped at scale.

Skipping the evidence stage is the mistake I see most, because it's the one stage that costs patience instead of budget. Everyone can find money for a pilot. Fewer people are willing to wait the extra month it takes to know if it actually worked.

When should you scale a pilot, and when should you kill it?

Scale when the evidence holds across more than one team and a failure inside it is cheap to catch and fix. Kill it when the pilot only worked because of one person's judgment, or when a failure would be expensive or hard to reverse once it's everyone's default.

This is the same reversibility test I laid out in decision-making under pressure: a decision that's cheap to undo deserves less ceremony before you take it, and a decision that's expensive to undo deserves more, whatever stage of the framework you're in. An AI pilot that only worked because the one person running it happened to know exactly when to override it isn't ready to scale. It's a skilled person doing skilled work, with a tool as a prop. Scaling that removes the one thing that made it safe.

The framework above isn't a gate to slow AI down for its own sake. It's the same sequence I'd want run before adopting any new system inside a regulated workflow, AI or not, because trust has never been a checkbox you clear once. It's a small group's experience, extended to a bigger group only after the small group's experience holds. Most rollouts fail for the boring reason that nobody wrote the stop condition down. The ones that work are the ones that were willing to stay small until the evidence said otherwise.

AI UX Patterns Worth Building Around

Sat, 22 Aug 2026 08:35:00 GMT

AI UX patterns are the small set of interface decisions, showing a preview before an action runs, making that action reversible, showing where an answer came from, and knowing when to hand off to a person, that decide whether someone trusts an AI product enough to keep using it. As of August 2026, after 15 years building products, including clinical simulation and platform tools where trust had to be earned before intelligence was even useful, I've stopped believing the pattern that matters is how the interface looks. The chat bubble, the typing dots, the sparkle icon: none of that is the product. The product is whether a user can tell, in the moment, what the system is about to do and how far they can trust it.

What are AI UX patterns?

AI UX patterns are the interface decisions that determine whether someone trusts an AI feature enough to keep using it: showing a preview before an action runs, making that action reversible, showing where an answer came from, and knowing when to hand off to a person instead of acting alone.

Most write-ups of AI UX patterns list surface conventions: streaming text, loading skeletons, a regenerate button. Those are fine details, but they're not what earns trust. The homepage of this site names the metric I actually design against: time-to-confidence. Not "does the AI work," but how long before the person in front of it knows what to do next. Surface conventions barely move that number. Structural guarantees do.

Why does a preview shorten time-to-confidence?

A preview turns a guess into a check. Instead of trusting the system's judgment about what it's about to do, the user trusts their own judgment about what they're looking at, which is a shorter, more reliable path to feeling safe enough to proceed.

GitHub Copilot's code review is the clearest version of this I've used. It doesn't ask you to trust the model's intent. It shows you the exact lines it wants to change and lets you read them like you'd read any other diff. That's a smaller cognitive step than "trust the AI," and smaller steps are what actually get taken under real deadline pressure. It's the same principle behind a well-built virtual patient case: the learner isn't asked to trust that the scenario is realistic. They're shown the exact vitals and history in front of them and asked to read those, the way they'd read a real chart.

Why does reversibility matter more than accuracy in an AI product?

Accuracy is an average over many uses. Reversibility is a guarantee about this one use. A system that's wrong 2% of the time but easy to undo feels safer than one that's wrong 0.5% of the time and hard to walk back, because the user only ever experiences one outcome at a time.

This is the same math I wrote about in decision-making under pressure: whether a move is reversible changes how much scrutiny it deserves before you take it. AI interfaces that skip a reversible design because the model is "usually right" are betting the whole relationship on an average the user never gets to see. One bad, un-undoable action erases a dozen good ones. ChatGPT's edit-and-regenerate pattern works for the same reason Copilot's diff does: it treats every output as a draft with a visible undo, not a final answer.

What does provenance actually mean in an AI interface?

Provenance means the interface shows where an answer came from, a document, a calculation, a model guess, and how confident the system is in it, instead of presenting every output in the same flat, authoritative tone regardless of how solid the ground under it actually is.

Most AI interfaces flatten this on purpose, because a single confident voice reads as more polished. That's backward for anything with real stakes. I built healthcare simulation products on the premise that a learner has to know the difference between a fact and a model's best guess, because in the field that difference is the whole job. An interface that can't tell the user "this came from the source document" versus "this is the model's inference" isn't being simple. It's hiding the one signal a careful user actually needs.

When should an AI product escalate to a human instead of acting alone?

Escalate when the stakes are real and the system's own confidence is low, or when the action can't be cheaply undone. The boundary has to be visible before the moment it's needed, not discovered by the user after the system already acted past it.

Intercom's Fin support agent is a decent public example: it answers routine questions on its own and hands off to a person when a query falls outside what it's confident about, and it tells the user that's happening. Intercom publishes the resolution and handoff outcomes as first-class metrics, which is itself the tell — a vendor treating the escalation boundary as a number worth reporting is a vendor that designed one. The failure mode I've watched more often is the opposite: a system with no visible boundary at all, so the user only learns where the edge was after it got crossed badly. Here's the table I actually use when I'm reviewing an AI feature before it ships, whether it's a product I'm building or one I'm just using:

Pattern	What it protects	Failure mode without it	One way to build it
Preview	The user's sense of control	The action feels like it happened to them	Show the exact diff, write, or message before it commits
Reversibility	Trust after a wrong answer	One bad action erases many good ones	A visible undo, not a support ticket, for at least 30 seconds after
Provenance	Judgment about how much to trust an answer	Every output reads equally authoritative	Tag each claim: sourced, calculated, or inferred
Escalation	Safety at the edge of the system's competence	The user discovers the boundary after it's crossed	A named handoff to a person, offered before confidence drops too far

None of these rows are hard to build. What's hard is deciding, before launch, which stakes are high enough to earn them. A low-stakes feature, a tone suggestion in a draft email, doesn't need an escalation path. A feature that writes into a patient record or a financial ledger needs all four rows, and it needs them visible, not buried in a settings page nobody opens.

The pattern I'd push back on if I heard myself arguing it five years ago: that a good enough model eventually makes these guardrails optional. It doesn't. The guardrails aren't a hedge against a weak model. They're the part of the interface that lets a person keep their own judgment in the loop, which is the actual reason anyone trusts a tool enough to keep using it past the first try.

Decision-Making Under Pressure

Thu, 20 Aug 2026 22:20:00 GMT

Decision-making under pressure is the discipline of choosing your next move before you have full information, while stress is actively narrowing what you can see. As of August 2026, after 15 years building products for people who have to decide under real stakes, in healthcare education and regulated platforms, and 36 hours into a mountain in Utah, I keep landing on the same finding. The failure point is almost never the decide step. It's the orient step: the moment you have to read your own state honestly before choosing anything. Most advice skips straight from noticing a problem to picking an answer. The systems that hold up under real pressure force an honest orient first, every time, on purpose, before the decide step gets anywhere near the wheel.

What does decision-making under pressure actually require?

Decision-making under pressure requires three things in order: an honest read of your own state, a next move sized to what you can verify right now, and the discipline to act on that move instead of the plan you made before the pressure changed the picture. Skip the honest read and the rest doesn't matter.

The homepage of this site names the metric I actually care about as a product person: time-to-confidence. How long before someone under pressure knows what to do next? Not the full plan. The next move.

That's a narrower question than it sounds. Most decision frameworks I've seen in product work are built for the calm room: gather data, weigh options, decide. Under real pressure, that sequence collapses. There isn't time to gather, and the data you have is already partial. What survives the collapse is a habit, not a spreadsheet.

Why does pressure distort decisions that calm analysis would get right?

Pressure narrows attention to the loudest signal in the room, which is rarely the most important one. Under real stress, working memory shrinks and the mind reaches for the first plausible option instead of the best one. That's not a character flaw. Gary Klein's recognition-primed decision model, built from field studies of fireground commanders, trauma nurses, and other people who decide fast for a living, describes it as how expertise actually works: experts recognize a workable option and pressure-test that one, rather than generating alternatives and comparing them. It's what the decision system does when the clock is running out.

US Air Force colonel John Boyd built his OODA loop, observe, orient, decide, act, around exactly this problem in the early 1970s: in combat, the pilot who cycled through that loop faster and more honestly won, not the pilot with the better plan going in. The insight generalizes past cockpits. Speed alone doesn't help. An honest orient step, run fast, is what helps.

I learned this on a mountain, not in a product review. Twenty minutes into a 36-hour climb in Utah, my watch read 163 beats per minute, a number I recognized as unsustainable for the fourteen hours still ahead of me. The instinct under pressure was to keep pace with the line of climbers around me. I'd already diagnosed the man ahead of me as pushing too hard before I'd looked at my own number. That's the tell: pressure makes you a sharp observer of everyone except yourself.

What is the orient-decide-act system for high-pressure moments?

Orient means naming your actual state and the actual stakes, out loud if you can, before you touch a decision. Decide means picking the smallest next move that matches what you just named, not the whole plan. Act means doing that one move, then orienting again. It's a loop, not a single choice.

The move that actually works under pressure depends on two things: how much the decision costs to get wrong, and how easy it is to reverse. I use a version of this table when I'm coaching a team through a launch decision or working out my own next move under a hard deadline:

Stakes	Reversible?	What to spend on "orient"	Right move
Low	Yes	Almost nothing	Decide fast, act, check the result
Low	No	A little	Decide fast, but name the one-way part out loud first
High	Yes	Enough to see the real risk	Decide fast, act, revisit on a short clock
High	No	As much as the situation allows	Slow the clock on purpose before deciding

Most bad decisions under pressure happen in that bottom-right box, treated like the top-left one. The stakes are real and the move can't be undone, but pressure makes it feel exactly like every other fast call that day. Naming which box you're actually in is the orient step. It takes seconds. It's also the step people skip first.

How do you practice decision-making under pressure before you need it?

You rehearse the orient step specifically, in a setting where a wrong call costs little: a simulation, a low-stakes deadline, a hard training day. The goal isn't to memorize answers. It's to make the habit of an honest self-check automatic before you're somewhere that habit is expensive to be missing.

This is the same argument I make about healthcare simulation technology: the equipment isn't the point, the rehearsal is. A clinician who has run a scenario forty times isn't smarter in the moment. They've already automated the orient step, so the decide step has room to work. The mountain taught me the same lesson with worse graphics. Stepping off the line at minute twenty wasn't a dramatic act of willpower. It was a rehearsed habit, built on easier days, firing on a hard one. I wrote the full account of that climb in The Sorting.

When should you slow down instead of deciding fast?

Slow down when the move is hard to reverse and the stakes are real. Speed is free when you can undo a bad call cheaply. It gets expensive fast on a one-way decision, and pressure is exactly when people default to fast, because fast feels like competence.

That's the part I'd push back on if I heard myself giving this advice five years ago. Fast isn't the virtue. An honest orient step, at whatever speed the situation actually allows, is the virtue. Sometimes that's half a second on a trail. Sometimes it's a day you buy yourself before a launch decision you can't take back. The system doesn't change. What changes is how much time the stakes earn you to run it.

I build this into how I think about product work now: reduce the problem until the next move is possible, then take it. Pressure doesn't remove that next move. It just makes people forget to look for it.

What Is POC in Software Development?

Wed, 19 Aug 2026 08:35:00 GMT

A POC, or proof of concept, is a small technical exercise built to answer one question: can this specific approach actually work? As of August 2026, after 15 years shipping platform software in regulated industries like healthcare, where "can this even work" had to be answered before anyone signed off on a budget, I still see teams confuse a POC with a small version of the finished product. It isn't sold, shown to real users, or judged on polish. It's built to remove one specific kind of doubt: technical feasibility, not market demand. Get that distinction wrong, and you either burn a quarter proving something nobody was worried about, or you skip the proof entirely and find out the hard way, mid-build, that the approach doesn't scale.

What is a POC in software development?

A POC, or proof of concept, is a small technical exercise built to answer one question: can this specific approach actually work? It isn't sold, shown to real users, or judged on polish. It exists to remove technical doubt before anyone commits budget or a team to building the real thing.

Here's what I keep coming back to: a POC answers exactly one question, and the discipline is picking that question correctly. "Can we sync this legacy database to a modern API without corrupting records" is a POC question. "Will customers pay for this" is not.

I've watched engineers spend three weeks polishing a POC's error handling and logging. None of that mattered. The only thing that mattered was whether the core mechanism worked, and every hour spent past that answer was an hour taken from somewhere else.

Why do teams build a proof of concept?

Teams build a POC when the biggest risk isn't whether users want something, it's whether the technology can deliver it at all. A POC answers that question cheaply, with throwaway code, before an engineering team spends months building on an assumption that turns out to be false.

In regulated platform work, that risk shows up constantly. Can this integration meet the audit trail requirements. Can this model run inference fast enough on the hardware a clinic actually owns, not the hardware a vendor demo used. Those are expensive questions to get wrong after the real build starts.

A POC is deliberately disposable. I've written POC code I knew would never see a production repository, because keeping it clean would have cost time the exercise didn't need. The only deliverable is the answer: yes, this works, or no, it doesn't, and here's why.

How is a POC different from an MVP?

A POC proves an approach is technically possible. An MVP proves people want the resulting product. A POC can be ugly, single-purpose, and thrown away. An MVP has to be a real product real users can actually use, because it's answering a demand question, not a feasibility one.

I wrote about this distinction in more depth in what an MVP actually is, but the short version is that these two terms answer different risks, and treating them as interchangeable stages of the same ladder is how teams lose months. A POC that works doesn't mean users want it. An MVP that users like doesn't mean the underlying approach will hold up at scale.

	Proof of Concept	Prototype	MVP
Question it answers	Can this be built?	What should this look and feel like?	Do people want this?
Shown to real users?	Rarely	Sometimes, for feedback	Yes, always
Built to last?	No, throwaway	No, throwaway	Yes, real product
Success measured by	Technical proof	Clarity of the flow	Real user behavior

I keep a version of this table in my head on every new platform effort. The moment a team can't say which column they're in, that's the moment the timeline starts slipping.

Proof of concept vs prototype: what's the difference?

The difference between a proof of concept and a prototype is what each one is trying to find out. A proof of concept tests one narrow technical unknown in isolation — often just a script or a spike, with no interface at all. A prototype tests how a whole experience feels or flows, usually with a visual interface a stakeholder can click through. A proof of concept proves capability; a prototype proves shape.

Put the shortest way I can: if the question is can we build this, you want a proof of concept. If the question is should it work like this, you want a prototype. They are not stages of the same ladder, and running them in the wrong order is how teams spend a quarter answering a question nobody was asking.

I use both, and I've seen teams reach for the wrong one more than once. A prototype in Figma or a clickable frontend answers "does this flow make sense to a human." It doesn't touch the hard backend question sitting underneath it.

A proof of concept skips the interface entirely, most of the time. Nobody needs a polished screen to know whether a batch job can process a million records in the maintenance window. That's a terminal output and a stopwatch, not a design review.

The three-way comparison further up — proof of concept, prototype, MVP — is the version of this I keep in my head, because the prototype question and the MVP question get confused just as often as this one does.

The numbers on this are worse than most teams assume. Gartner predicted in July 2024 that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, unclear business value, and escalating costs. A year later, MIT's Project NANDA reported that roughly 95% of enterprise generative AI pilots had produced no measurable P&L impact, against $30–40 billion in spending. In my experience the gap usually traces back to exactly this confusion: a team proved a model could technically produce an answer, then mistook that for proof the whole product was ready.

When should you skip the POC?

Skip the POC when the technical approach is already well established, like building a CRUD app with a mainstream framework, because there's no real feasibility doubt to resolve. Also skip it when the honest risk is whether anyone wants the thing, not whether it can be built. That's an MVP question.

A proof step earns its cost only when a real technical unknown exists, not as a default ritual before every project. I've sat in kickoff meetings where a POC got added to the plan out of habit, for an integration the team had built the same way a dozen times before. That's not risk reduction. That's a stalling tactic wearing a process badge.

The honest question to ask before scoping a POC is simple: what specifically don't we know how to do yet? If nobody in the room can answer that in one sentence, you don't need a POC. You need to start building, or you need to go find out whether anyone wants what you're about to build, which is a different exercise entirely, closer to what I described in what an MVP actually is.

The same discipline that says "prove the risky part first" is the same judgment call I wrote about in what AI has and hasn't replaced in software engineering: the tools can help you write the throwaway code faster. They can't tell you which question is actually worth proving.

I write more about how I make these calls, and about the fifteen years of specific mistakes behind them, on the About page.

What Is Healthcare Simulation Technology?

Tue, 18 Aug 2026 15:42:00 GMT

Healthcare simulation technology is the tools, mannequins, virtual patients, and VR scenarios that let clinicians rehearse high-stakes decisions before making them on a real patient, plus the feedback and facilitation that turn that rehearsal into real learning. As of August 2026, after spending most of my career building virtual patient simulations and immersive medical education products at WebMD, Medscape, and Shadow Health, I think the equipment gets too much of the attention and the system around it gets too little. The technology that matters isn't the headset or the mannequin. It's a four-part stack underneath: a realistic rehearsal scenario, structured feedback, skilled facilitation, and a change in the learner's confidence that outlasts the session. Skip any one layer, and the equipment is just an expensive prop.

What is healthcare simulation technology?

Here's what I keep coming back to: when people say "simulation technology," they usually mean the hardware. A high-fidelity mannequin that breathes and bleeds. A VR headset with a photorealistic patient room. A branching virtual-patient case with a hundred decision points.

I built products in that category for years. The hardware and content are real, and they matter. But none of it is the thing being purchased. What a hospital, a nursing school, or a medical education company is actually buying is a change in how a clinician behaves under pressure, later, when it counts. The mannequin is one way to deliver that. It's not the definition of it.

That distinction sounds academic until you watch two programs with the same budget produce different results, because one spent it on fidelity and the other spent it on the system around the fidelity.

What are the four layers of the simulation stack?

Rehearsal, feedback, facilitation, and confidence. Rehearsal lets the learner practice the decision, feedback tells them what their choice did, facilitation makes sure the lesson survives past the room, and confidence is the measurable change that outlasts the session. Skip a layer and the equipment is an expensive prop.

I think of it as a stack because each layer depends on the one below it actually working. Here's the map I use when I'm evaluating or building a simulation product:

Layer	What it does	What breaks without it	Example modality
Rehearsal	Lets the learner practice making the decision, not just watch someone else make it	The learner arrives at the real event never having made the call before	High-fidelity mannequin, VR clinical scenario, branching virtual-patient case
Feedback	Shows the learner what their choice actually did, during the scenario or right after	The learner repeats the same mistake because nothing ever corrected it	A mannequin's physiological response, a virtual patient's changing vitals or outcome
Facilitation	A trained person frames the debrief so the lesson generalizes past this one scenario	Learners leave defensive or numb instead of changed	A structured, trained-facilitator debrief, not a checklist read aloud
Confidence	The measurable shift in how ready the learner feels, and performs, on the next real case	The program looks busy on a dashboard but nothing changes at the bedside	Pre/post confidence and competency assessment

The rows that get funded first are almost always rehearsal and, sometimes, feedback. They're the visible, purchasable parts. Facilitation is a training and staffing problem, not a line item on a hardware quote, so it's the layer most likely to get squeezed when budgets tighten. That's an observation from building and buying in this space for over a decade, not a universal law. I've also seen well-resourced programs get it right.

How does simulation build clinical confidence, not just skill?

Skill is being able to perform the task correctly. Confidence is trusting yourself to perform it under pressure, which only comes from rehearsing the decision enough times that it stops feeling foreign. A well-run debrief is what converts one rehearsal into confidence instead of just a memory.

This distinction shows up constantly in nursing and clinical education research under the name debriefing, and it's the part of the stack I'd defend most if a budget forced a choice. The educator and researcher Pamela Jeffries built much of the modern academic framework around exactly this idea, that the structured reflection after a scenario is where the actual learning transfer happens, not the scenario itself.

I saw the same pattern building virtual patient products: a learner could get every decision "right" in a scenario and still walk away without more confidence, because nobody helped them connect the choice to the reasoning behind it. The scenario taught an answer. The debrief is what teaches judgment.

Where do simulation programs actually fail?

Most failures I've seen weren't the technology. They were budget going to fidelity, better mannequins, sharper graphics, while facilitator training and debrief time got cut. A photorealistic scenario with a rushed, unskilled debrief teaches less than a simple scenario with a great one.

That's my honest read after years on the product and platform side of this industry, and it's an inference from a lot of specific programs, not a claim I can attach a single statistic to. The pattern is consistent enough that I trust it: fidelity is the easiest thing to demo to a stakeholder, and the easiest thing to point to when justifying a budget renewal. A great debrief doesn't photograph well in a sales deck.

The other common failure is treating simulation as a one-time event instead of a rehearsal cadence. One scenario, run once a year, builds almost nothing durable. The confidence layer is a curve, not a checkbox, and it needs enough repetitions to actually move.

What should product teams test first before scaling a simulation program?

Test whether a single scenario changes a learner's stated confidence and decision-making on a follow-up case, before you invest in more hardware or more content. If the smallest version of the loop, rehearsal, feedback, facilitation, doesn't move that number, more fidelity won't fix it.

This is the same instinct I wrote about in what an MVP actually tests: find the cheapest version of the loop that can prove or disprove the hypothesis, before you spend real budget scaling the wrong thing. In simulation, the hypothesis is "this rehearsal, done this way, changes behavior." Test that with the smallest scenario you can build, a real debrief, and a before-and-after confidence check. Everything after that, more fidelity, more content, more seats, is scaling something you've already proven works.

It's worth asking the same question I keep asking about AI adoption in will AI replace software engineers: the tools in this space keep getting more capable, VR headsets cheaper, virtual patients more responsive, and none of that changes what the stack is for. Better rehearsal tools still need feedback, facilitation, and a way to prove the confidence actually moved.

I'm not writing this as clinical advice, and none of it is. It's a product and learning-design view from someone who spent most of his career shipping this category. Where the technical or research claims get more specific than my own build history, I've linked the source or kept the claim deliberately qualitative.

The equipment is the part anyone can buy. The stack is the part that has to be built.

I write more about how I make these calls, and the fifteen years of specific programs behind them, on the About page.

Internet Marketing Services. Delivered.

Mon, 17 Aug 2026 16:05:00 GMT

From the late 2000s until 2013, this URL sold internet marketing services to businesses in Raleigh, Durham, and Cary: web design, SEO, email campaigns, social media, and a contact form with a checkbox that read "I want to be #1 on Google." Then the agency era ended and the page went dark. The address spent a decade returning nothing. Google never stopped asking for it. My Search Console shows the crawler still requesting this exact URL in August 2026, flagging it as a missing page it expected to find. So the page is back, with the only honest answer I can give: every tactic it sold is dead, the lesson underneath them is not, and while I still take on a client or two when the fit is right, it works nothing like the page once promised.

What did this page used to sell?

Everything a small business wanted in 2010: web design, SEO, email marketing, social media, and results. The copy called Thinkkeno a results-oriented full-service agency that turned web clicks into customers. The contact form had a budget dropdown that climbed to $20,000+ and a checkbox that said "I want to be #1 on Google."

I wrote every word of it. Some of it holds up. Most of it reads like a time capsule from an internet that no longer exists.

The boldest line on the page: "On average, for every $1 spent on Thinkkeno services, our clients receive $10 in return."

I cannot produce the spreadsheet behind that sentence today. I am not sure I could have produced it then. Neither could most of the agencies writing sentences like it, which is the first thing to understand about the internet marketing era: the numbers were vibes wearing a suit.

The work itself was real, though. Real websites, real rankings, real restaurants full of customers who found them online. The independent decade in The Record is this page's receipts.

What happened to internet marketing?

The name kept molting: internet marketing became digital marketing, then growth, then performance marketing, and by 2026 the battleground moved to answer engines. Nearly every tactic this page sold is dead. What survived is the boring layer underneath: a real domain, verifiable work, and claims that hold up when a machine checks them.

Directory submissions died. Keyword density died. Exact-match domains, reciprocal links, press-release blasts: all gone. "Web clicks" stopped being a phrase anyone says out loud.

The promise on my own contact form aged worst of all. Nobody honest ever sold #1 on Google. Rankings were always rented, and the landlord kept changing the locks.

Here is what I find funny now. I still do search optimization, for this site. But the playbook inverted. In 2010 you chased the engine. In 2026 you try to be the thing engines can verify: one consistent name, claims with dates, pages that actually answer the question they rank for. Another page from this era got rebuilt for the same reason.

The tactics expired. The principle never did: be worth finding, and be easy to verify.

Why is Google still asking for this page?

Because search engines have long memories and URLs are promises. Google flagged this missing URL in July 2026 and was still crawling it in August, roughly a decade after the page went dark. Old links, old citations, and index history keep an address alive long after the business behind it is gone.

That fact stopped me when I saw it. The campaigns from this era are dust. The rankings are dust. The one asset that outlived everything was the address itself.

A URL is the only promise a website makes that can outlive the website.

So when Search Console showed a crawler politely requesting a page that died a decade ago, the right move was not a redirect. It was an answer. This is the third URL from the old site rebuilt at its original address, and it earned the spot differently than the others: not because a backlink points here, but because the machine kept asking.

Do you still sell internet marketing services?

Selectively, yes. The full-time agency closed around 2010 when I went inside the platforms: a decade-plus leading product at WebMD/Medscape and Elsevier. Today I build Keel, publish this site, and take on a small number of client engagements a year, when the fit is right. The form at the bottom of this page is how that conversation starts.

The longer version of that arc is on the about page.

Here is what changed between 2010 and now. Then, I needed every yes. The budget dropdown started at zero because the business could not afford to filter. Now the work has to earn the yes: a real problem, a number worth moving, and honesty on both sides about whether I am the right person to move it.

That honesty is the deliverable I recommend you demand from anyone you hire, me included: a person who tells you what they can't do. That was always the trick. It filtered the honest shops from the ones selling $10 back for every $1 in.

This page spent a decade as a broken promise at a good address.

Google kept asking. Here is the answer.

Delivered.

What Is MVP in Software Development?

Mon, 17 Aug 2026 08:36:00 GMT

An MVP, or minimum viable product, is the smallest version of a product that lets you test your core hypothesis with real users, not a smaller version of the whole finished thing. As of August 2026, after 15 years shipping products across healthcare, EdTech, and regulated systems, I still watch teams confuse the two, and build months of extra scope before anyone outside the company ever touches the thing. The term is older than the startup hype cycle around it. Frank Robinson used it in a product strategy context years before Eric Ries's The Lean Startup made it mainstream. The point was never speed for its own sake. It was learning the cheapest way possible, before you commit real engineering time to the wrong assumption.

What is an MVP in software development?

An MVP in software development is the smallest working version of a product built to test one core assumption with real users, not the smallest version of your finished vision. It ships fast, measures a real reaction, and tells you whether to keep building or change direction before you spend months finding out.

Here's what I keep coming back to: the word doing the work in that sentence is viable, not minimum. Minimum without viable is an unfinished product, nothing more. Viable without minimum is a slow, expensive way to learn the same thing.

I've watched teams build a beautiful, feature-complete first release and call it an MVP because it shipped early in the company's life. That's not what the term means. An MVP is defined by the hypothesis it tests, not by the calendar.

Why does the MVP pattern exist?

The MVP pattern exists because most product failure is a guessing problem before it's a building problem. Teams spend months of engineering time on features nobody asked for, then learn the mismatch after launch. An MVP moves that discovery earlier and cheaper, when a wrong guess costs weeks instead of a year.

The honest answer is that engineering time is the most expensive thing most product teams have. Every sprint spent building the wrong feature is a sprint you cannot get back, and a competitor you cannot out-guess forever.

The oldest version of this idea I know of, before either Robinson or Ries put a name on it, was a founder recording a short demo video of a product that did not exist yet, then measuring who signed up.

No code. Real signal.

That instinct, test the assumption before you build the machine, is the whole pattern.

How is MVP different from a prototype?

A prototype tests whether something can be built or how it should look, and it rarely touches real users or real data. An MVP is a real, working product released to real users to test whether they want it. A prototype answers a feasibility question; an MVP answers a demand question.

I use both, for different jobs. A clickable prototype tells you if a flow makes sense before you write a line of production code. It never leaves the building.

An MVP leaves the building on purpose. It has to, or it can't answer the question it exists to answer.

This is the same distinction I wrote about in emotionally intelligent design: a prototype can look right in a design review and still feel wrong in a real person's hands. You don't find that out until real users touch the real thing.

What's the difference between MVP and MLP (Minimum Lovable Product)?

An MVP proves people will use the thing enough to test your hypothesis. An MLP goes further and asks whether they love it enough to stay, tell a friend, or pay for it. MVP clears a validation bar; MLP clears a retention bar, and it almost always costs more to reach.

I think the MLP idea is a useful correction, not a replacement. Plenty of teams shipped a technically validated MVP that nobody enjoyed using, called the experiment a success, and then wondered why retention was terrible. Viable and lovable are different questions with different price tags.

Deciding which bar you're clearing, and being honest about which one you actually cleared, is a judgment call. It's the same kind of call I wrote about when I asked what AI has and hasn't replaced in software engineering: the tools can help you build either one faster. They can't tell you which one your team needs right now.

When shouldn't you build an MVP?

Skip the MVP pattern in regulated spaces, like medical devices or clinical workflows, where a half-built version can hurt someone before it can teach you anything. Also skip it when the demand question is already answered and the real risk is execution, not desirability. In both cases, minimum is the wrong axis to optimize.

I spent years in regulated health systems, where "ship the smallest thing and see what happens" is not a strategy, it's a liability. In that world, you validate the hypothesis a different way: paper workflows, closed pilots, stakeholders who can veto before code ships.

The MVP instinct is still there. The word "viable" means something stricter.

The same logic holds anywhere the cost of being wrong in public outweighs the cost of researching the answer in private.

So the honest definition is not "the smallest thing you can ship." It's the smallest thing that answers the question you're actually asking. Get the question wrong, and no amount of minimum saves you.

I write more about how I make these calls, and about the fifteen years of specific mistakes behind them, on the About page.

Will AI Replace Software Engineers in 2026?

Sun, 16 Aug 2026 17:00:00 GMT

No. As of August 2026, AI has not replaced software engineers, and the honest numbers say it is not close. What it has replaced is a layer of the work: the first draft, the boilerplate, the almost-right version of the routine parts. In Stack Overflow's most recent survey, 84% of developers were using or planning to use AI tools while only 3% highly trusted the output, and Google's DORA research found AI raising individual productivity while hurting delivery stability and throughput. That is not a replacement curve. It is a reorganization: the typing got cheap, and the parts that were always expensive got more valuable. The same answer holds whether you ask about software engineers, developers, or programmers. The pattern does not care about the job title.

Will AI replace software engineers?

No, not in 2026, and the trend does not point that way. AI replaces tasks inside the job faster than it replaces the job. Code generation is real and widely adopted, but production software still needs someone who owns what ships: someone accountable in ways a model cannot be.

After 15 years leading product and platform teams, here is the plainest version I can offer. The job was never typing. The job was deciding what to type, and standing behind it after it shipped.

AI came for the first half of that sentence. It has no answer for the second.

How many software engineers has AI actually replaced?

Fewer than the headlines imply, and the data is murkier than either side admits. Layoffs attributed to AI often mix cost-cutting, over-hiring corrections, and automation into one press release. The measurable data shows adoption, not replacement: Stack Overflow's most recent survey found 84% of developers using or planning to use AI tools, while 46% distrusted the accuracy of the output.

I cannot give you a clean replacement number. Nobody honest can.

What the research does show is stranger than replacement. Google's DORA program found AI adoption raising individual productivity, flow, and job satisfaction while negatively impacting delivery stability and throughput. Individuals speed up; systems wobble. That is not what a replacement curve looks like. That is what a powerful new tool being absorbed looks like.

What parts of software engineering has AI replaced?

The first draft. Boilerplate, scaffolding, test skeletons, glue code, and the routine translation of a clear spec into code. Anywhere the problem is already well-defined, the model is fast and usually almost right. That layer of the work is genuinely gone on teams that adopted.

Almost right is the operative phrase. In the same Stack Overflow data, 66% of developers named it their top frustration: solutions that are almost right, but not quite. Almost-right code still needs someone who can see the gap, and seeing the gap is a senior skill.

I wrote separately about what this shift does to developer identity. The short version: the anxiety is real, the obsolescence mostly is not.

What parts of software engineering can't AI replace?

Ownership. Deciding what to build, recognizing what almost-right misses, saying no to the wrong feature, and carrying the consequences of production failure. Each of those requires being accountable to reality, and accountability is precisely what a model cannot hold.

By early 2026, Stack Overflow's own analysis was framing developer skepticism as professional integrity rather than resistance, with trust in AI output falling even as adoption climbed. Engineers are not confused about this. They use the tools daily and believe them selectively, because they are the ones who answer for the result.

Someone has to answer for the software. That someone has a name.

The same logic runs through design, by the way. A system can generate the artifact. It cannot care what the artifact does to the person on the other side.

Should you still learn to code in 2026?

Yes, but learn it as a judgment discipline rather than a typing skill. Reading code, evaluating approaches, and knowing why a solution is wrong now matter more than syntax recall. The engineers thriving with AI are the ones who can review at the speed the tools generate.

That skill still starts with learning to code. You cannot audit a language you never learned to speak.

So the honest answer to the question in the title is no. And the more useful answer is that the question is aimed at the wrong layer.

AI did not replace the engineers. It promoted them, whether they asked for it or not.

A New Front-End Methodology: BEM

Sat, 15 Aug 2026 23:00:00 GMT

BEM stands for Block, Element, Modifier. It is a CSS naming methodology developed at Yandex around 2007, and in April 2012 an introduction to it ran on this site as part of a series covering the new front-end tools of the moment. Here is what happened next: almost everything else in that series died. The prefixers, the grid generators, the clever plugins. The naming convention is the thing that survived. Fourteen years later I am republishing this URL with a different argument than the original carried, because BEM turned out to be less about CSS than I understood at the time. It is a lesson about what makes conventions outlive tools, and it earned its place at this address.

What is BEM?

BEM stands for Block, Element, Modifier. A block is a standalone component: a card, a nav, a form. An element is a part that only makes sense inside its block: the card's title, the nav's link. A modifier changes a state or variant: the card, featured; the button, disabled. The names encode the structure.

In CSS it looks blunt: .card, .card__title, .card--featured. Nobody has ever called it pretty.

The official BEM introduction is still live and still says it plainly: standalone entities, their parts, and their flags. That is the whole system.

Why did BEM outlast the tools of its era?

Because it was a convention, not a dependency. The 2012 series this URL belonged to covered a prefix polyfill, a responsive framework, a drafts library, a grid generator. Real tools, genuinely useful, all requiring installation and faith in a maintainer. All gone.

BEM required only agreement.

A convention costs nothing to adopt, nothing to leave, and it keeps working when the build system changes underneath it. It travels in the heads of the people who use it. You cannot deprecate an idea that lives in naming.

There is a pattern here I keep meeting in product work too: the durable part of any system is rarely the machinery. It is the shared understanding the machinery was built to enforce.

Is BEM still relevant in 2026?

The syntax matters less now; the thinking still matters. Scoped styles and component frameworks do mechanically what BEM did by discipline: they guarantee that a component's styles belong to it. In that world, writing card__title by hand is solving a solved problem.

But the core idea was never underscores. It was making the relationships between parts explicit, in names a stranger can read. That idea is alive everywhere: design tokens, component APIs, file conventions. And plenty of the web still has no build step at all. CMS themes, static sites, inherited codebases. There, BEM remains excellent, unchanged, and free.

I wrote recently about emotionally intelligent design, and this is the same principle one layer down. Code has a human on the other side too. The next developer is a user.

Should you use BEM today?

It depends, but the honest answer has a shape. Greenfield component stack: adopt the discipline, skip the syntax; your tooling already enforces the boundaries. No-build site, CMS theme, long-lived codebase strangers will inherit: BEM is still one of the best answers available. Zero tooling. Total portability. CSS a newcomer can navigate on day one.

The 2012 version of this page introduced a new methodology. The 2026 version can say what the original couldn't know.

Tools are bets on a maintainer. Conventions are bets on people agreeing. Fourteen years later, the second bet paid.

The Sorting

Sat, 15 Aug 2026 22:00:00 GMT

You don't hear the sorting happen. It is just the sound of three hundred pairs of boots on hardpack, then the rhythm fractures. Twenty minutes in. Five hundred and fifty vertical feet. The mountain charges you for all of it up front.

The steps are cut high, each one a full lift of the body, the back leg driving, the quad taking the weight. You do one. Then you do it again. By minute fifteen the quads are burning, and there are fourteen hours of this above you, though you don't know it yet, or you know it and won't let it land.

A few keep their line, moving like the grade is a sidewalk. Most have dropped into mouth-breathing now, making sounds they don't hear themselves make. A few have already stepped off.

You cannot slow down in place. Three hundred people are climbing a single line of trail, and if you drop your pace you become a wall the rest of them have to climb around. So you don't get to slow quietly. Your only move is a few steps to the right, off the line, where you stand and let the herd go by.

The first man to step off, twenty yards above me, turned down the slope as he did it. Raised his bottle. Drank. Maybe he was thirsty. The man beside him had stopped to look at the sunrise, which had come up orange and huge over the valley and was, in fact, worth looking at. You don't ask.

I had him diagnosed — rate too high, needs to come down — before I looked at my own watch.

One sixty-three.

Not a number you hold. Not for fourteen hours.

I took a couple of high steps to the right, off the line. Let two runners and a trekker pass. Got my bottle. Turned and faced the valley and the orange coming up over it. I drank water I didn't need, and kept my eyes on the view, not on the people coming up the trail behind me.

It was lap one. The mountain went up into the light and kept going, past where I could see.

From the notebook. I diagnosed another man's pace before I looked at my own number. That order is the whole problem, and not only on mountains. The accurate reading of yourself is the most useful data you own, and it is the one you resist taking. Stepping off the line on purpose was the first honest decision of the day. There were fourteen hours left.

Give Your Website Soul with Emotionally Intelligent Interactions

Sat, 15 Aug 2026 16:00:00 GMT

Emotionally intelligent design is the practice of building interfaces that acknowledge the human on the other side of the screen: their anxiety, their context, and their limits. It is not decoration and it is not persuasion. I published the original version of this article in 2012, back when "delight" was the word of the year. Fourteen years, several platforms, and one AI wave later, the argument matters more, not less. Software can now generate itself. What it still cannot do is care whether you succeed. The sites that feel alive are the ones built by someone who imagined a specific person, at a specific moment, feeling a specific thing. That is the soul. It was never the animations.

What is emotionally intelligent design?

Emotionally intelligent design means the interface responds to how a person feels, not only what they click. It anticipates anxiety at high-stakes moments, owns its failures in plain language, and remembers what you already told it. The test is simple: does the system behave like it knows a human is present?

In 2012, the fight was against decoration. Glossy buttons pretending to be feelings.

Today the fight is against scale. Interfaces are cheaper to produce than ever, and it shows. A generated page can be correct in every detail and still feel like nobody is home.

How do you design for emotion without manipulation?

Design for the user's emotional outcome, not your conversion metric. Manipulation engineers a feeling to extract a behavior. Emotional intelligence reduces fear, restores control, and tells the truth about limits. If the emotion you are creating only benefits you, it is persuasion wearing empathy's clothes.

Don Norman's three levels of emotional design explain why the cheap version fails. Nielsen Norman Group's account of divorcing a Nest thermostat traces the arc: visceral charm wins the purchase, behavioral betrayal ends the relationship.

Charm gets you the first week. Behavior gets you the years.

What are the 5 patterns of emotionally intelligent design?

Five patterns cover most of it: acknowledgment (the system notices you), proportion (the emotional register matches the stakes), honest failure (errors own the fault and name the fix), anticipation (calm at the anxious moments), and memory (never making someone repeat what they already said).

Acknowledgment. Confirmation that a human arrived, not a session. A form that keeps your work. An error page that speaks like a person.
Proportion. No confetti for trivial actions. No dead neutrality at painful ones.
Honest failure. "We broke something, here is what to do" beats a cheerful shrug every time.
Anticipation. Loading states, empty states, and irreversible actions are where anxiety lives. Design those first.
Memory. Asking twice for the same information tells people the system was not listening.

In my product work, I measure time-to-confidence: how fast someone knows their next action. These five patterns are how an interface shortens it.

How is emotionally intelligent design different from persuasion?

Persuasion moves people toward your goal. Emotionally intelligent design moves people toward theirs, with less fear along the way. The two can coexist in one product, but they carry different tests: persuasion is measured in conversion, emotional intelligence in trust that survives a failure.

Aarron Walter's Designing for Emotion made the case in 2011 that personality is how people form relationships with software. The 2020 second edition added what the first era undervalued: privacy and representation are emotional design too.

This is about to matter more. I wrote recently about what AI tools are doing to developer identity, and the same shift applies to interfaces: when every product can talk, the ones that listen will stand apart.

Fourteen years later, I would compress the whole argument to one line.

People do not remember your interface. They remember how it treated them.

What Is AI Anxiety for Developers (and Why It's Misunderstood)

Sat, 15 Aug 2026 14:00:00 GMT

AI anxiety for developers is the fear that your skills are becoming obsolete as AI tools get better at writing code. It is not the same thing as general fear of AI. Most developers are not losing sleep over runaway superintelligence. They are sitting with a quieter question: if a model can produce in eight minutes what took me four hours, what am I for? That is an identity question wearing a technology costume. That is why most advice about it misses. The honest answer is not that the tools are overhyped, and it is not that you should retrain into something else. It is that your value was never really the typing, and the typing is what got cheap.

What is AI anxiety for developers?

AI anxiety for developers is the specific worry that AI coding tools will make hard-won programming skills less valuable. It shows up as quiet dread during tool rollouts, defensiveness in code review, and compulsive comparison against AI output. It is about professional identity and worth, not about the technology itself.

After 15 years leading product and platform teams, I've watched several waves of "this changes everything" arrive. This one is different in one specific way: it aims at the part of the work developers use to measure themselves.

Nobody built an identity around typing speed. People built identities around craft.

How is developer AI anxiety different from general AI fear?

General AI fear is about what AI might do to the world — jobs, misinformation, safety. Developer AI anxiety is about what AI is doing to you, this quarter, in your own editor. It is nearer, more personal, and more useful: you can actually act on it.

Most AI anxiety in dev teams isn't about the model. It's about identity. The developer who built a career on craft is now being told craft is automatable. That lands harder than any layoff memo.

The distance matters. Abstract fear paralyzes because there is nothing to do with it. This fear is specific. It can be worked.

What causes AI anxiety in software teams?

In teams, I see three patterns driving much of it: leadership announcing AI adoption without saying what it means for roles, tools that produce almost-right code that still needs senior judgment, and silence, because nobody wants to admit out loud that they are scared of the thing they are being told to celebrate.

The numbers say adoption and doubt are rising together. In Stack Overflow's most recent developer survey, 84% of developers were using or planning to use AI tools, 46% distrusted the accuracy of the output, and 66% named the same top frustration: solutions that are almost right, but not quite. By early 2026, Stack Overflow's own analysis of that gap was calling the skepticism professional integrity, not resistance.

Adoption without trust is the exact recipe for anxiety. You are required to rely on something you are not allowed to fully believe.

How do you overcome AI anxiety as a developer?

Name it as an identity question, not a skills gap. Then move your sense of worth up a level: from producing code to owning judgment — what to build, what almost-right misses, what production actually requires. The developers who do that are positioned to become more valuable as the tools improve, not less.

Here's what I recommend to teams I work with. Use the tool on real work, not demos. Keep a private list of what it got wrong and what shipping that wrongness would have cost.

That list is your job description. It always was.

I spend my own bench time on robotics and physical AI, where this is unusually honest: the wheel turns or it doesn't. Software lets almost-right hide. Production doesn't. Knowing the difference is the skill.

Does AI anxiety mean you should stop using AI tools?

No. Avoidance feeds the anxiety and costs you the fluency that makes the fear manageable. Use the tools on real work, with your own review standards, and let the evidence replace the dread. The 66% almost-right problem is precisely why your judgment stays load-bearing.

I took the replacement question head-on in Will AI Replace Software Engineers in 2026? The short answer is no. The long answer is about what the job actually is.

The anxiety is real, and pretending otherwise insults people's intelligence. The obsolescence mostly isn't. Not for developers who move their identity from typing to judgment.

The model can perform the typing. It cannot own the consequences. That part was always the job.

Opening the notebook

Fri, 14 Aug 2026 00:00:00 GMT

The homepage of this site describes a workshop: rooms for product strategy, physical making, fiction, endurance, and decision systems. A workshop produces scraps — half-finished thoughts, patterns noticed mid-build, lessons that only show up under load. This notebook is where those scraps get written down.

The return

This is a return, not a beginning.

From 2005 to 2014 I published constantly: web design, internet marketing, new tech, all things web. One of those articles is back at its original 2012 address, refreshed for what the argument became.

Then life rearranged itself. A heavy acquisition made the work much bigger, the hobbies shifted around, and three amazing kids arrived. In 2018 I wrote a book about that stretch of acquisitions.

Late last year I started something I had wanted to do for a long time: my first novel. It Held is in its last mile of polish now, with a goal of publishing it by September 15th.

Writing came back. So the notebook came back with it.

How it gets written

The engine runs differently this time.

I use AI as a personal scribe. It interviews me periodically, we ping-pong on a subject until it sharpens, and the result becomes a post. Nothing publishes until I have read it, edited it, and merged it myself.

The judgment stays human. The drafting gets help.

That approach is faster than the 2005 version of this ever was, and it lets me broaden the aperture: product leadership, confidence systems, physical AI, endurance, travel, repair, and whatever else the workshop produces. More range, same standard.

Expect notes on the things I actually spend my days on: turning uncertainty into confident action, building Keel, teaching software to touch the physical world, and what long efforts in the mountains teach about decisions under pressure.

Short notes, published when they're ready. That's the whole contract.