Simon Willison published “Feeling Sad About AI” on September 11. Willison is not a doom-poster or a skeptic. He is one of the most careful, even-handed observers of what these tools actually do in production, and his takes tend to age well precisely because he tracks reality rather than a narrative. The piece deserves attention because it holds two things at once: genuine appreciation for what current models can do, and genuine unease about the environmental costs, the labor displacement questions, and the difficulty of maintaining clear-eyed engagement when the trade-offs are real and in tension with each other.
He is not telling anyone what to think or how to feel. He is naming the discomfort honestly and asking what to do with it. That is worth paying attention to, because he is describing what a significant portion of the practitioner community actually experiences — and that almost nobody in mainstream technology coverage will say plainly.
There is a pattern in how organizations handle that discomfort. It either gets acknowledged and integrated into how decisions are made, or it gets suppressed in favor of a simpler story — that AI is obviously good and concerns are obviously overblown. The first path produces better governance. The second produces surprises at the worst possible moment.
mindmap
root((Governance<br/>that earns trust))
Environmental accountability
Energy audit baseline
Offset strategy
Labor displacement
Role evolution plan
Reskilling investment
Data ethics
Audit trail
Human review gates
Organizational ambivalence
Practitioner input loops
Explicit ownership
For engineers: the discomfort is a quality signal, not a distraction
If you are building seriously with AI tools — using them in production, depending on their output, designing systems around their capabilities — and you feel some weight from that, you are paying attention. The engineers who navigate this era well are not the ones who resolved their ambivalence quickly in either direction. They are the ones who let the discomfort do its job as a design input.
What that looks like in practice: they build audit infrastructure they would not bother building if they fully trusted the system. They design human review gates at decision points where errors matter. They are explicit about which calls the AI makes and which decisions stay with the engineer. They treat AI systems the same way they would treat any system where the stakes are real — with instrumentation, failure modes thought through, and clear accountability for outcomes.
The engineers who dismiss the discomfort and ship fast tend to produce systems that work until they do not. The engineers who let the discomfort shape their architecture tend to produce systems that hold. Neither group is building carelessly. Only one is building with an honest model of what can go wrong.
For business owners: what your team is feeling is probably pointing at something real
If your leadership team is expressing mixed feelings about AI — some enthusiasm, some discomfort, real uncertainty about pace and governance — resist the temptation to read that as friction to be managed through. The ambivalence is almost always pointing at something that has not been resolved.
The organizations that build durable AI programs are the ones that asked uncomfortable questions early, when they still had design flexibility: What work are we automating, and what does that mean for the people doing it today? Who is accountable when an AI-driven decision turns out to be wrong? What are our obligations around data use, and have we actually read what we agreed to? What happens when the system breaks?
Those questions do not cost you time if you take them seriously early. They cost you significant time and money if you hit them reactively — after the system is embedded in operations, after the team has organized around it, after the political cost of changing it has compounded. The organizations struggling with AI governance in the second half of 2026 are almost uniformly the ones that skipped this conversation in the first half.
The practitioners expressing discomfort on your team are not the problem. They are the early warning system. What they are pointing at deserves a real answer.
My take: the weight of the decision is what governance is built on
Willison is describing something I have encountered in nearly every serious technology engagement: the practitioners who feel the stakes of a decision tend to be the most rigorous builders. The discomfort is usually evidence of awareness, and awareness is what governance is built on.
I dealt with a direct version of this at a class-action settlement administration company where I served as principal architect. We built a case management application that sat between legal teams representing opposing parties — technically sound, carefully designed, with real thought in the architecture. What we did not resolve early enough was the access model: which parties could see which case data, how the neutral position of the platform translated into specific permission boundaries, and whether the stipulations of individual court cases created exceptions to the general rules.
Those were uncomfortable questions. They surfaced real tension between stakeholders, touched on the legal structure of the engagements, and required decisions that nobody particularly wanted to make while the project was still in flight. So we deferred them. The project paid for that deferral when we were 80 percent through the build — the political and legal questions came back as blockers at a stage when resolving them cost substantially more than it would have cost to work through them at the beginning. We delivered a technically solid product. The governance infrastructure was not solid, because we had not forced ourselves to sit with the discomfort early enough to build it properly.
AI governance is running the same pattern at scale. The developers and operators who feel the weight of the environmental costs, the labor questions, the data ethics, the accountability gaps — they are not obstacles to deployment. They are the people best positioned to build governance that functions under real-world conditions, because they are already thinking about the failure modes. Willison’s piece deserves to be read as a design brief.
