A forecast asks to be judged on whether it came true. An assumption is a working rule: what we act on until the evidence says otherwise. We write ours down so that we notice when they stop being true, and so that readers can hold us to them. Each entry names an observable condition that would make us drop it. Some of these will be wrong by summer.
| 01 | Capability will keep running ahead of adoption inside companies. The Census Bureau found 19.8 percent of US businesses using AI in the period ending May 3, 2026, and McKinsey’s 2025 survey found nearly two-thirds of organizations had not begun to scale it. In our client work the slow part is rarely the model. What would change our mind: the Census survey showing more than a quarter of US businesses using AI by the third quarter of 2027, or a client putting a new system into daily use within a month without being pushed. |
| 02 | Model leadership will keep rotating, so portability will matter more than picking the right lab. Sam’s own preferred model changed several times between May and September 2026. In late September our whole team moved its default work from one lab to another within days of a release. People who keep their instructions and finished work in plain files tell him the switch takes about an hour. What would change our mind: one lab holding a clear lead in our team’s daily work for two consecutive quarters, or a lab shipping a memory or agent feature that is plainly better and can’t be exported. |
| 03 | The cost of moving off software will keep falling. “It’s never been easier to migrate anything, and it’s only going to get easier from here,” Sam told a client in September. He has described data migrations that “used to take six months” and that Runpoint can now “do in a week.” When leaving is cheap, rented software loses its hold, and owning your own becomes a realistic option for companies that never considered it. What would change our mind: our own migrations running past their estimates for two quarters in a row, for reasons faster tools couldn’t fix. |
| 04 | For most mid-market work this year, ordinary software built quickly with AI will beat agents doing the work. The best use of AI we see is usually building ordinary software faster, rather than having a model do the work itself. Deterministic software gives the same answer to the same input every time, which is what a controller or an auditor wants. Agents earn their place at the steps that need judgment. What would change our mind: an agent running a judgment-heavy workflow end to end for a full quarter, at an error rate no worse than that of the people who did it before, at a client that isn’t a software company. |
| 05 | Slow decisions and unwritten knowledge will set the pace of AI projects, and the code will keep getting easier. On our projects, writing the software now takes less time than getting people to explain how the work runs and getting executives to answer questions about it. What would change our mind: a quarter in which our projects spend more calendar time waiting on engineering than on client decisions and interviews. |
| 06 | Executives will keep describing AI as a way to grow without adding people, and cuts will stay the exception in how they talk about it. The owner of an industrial distributor asked us whether he “could add 15 people and not even feel it when it comes to overhead.” A chief executive told us this month, “I don’t want to look at it as an efficiency project.” Counterexamples exist. One prospect in 2025 named “targets for optimization and headcount reduction. Let’s be honest.” What would change our mind: headcount reduction becoming the stated goal in more than half of our new executive conversations in any quarter. |
| 07 | Whether an AI system is safe will depend on how it is built far more than on whose model it uses. Sam’s version, for a room of chief executives: “It is possible to make these things safe. It is not default safe… It’s really about how you architect these systems.” In practice that means human approval before consequential actions, narrow permissions for each task, audit trails that let you reverse a mistake, and limits on how much any one agent can touch. What would change our mind: a serious incident in a well-built deployment, traced to a vendor failure those safeguards could not have contained. |
| 08 | Arming a few strong operators will beat licenses for everyone. The person to back is the one who taught themselves spreadsheet macros because the job needed it. Rolling licenses out to a whole company because the board asked for AI tends to multiply bad judgment along with good; “Arm the Few,” which follows, makes the case at length. Sam suggests starting with roughly a tenth of the staff and giving them generous access. What would change our mind: a client that gave everyone access showing more measurable output after two quarters than a comparable client that armed a small group. |
| 09 | Prototypes will stay cheap, and production will stay where projects fail. One Austin venture firm we worked with had more than ten apps going “straight from local to deployment,” with no source control, and a rollout finished at the last minute broke during its flagship event. At another client, a coding agent changed 140 files, deployment workflows included. The first version takes days now. Making it reliable takes most of the project. What would change our mind: hardening, testing and rollout falling below a third of the hours on our projects for two straight quarters. |
| 10 | One-on-one, in-person teaching will beat workshops. A 20-person workshop we ran taught people something. Two one-hour sessions in person, one or two executives at a time, got them producing. Much of the friction is small and individual, an IT approval here and an email connector there, and a room of 20 can’t wait for each person’s. What would change our mind: a group cohort in which most participants are still using what they built sixty days after the last session. |