Tech and me

The Demoscene Was Built to Push Computers. Why Stop at AI?

2026-08-23T13:20:22.884+02:00

TL;DR: This Easter I released my first full PC demo at The Gathering 2026. body.mod placed third. I used AI to help write the code, generate 2D assets and turn some of them into 3D. The music was composed by a human musician in Crusaders. Some demoparties would disqualify the result because they treat the production method as proof of creativity. I think that confuses craftsmanship with creativity. Both matter, but they are not the same. Keep dedicated categories where a specific craft or constraint is what competitors are being asked to demonstrate. For general demo compos, disclose how each production was made, and then let the audience judge them together.

In 1993, at a demo party, I coded a sine scroller. A pretty bad sine scroller. In Turbo Pascal.

That was more or less the peak of my demo coding career.

By then, the demoscene had already travelled from the Commodore 64 to the Amiga, and the PC was becoming a serious demo platform. Each machine changed what we could create. The Commodore 64 invited people to exploit every cycle, sprite and quirk of its sound and graphics chips. The Amiga brought richer graphics, sampled sound and hardware that felt built for audiovisual experimentation. Then the PC arrived with faster processors, graphics cards and a moving target of possibilities.

The scene adapted every time.

I was never a great demo coder. I was not particularly good at 3D either. I understood what I was looking at, and I had opinions about what was good, but there was a large gap between the demo I could see in my head and the one I could build with my own hands.

Thirty-three years later, I entered a PC demo at The Gathering 2026. It was called body.mod, it placed third, and it was the first demo I had attempted to create end to end myself.

The title was a small demoscene-and-aging pun. A .mod is a tracker music module, but at my age the body may need a few modifications too. Add a touch of cyberpunk body modification, and body.mod felt about right.

It is by no means a great demo. It was my first serious run up the learning curve.

The difference was AI tooling.

That sentence alone will make some demosceners stop reading. I hope they keep going.

Because this is not only a story about how I made one demo. It is about whether a scene built around exploring computers can evolve when the computer becomes a collaborator.

A very short introduction to the demoscene

For anyone outside the scene: a demo is a real-time audiovisual production. It is an executable program, not simply a rendered video. Code generates the visuals while music, graphics and effects are pulled together into something that can be abstract, funny, beautiful, technically impossible-looking or occasionally all four.

The demoscene grew out of the crack intros of the early home-computer era. Groups competed to create increasingly impressive introductions, then started making stand-alone demos where the art and technical achievement were the entire point. The scene developed its own groups, handles, parties, archives, status and language. We call competitions compos. Coders, musicians and graphicians form groups and release productions under group names.

I am Wobba of Crusaders.

The scene has shaped me far beyond the code I did or did not write. I spent years as a compo organizer at The Gathering. I learned by watching other demos, talking to people, sharing ideas and seeing what the people around me could make a computer do. I am still learning that way.

In the early scene, pushing the hardware mattered enormously. How many objects could you put on screen? Could you make the machine do something everyone thought was impossible? Could you fit a complete audiovisual experience into 64 kilobytes, 4 kilobytes or less? Those constraints still produce some of the most impressive work in computing.

But when I stood in the audience, I rarely understood every trick behind the code.

I saw the result.

I saw the effects, the sync, the pace, the atmosphere and sometimes a story. A brilliant technical achievement could make me admire the coder. A brilliant demo could make me feel something.

Those are related, but they are not the same thing.

What changed for me

Today I work as a product manager, architect and programmer in enterprise software. Earlier in my career I worked as a computer game designer. I know programming, graphics and game fundamentals. I can reason about systems. I can debug. I can tell when a visual effect is wrong even when I cannot immediately write the mathematics that will make it right.

Before AI, making the demo I wanted would normally have required a team. A strong graphics programmer. Someone comfortable with geometry and 3D mathematics. A 2D artist. A 3D artist. A musician. Perhaps a dedicated designer or director to pull the parts together.

That team structure has produced decades of wonderful demos, and working with talented people still makes ideas better. Creativity feeds on other creativity.

But I do not have all those people sitting around me every evening.

What I do have is an RTX 5090, Nvidia's flagship consumer GPU, local image models, tools that can convert 2D assets into 3D, and coding agents that can turn a detailed description into C++ I can run, inspect, reject, debug and improve.

I am over 50 now. Unlike the version of me who coded that bad sine scroller in Turbo Pascal, I finally have the means to go slightly overboard on the hardware. Some people buy a sports car. I bought a GPU and started making demos again.

For body.mod, I used those tools layer by layer. I started with an idea. I worked out the parts and effects. I generated and refined visual assets locally. I turned some 2D material into 3D. I explained the motion, timing and composition I wanted to coding agents, then ran what they produced and pushed it closer to what I had in mind.

That took many turns and more than a few late nights. Prompting in this kind of flow feels a lot like coding: describe, run, inspect, adjust, repeat. Rinse and repeat until the visuals are not merely plausible, but as close as I can get them to what I saw in my head.

The music was not AI-generated. It was made by a musician in Crusaders, the group I am part of. That contribution did what collaboration has always done in the scene: it added someone else's domain skill and creative perspective to mine.

The rest did not happen in one prompt.

Not even close.

Prompting is not pressing a button

There is a persistent fantasy about AI-assisted work where someone writes "make me an awesome demo," waits thirty seconds, and submits whatever comes out.

That is not how I work.

I have spent many hours on my current production. I develop one part, run it, find what is wrong, explain the problem, try a different approach and repeat. Sometimes the model misunderstands the visual. Sometimes it produces code that is technically plausible but aesthetically useless. Sometimes fixing one glitch creates two new ones. Sometimes I throw away an entire direction.

Conveying a visual idea to a language model is surprisingly hard. Yes, it can inspect an image and describe what it sees. That does not mean it understands the image in the same way I do, or knows which part of it matters to the experience I am trying to create.

I have had to learn how to describe movement, camera behavior, light, material, scale and timing. I have had to learn when words are not enough and a rough reference image communicates more. I have had to build a feedback loop where the agent proposes, I evaluate, and we move another step toward the target.

I am still learning and adapting as the tools change and as I discover where my own process is weak. body.mod taught me what to ask for, what not to accept and how much work still sits between a plausible first output and a demo I am willing to release.

Had I ever heard of Gaussian splatting before I started researching how to approach 3D in my next demo? No. Now I have. The tools did not merely produce an answer. They helped me discover a technique, understand what it could do and add it to the set of ideas I can draw on. The next time I face a 3D problem, I start from a wider base than I did before.

That is a skill.

It is not the same skill as writing a renderer from scratch. It does not deserve the same credit as squeezing an impossible effect into 4K. But "not the same craft" is different from "not a craft."

I am closer to the director than the camera operator

The best description I have found for my role is director.

A film director does not operate every camera, build every set, sew every costume, create every visual effect or perform every role. Christopher Nolan and Martin Scorsese work through people with deep specialist skills. We still consider them creative because creativity also lives in the idea, the selection, the direction, the pacing and the judgment about what belongs in the final cut.

I am not comparing my demo to a Scorsese film. I am comparing roles.

When I work with AI tools, I direct a strange little production crew. I explain what I want. I review what comes back. I keep the parts that move the production toward my idea and reject the ones that do not. I change my mind when an experiment reveals something better. I take responsibility for the final result.

Could I explain every line of the generated C++ code? Probably not.

Can every film director explain the wiring of every light on set?

The more useful question is whether I understand enough to direct the work, judge the result and fix the problems that stand between the current version and the demo I want. My background matters enormously here. Without programming knowledge, I would not know what to ask for when the frame rate drops. Without graphics fundamentals, I would struggle to explain why the camera, material or composition feels wrong. Without years of watching demos and working with computer games, I would have less instinct for pacing and effect.

Taste is not implementation skill. But implementation skill is not the only form of authorship.

Creativity is not the same as craftsmanship

I have written before about a developer colleague who loves the complete arc of programming: sitting down with a problem, thinking it through and writing the code himself. For him, the craft itself is the point. Handing part of that arc to an agent removes something he came to work for.

I respect that.

The same is true in the demoscene. In a 4K intro, the constraint and the code are inseparable from the work. In a graphics compo where entrants submit working stages, the manual process is deliberately part of what is being judged. In a tracked music compo, opening the module and studying how the musician constructed it is part of the culture.

Some compos should absolutely protect a particular craft.

The mistake is turning that into a claim that everything made with different tools is uncreative.

Was Edvard Munch great because of technique, creativity or both? What about Picasso? We can admire the brushwork, the experimentation, the composition, the emotional effect or the break with convention. Different viewers value different parts. Art has never had one clean unit of craftsmanship.

Neither has the demoscene.

Think about ships.

We can admire a reconstructed Viking ship built with period tools, traditional materials and knowledge passed down through generations. The process is part of the achievement. We can also admire a modern hydrofoiling catamaran designed with computer simulations, scientific measurements, carbon fiber and detailed models of drag and friction. One demonstrates historical craftsmanship. The other combines design, science, engineering and modern tooling to move across water in a way the Viking shipbuilders could not have imagined.

One is not better than the other.

They are interesting for different reasons, and which one moves you more is partly taste. We do not claim the modern boat lacks creativity because its designers used simulations instead of shaping every component by eye.

The same distinction already exists in the demoscene. A 4K or 64K intro is explicitly about constraint. How much can you cram into an absurdly small executable? The size limit is not a side note. It is part of the work.

Graphics compos have already evolved this way. Pixel and old-school graphics still exist alongside digital graphics, 3D renders and combinations of techniques. We did not have to decide that one method was creative and the others were not. We made categories, wrote rules and kept creating.

If a compo wants to celebrate hand-written code or hand-drawn pixels, say so clearly. Call it handcrafted. List the allowed tools. Make the process an explicit constraint in the same way we make file size and hardware explicit constraints.

But do not shut people out simply because their way of creating does not fit the current rulebook. Rules can evolve, categories can be added, and a general demo compo should still be able to judge demos.

The scene already has a precedent for this: the Wild compo. It created room for productions that did not fit the normal platform or format rules. Use any tool, any hardware and any idea; make something creative that can be recorded and shown on the big screen. When creativity outgrew the existing boxes, the scene built a bigger box.

An AI-assisted demo could perhaps compete in Wild. If that were the only category open to me, I would submit it there. But that still feels wrong. A real-time PC demo does not stop being a demo because an agent helped write the code or generate some of its assets. Wild should be for work that is wild in form, not a waiting room for demos made with tools the main compo has not accepted yet.

The parties are already choosing different answers

The Gathering 2026, where I released body.mod, used a deliberately pragmatic rule:

"Entries with primarily AI-generated content are not allowed. AI may be used for assistance, but the majority of the entry must still be the competitors' own work."

Did I break that rule?

I do not believe I did. My interpretation is that AI was tooling inside a production I initiated, directed, iterated on and took responsibility for. The concept, selection, composition, feedback loops and countless decisions were mine. The music came from Nightshade in Crusaders. The tools helped me implement the production. They did not choose what to make, decide which results were good enough or take responsibility for the finished demo.

Could someone read "primarily AI-generated" differently, especially if they count lines of code rather than creative decisions? Certainly. That ambiguity is part of the wider debate. What I like about TG's rule is that it at least tries to distinguish assistance from substitution and leaves room for organizers to make a judgment about the whole work. It is pragmatic rather than ideological.

Assembly Summer 2026 has chosen a practical transitional model. Its traditional demo compos do not allow AI-generated code, graphics or music. It also has a separate AI Coding (Vibe Demo) competition where AI may write up to 100% of the code and assets may be human-made or AI-generated. The entry must still be an executable real-time production, not a single-shot prompt output, and entrants must submit a readme.txt describing the AI tools they used.

That is better than a ban.

But I am no longer convinced a separate vibe coding category is the right destination.

It protects the traditional production method while giving the new one a stage, but it also risks turning AI-assisted demos into a side show. The label starts judging the tool before the audience has seen the production. A weak AI-assisted demo is still a weak demo. A strong one should not need a separate definition of strong.

The 2026 results also make another point. Rasteriunelma by Doomsday won the AI Coding compo. Before Zero by Byterapers and friends won the regular Demo compo. To my eyes, Before Zero is in a completely different league. It is simply a much better demo. AI did not magically level the field or make traditional skill irrelevant. If anything, putting the productions side by side shows how far AI-assisted creators like me still have to go.

The Gathering and Assembly both held their first events in 1992. These are not newcomers chasing a trend. They are old-school institutions that have survived because they adapted as computers, creative tools and communities changed. Making room for AI does not require abandoning their history.

Other established parties have chosen blanket bans. A check of published 2026 rules finds several parties in Germany and Sweden prohibiting generative AI across their compos, sometimes with narrow exceptions for minor assistance. Organizers are allowed to draw those lines. They do a huge amount of unpaid work, and categories with clear rules are a healthy part of the scene.

My concern is not that every compo must allow every tool. It is what happens when the scene as a whole offers no place for people using the tools that increasingly define how computers are used.

Disclosure is not a problem for me. I am proud of the process. Tell the audience what tools were used. Let them decide what the process means when they vote.

AI did not have my idea

I do not believe an LLM is creative by itself in the way a person is creative. It knows patterns from its training. It can combine them in useful and surprising ways, but it does not sit at a demo party in 1993, remember a sine scroller, spend decades gathering experience, then decide it finally wants to make the demo it never had the technical range to build.

That part came from me.

Of course my ideas also come from things I have seen, heard and experienced. Human creativity is not created from a vacuum either. We build on references, culture, technique, accidents and other people. For this article I am deliberately leaving the training-data debate to one side. It matters, but it is a different argument. Think of training here as experience on steroids.

The question in front of me is simpler: when a human has the idea, directs the process, evaluates every iteration and owns the result, does using AI make the work non-creative?

I cannot see how.

The human is still the proponent

At Microsoft we have gone deep into AI-assisted work. Production code is written with AI, directed and reviewed by humans with domain knowledge. It works. It can be stable, maintainable and efficient.

The tool is not the proponent or opponent of quality. Humans are.

The same tool can produce generic filler in one person's hands and something thoughtful in another's. The difference is not that one model suddenly became creative. The difference is the idea, context, taste, direction, iteration and willingness to reject mediocre output.

AI closes capability gaps. It lets one person attempt a production that previously needed a larger team, in much the same way better cameras, editing software and visual-effects tools have lowered the budget needed to make a film. A low-budget film is not automatically worse than a high-budget one. It is made under different conditions.

Would I create a better demo together with excellent coders, graphicians, 3D artists and musicians? Very possibly. Their experience would broaden my ideas, challenge my taste and take the work somewhere I could not reach alone.

That is not an argument against AI. It is an argument for collaboration.

When those collaborators are not around, AI fills part of the gap. It lets me keep creating. I can then show the work to real people, get feedback and adapt. The circle still includes humans. It is simply shaped differently.

The community is the point

To me, the demoscene has always been inclusive. Not in the sense that every entry belongs in every category, or that rules do not matter. Inclusive in the more practical sense that you can show up, learn, make something, put it on the big screen and become part of a community that wants to see what computers and people can do together.

That community formed me.

I have carried the idea into my professional life. For more than fifteen years I have helped organize the Arctic Cloud Developer Challenge, a nonprofit community hackathon for developers, consultants and architects working with Microsoft 365, Power Platform, Azure, Fabric, pro-code and, increasingly, AI. We created it with inspiration from The Gathering: give people a place to learn, compete, socialize and show off what they can make.

The technology changed. The purpose did not.

AI has become a large part of the hackathon in the past few years because it has become a large part of the technology. Participants still need ideas, domain knowledge, judgment, persistence and teamwork. They simply have a new set of tools to explore.

That is what I want from the demoscene too. I want to compete and show my work. If it is good, perhaps I get some acclaim for the creativity, storytelling and ideas. If it is not, I watch the other demos, see what they did better and learn. I have been doing that for most of my life.

One compo, with the process visible

Is music made in a DAW more creative than music generated with ACE-Step or Suno and then directed, selected, arranged and refined by a person? I do not think there is one answer. Taste is subjective, and competitions are allowed to judge process as well as output.

What I object to is the shortcut where AI use itself becomes proof that no creativity or craftsmanship occurred.

My preferred model is straightforward:

Put demos in the demo compo, regardless of whether the code was typed by hand, written with an agent or built through a mixture of both.
Show a clear production card before each entry: code, graphics, 3D, music, AI tools, engines and other major parts of the process.
Keep craftsmanship-specific compos where the method is the point, and name the constraint clearly: handcrafted code, pixel graphics, tracked music, 4K, 64K or a specific hardware platform.
Require honest disclosure, with disqualification for hiding or misrepresenting the process.
Keep real-time execution as the defining line for demos.
Let the audience decide how much the production method matters when they vote.

That respects the heritage without freezing the scene in one era's toolchain.

Some voters will reward a hand-coded effect because they understand how difficult it was. Some will care mostly about the audiovisual experience. Some will discount AI-generated assets. Others will be impressed by how one person directed a complicated production into existence. That is fine. We have always voted with different ideas of what makes a demo good.

9 Fingers by Spaceballs is a good historical example. Released on the Amiga at The Party 1993, it used heavily processed footage of a dancer, driving music and tight synchronization to create something closer to a music video than the effect-by-effect demos many people expected. Some questioned whether preprocessed animation was proper demo craft. It still required clever compression and code to make the result run smoothly on an Amiga 500, but its lasting power comes from the complete audiovisual experience. It placed fourth in the compo and became one of the best-known Amiga demos of its era.

The argument was familiar even then: are we judging how an effect was made, or what happens on the big screen?

The process card gives craftsmanship the credit it deserves without turning one process into the admission ticket for creativity.

If the compo does not exist, build it

There is a fitting historical loop here.

Before the first The Gathering, we in Crusaders spent plenty of time complaining about what other demo parties got wrong. Eventually someone gave us the obvious answer: "So do it yourself, then."

And we did.

The Gathering grew from that impulse. Do not only complain about the room. Build a better room and invite people into it.

If the scene does not adapt, perhaps those of us making AI-assisted demos will eventually have to follow the same advice. Not because we want to split the community, but because we want to participate in it. I would much rather see existing parties create clear, welcoming rules than build a parallel scene from scratch.

The Crusaders slogan is "We break for nobody." It fits where I am now. I am still following ideas, still learning, still adapting and still trying to make the demos I want to see.

The demoscene has always explored what computers can do. We moved from chip tunes to four channels, eight channels, sixteen and effectively no meaningful channel limit. We moved from hand-plotted pixels to 3D packages, modern engines, shader languages and GPUs powerful enough to render 4K at 60 frames per second.

Every generation has had better tools than the one before it.

AI is a bigger jump, and it raises harder questions, but rejecting it as inherently non-creative feels strangely out of character for a culture built around making machines do new things.

I did not become a brilliant demo coder.

I found a different way to make a demo.

body.mod was neither better nor worse because AI helped me create it. It was a first production made with a different process. People watched it alongside the other demos, voted for it and, I hope, enjoyed it.

That was always the point for me.

I already have another one in the works. I cannot disclose much, because a demo should not be released before it enters a compo. But in my own completely biased opinion, it is at least 10x better than body.mod.

That improvement did not arrive in a prompt either. It came from doing the first demo, seeing where it fell short, learning the tools, changing my process and trying again.

Apparently, even with AI, there are no shortcuts around having to get better.

Stay creative :)

Sources and further reading

Watch body.mod on YouTube
BODY.MOD by Crusaders — Demozoo
The Gathering 2026 results — Demozoo
The Gathering 2026 Real-time Demo rules (AI assistance allowed; primarily AI-generated entries prohibited)
The Gathering history — Wikipedia
Demoscene — Wikipedia
Scene.org — The International Demoscene Organization
History of Assembly
Assembly Summer 2026 demoscene competitions (separate AI Coding compo)
Assembly Summer 2026 competition rules (AI allowed in AI Coding; prohibited in traditional compos)
Revision 2026 general competition rules (generative AI prohibited in all compos)
Evoke 2026 competition rules (generative AI prohibited)
Deadline 2026 competition rules (generative AI prohibited; minor assistance excepted)
Edison 2026 competition rules (generative AI prohibited in all compos)
Arctic Cloud Developer Challenge

Because Clicking Around in Search Admin Is Not a Strategy: Microsoft Search Cmdlets Landed in PnP PowerShell

2026-06-23T16:00:19.938+02:00

I had this pull request merged back in February and then... forgot to blog about it. Better late than never. Here you go!Z

PR: https://github.com/pnp/powershell/pull/5242

If you’ve ever tried to automate Microsoft Search verticals and result types and ended up rage-clicking in admin UIs instead, this one is for you.

What was added

This PR adds cmdlets for managing Microsoft Search configuration through PnP PowerShell:

Search verticals

Get-PnPSearchVertical
New-PnPSearchVertical
Set-PnPSearchVertical
Remove-PnPSearchVertical
Set-PnPSearchVerticalOrder

Search result types

Get-PnPSearchResultType
New-PnPSearchResultType
Set-PnPSearchResultType
Remove-PnPSearchResultType
New-PnPSearchResultTypeRule

Site connections

Get-PnPSearchSiteConnection

In short: proper scripting support for verticals/result types/site connections, instead of “hope-and-click” operations in multiple portals.

Important caveat (read this)

These cmdlets use the Graph Connector Service (GCS) API endpoint used by the same Microsoft admin experiences, but it is not publicly documented/supported.
So yes, it works. Also yes, the API can change whenever it wants to. All work done using reverse engineering of the admin UX experience.

You need delegated permission from the GCS app registration (not the standard Graph one) – no app only as the API was build for the admin UX:

API app id: 56c1da01-2129-48f7-9355-af6d59d42766
Scope: ExternalConnection.ReadWrite.All (d44774bd-e26c-43b1-996d-51bb90a9078e)

Which PnP PowerShell version has this?

First stable release: v3.2.0
First nightly containing it: 3.1.311-nightly

So if you’re looking for this in older stable versions, that’s why you’re not seeing it.

Quick start

Install-Module PnP.PowerShell -RequiredVersion 3.2.0 -Scope CurrentUser
# or update if already installed
Update-Module PnP.PowerShell

Human in the Loop: When to Replace, When to Keep, and Why (Part 6 of 6)

2026-06-22T12:01:21.448+02:00

TL;DR: "Human in the loop" is repeated like a magic spell, but most teams have never asked what the human is actually for. Sometimes it's judgment, trust or legal sign-off. Sometimes it's habit. The interesting work is asking that question honestly for each loop, and shrinking the role to where it actually matters. Three breast cancer screening studies (Denmark, UK, Sweden) show what this looks like when it goes right, and they're a reminder that human-in-the-loop covers all AI, not just chatbots. The wider authorship question matters too: AI training, AI use, and AI imitation are three different debates that keep getting collapsed into one.

Part six of a six-part series. Previously: consultants and what survives.

In the first five posts I argued that AI mostly removes friction and changes who the work flows to. The natural next question is more practical. Where in my own processes is a human still needed, and where is the human just there because no one has revisited the design?

This post is about asking that question on purpose.

The Danish radiology case

In Denmark, breast cancer screening used to be read by two radiologists independently for every single mammogram. After roughly three years of using an AI system (Transpara) in the Capital Region and Region of Southern Denmark, the setup looks very different. The AI now triages the screenings. Around 70% of the lowest-risk mammograms get read by a single experienced radiologist instead of two. The remaining high-risk cases still go through the original double-read process.

The published outcomes are worth pausing on. More cancers detected. Fewer false positives. Radiologist workload cut by roughly a third to a half, depending on which study you read (University of Copenhagen 2024, Nature Medicine May 2025, and the earlier Lauritzen et al. work in Radiology 2022).

A fresh UK result backs the same pattern at much larger scale. Kelly et al., published in Nature in March 2026, evaluated a Google AI system on 175,000 women across NHS sites, the largest such study to date. AI detected more invasive cancers, recalled fewer women on their first scan, and crucially had higher specificity, meaning fewer false positives. The earlier Swedish MASAI randomised trial in The Lancet02464-X/fulltext) (January 2026) landed in the same place: same specificity as standard double reading, higher sensitivity, fewer interval cancers with bad characteristics, less reading workload. Three independent settings, three studies, the same shape of result. Specificity matters more than people think. False positives mean recall letters, biopsies, weeks of fear and real downstream cost. If AI reduces them while also catching more real cancer, the gain is much larger than "AI is as good as a radiologist" makes it sound.

This is the version of "human in the loop" I find honest. The humans did not disappear. The loop got redesigned around what only humans should do, and AI took the rest.

Not all AI is a chatbot

It's worth saying plainly, because the current hype makes it easy to forget: the cancer screening systems above are AI, but they are not language models. They are predictive models trained to do one narrow thing extremely well, and "human in the loop" applies to them just as much as it applies to the chatbot drafting my emails. The principle spans the whole field, not just the part that talks back to you.

The distinction matters for a practical reason too: cost. Generative AI, the large language and image models, is expensive. It burns a lot of GPU time and electricity for every answer. Predictive AI of the kind used in medical imaging is usually cheap by comparison, small enough that it can often run on a local laptop. Different tools, different footprints, different jobs.

Yet we increasingly reach for the generative model even when the task is deterministic, something a small script or a classic predictive model would handle faster, cheaper and more reliably. We do it because the chatbot is right there, one prompt away, and the deterministic option takes a little setup. Availability and ease of use win, even when they are the wrong tool for the job. That is worth noticing, because the easy default is not always the responsible one.

Why is the human actually there?

When I look at processes around me, the answer to "why is there a human here" usually falls into one of four buckets:

Judgment. Hard tradeoffs that depend on values, context or risk appetite.
Trust. A customer, regulator or colleague needs a named human to vouch.
Legal or compliance. A signature, an audit trail, an accountable owner.
Habit. No one has revisited this loop in years.

The first three are real. The last one is where most of the easy wins live, and where most teams get stuck because nobody is allowed to ask the question out loud.

For each loop in your process, I think it's worth being honest. Why is the human there? If the answer is "habit," that's a candidate for redesign. If the answer is "judgment, trust or legal," then the human should stay, and the interesting question becomes how much of the surrounding work AI can take off their plate so the human can focus on the part that actually needs them.

That's what happened in Denmark. The human radiologist is still the one signing off. AI just removed the read that was happening twice for no diagnostic gain.

Adapting to the process, not forcing it

A small caveat that I keep getting reminded of in real conversations: you can't always shove AI into an existing process and expect it to work. Sometimes the process has to flex. Sometimes AI has to flex.

I was in a conversation recently with a team that tried going all in on AI-first coding for a few months and decided to dial it back. Their reasoning was good. In their world, the existing tight feedback loops of pair programming and TDD were doing real work, and treating AI as the default driver actually weakened the engineering culture. So they backed off to "AI where it makes sense" rather than "AI first."

I do not read that as a defeat for AI. I read it as a team that did the actual work of figuring out which loops the AI was making better, and which loops it was breaking. That is exactly the right question to land on, even if very few teams ask it up front. Most discover it the long way around, by trying everything, seeing what sticks, and quietly paying for what doesn't. The shotgun approach has a real cost. You just rarely see it on the same invoice as the AI tooling.

You will find places where AI fits naturally, places where you need to change the process to let it fit, and places where the human-led loop is genuinely the better answer for now. All three are valid outcomes.

Brain cycles vs GPU cycles

Here is a pattern I keep running into, and it is the one that frustrates me most.

A recent example from my own week: we needed an API change to support a particular cohort of users. Writing the one-pager to explain the scenario took minutes with an agent and my own input. Then it sat. Engineering would not look at it until product management produced a proper spec. PM would not write the spec until leadership signed off. The artifact AI helped me produce in minutes was now behind weeks of human coordination.

This is not a story about AI failing. The AI did exactly what I needed it to do. The bottleneck is org design, and AI cannot route itself around an approval chain that was built for a different speed of work.

The lesson, if you are trying to get company-wide gain from AI tooling, is to split your sign-off junctions into two piles. One pile is the real regulatory boundaries, the genuine ship blockers, the things where the sign-off exists because something will actually break (legally, financially, safety-wise) if it doesn't. Those stay. The other pile is everything else: gates that exist because they existed last year, reviewers who got added when a different VP cared, ceremony that no one remembers approving. Those are the candidates for redesign.

Saving an hour on the artifact does not matter if the artifact then waits three weeks for a signature.

Getting people to spend brain cycles on the right question, instead of having a GPU spend cycles on the wrong one, is inherently the harder problem.

Turning frustration into opportunity

A few moves help. Name the bottleneck out loud, because if AI makes the artifact ten times faster, the slowness of the next step is suddenly visible in a way it wasn't before. Separate decisions from rituals, and treat them differently. Match the artifact to the audience that has to act on it, since AI can produce a one-pager and a full spec for the same price. And make it easier to say yes than to say no by bringing the spec, the impact, the alternatives and a draft of the answer you're hoping for.

None of this fixes the org chart. But it does turn each blocked artifact into evidence about where the org is structurally slow, and a small chance to make the next round less painful.

If AI ends up doing anything important for organizations, I suspect it will be this. Not replacing the humans in the loop, but making it impossible to ignore where the loops themselves are the problem.

The low-risk on-ramp: meeting summaries

If you want a concrete loop where the human role can shrink safely, it's meetings. AI-generated transcripts and summaries are easy to verify against your own memory, the cost of a small error is low, and the time saved (note-taking, recap emails, late joiners catching up) is real and immediate. It's also a good practice case: if your team is nervous about handing anything to AI, this is the safest place to build the muscle of "AI proposes, human verifies, human owns the output."

A small checklist for each loop

When I look at one of my own processes and ask whether AI can take part of it, I find it useful to run through these questions:

Why is the human in this loop? Judgment, trust, legal, or habit?
What is the cost of a small error? Low, recoverable, or catastrophic?
How easy is it to verify the AI output? Can I check it in seconds, or does it require deep review?
What is the ROI of changing this loop? Saved money, saved time, better quality, better employee experience, or just "looks modern" (or worse, "see, I spent AI credits, so I must be effective")?
Can I take one small step instead of redesigning everything at once? What is the smallest piece of this loop I could hand to AI today and review tomorrow?

If a loop fails the first question (the human is mostly there out of habit), and passes the second and third (low cost of error, easy to verify), it is a strong candidate. If it fails the second (catastrophic if wrong) or third (hard to verify), keep the human firmly in place, and instead look at what surrounds the loop.

I am still the author

One last thing, because it ties the whole series together for me.

I have written all six of these posts using AI as part of my flow. Outlines, drafts, sharpening, even catching weak transitions. I have also adapted the output to my own voice, grounded in hundreds of previous blog posts I've written over the years. But every claim, every sentence and every decision about what stays and what goes is mine. I read everything. I cut what I disagree with. I own the result.

The same thing is true for my day job. My name is still on the spec documents I write. My name is still on the code changes I push. Whatever the agent did along the way, the artifact has a human owner, and that owner is me.

There is a flipside to that, and it is one I should be honest about. The models I rely on were trained on a huge amount of writing other people produced. A book I co-wrote, Working With Microsoft FAST Search Server 2010 for SharePoint, sits on the Anthropic copyright settlement works list. I'm not personally a class member there because the rights belong to the publisher, not me, but it's a useful concrete example because that book was clearly used as training material without explicit consent at the time.

I'm not going to pretend the legal questions here are settled, because they aren't, and a lot of authors feel, with reason, that something was taken from them. My own position is more pragmatic than principled. I lean toward "if it's on the open internet, it's fair game for learning," and I'm fine with the trade where work I helped produce contributed to something millions of people now use to think and write better. I'm a sharing-is-caring person. I always have been. That said, training really should move toward licensed or otherwise lawful material wherever it can. The trajectory matters. Meta's Llama models were largely trained on user data under terms people technically agreed to in the EULA when they signed up for Facebook and Instagram, which is at least a clearer legal footing, even if "consent buried in a 12,000-word document" is a thin definition of consent. Llama and DeepSeek are also open weights, which gives something back to the wider community in a way that closed-source providers like Anthropic and OpenAI do not. The conversation should not just be about what was trained on, but also about who benefits from the result.

Where I draw the line is on use, not on training. I use these tools to think, draft, sharpen and ship work that is mine. I do not use them to impersonate another author's voice on demand, to clone a living artist's style for commercial output, or to mass-produce work designed to look like someone else's. The training argument and the imitation argument are not the same argument, and I think conflating them is part of why this debate keeps getting stuck. Training broadens what the tool can help with. Imitation-on-demand is where I think real harm starts.

That is, in the end, what I think "human in the loop" actually means. Not a checkbox. Not a ritual. Someone is responsible for what comes out the other side, and that someone is named, and that someone is human.

If your process has loops where no human ends up actually owning the output, that is the problem worth fixing. Whether AI shows up before or after, that loop was broken already.

Thanks for sticking with me through six posts. The question I started with was who the work flows to now. The question I'm ending with is who the work flows back to for accountability. I think those are the two questions that matter most for the next few years.

Stay curious :)

Consultants, Context-Switching, and What Survives (Part 5 of 6)

2026-06-22T11:41:24.677+02:00

TL;DR: AI changes how consultants work and who wins at it. The timeseller who just bills hours gets more exposed. The curious builder who reads context fast, carries patterns between projects, and turns ideas into working loops gets more valuable. And if AI one day makes my own role redundant, I think that's genuinely fine. I've changed roles plenty of times already.

Part five of a six-part series. Previously: too few and too many people at once.

I've spent four posts arguing that AI is mostly a friction remover that rewards people comfortable with tempo and many contexts. Time to land it where I actually live, consulting. Or technically, where I used to live, with a long enough shadow that the way I work today still looks like it.

We misunderstand what good consultants do

In the public sector there's constant talk about cutting consultant spend. Sometimes for good reason. Consultants shouldn't replace permanent expertise, and organizations need to own their own decisions.

But after many years as a consultant, and many conversations with other consultants, I think we often misunderstand what good consultants actually do.

For the record: I'm not technically a consultant anymore. I've been at Microsoft for seven years, in a permanent role. But the way I work still looks much like it did in consulting. I help out here and there, where it's needed, across projects and teams. Three internal roles and seven managers later, I keep landing on something new because I follow projects and opportunities. AI today is part of why that works. It lets me get into new projects faster and keep an overview across them.

When I ask experienced consultants what the ideal project length is, many say three to six months. That's usually enough to understand the problem, find patterns and build momentum. After that, many want to move on. Not because they're disloyal, but because they like getting into something new. For a lot of us, a permanent role isn't the goal. The goal is new problems, new context and fast learning.

Why AI makes this arrangement stronger

A lot of good consultants create value because they handle context-switching well and have seen many variants of the same problem. AI makes this way of working stronger, not weaker.

Agents can read up while the consultant talks to people. They can check code while the consultant weighs a solution. They can keep several threads warm at once. The consultant stays the human in the loop, but on more threads at the same time. So the consultant's most important quality stops being "delivers the most hours" and becomes "asks the right questions and connects patterns fast."

The employees know the organization and the people. The consultant brings an outside view and speed. I'm not defending consultant spend uncritically. I'm defending the difference between renting hours and bringing in specialist competence from outside.

And here's where I think AI sharpens the difference. The mediocre consultant who only sells hours gets more exposed. The curious one who understands context and carries what they've learned elsewhere can become far more valuable.

This clicked for me in a conversation with a former colleague who immediately leaned into what I'd call the builder persona. The people who get energy from seeing a messy need, shaping a solution, and then watching it come alive in the real world. He has side projects where agents monitor for new information, auto-send request emails when criteria are met, and then escalate only the moments that actually need judgment. Human in the loop, but for the right moments. That's the pattern I keep seeing: AI is best when it handles the repetitive plumbing so a human can spend attention on decisions, direction and accountability.

What survives

So what actually survives all of this? Not "writing code," at least not as the core value. What survives is judgment, context, asking the right question, and knowing when something is good enough. The human glue that AI can scout for but not replace.

It's easy to talk about transformation. Harder to stand in it.

If AI one day makes my own role redundant, I honestly think that's fine. Then I'll have to find something else to do. I've already changed roles many times. Maybe I'll have to do it again. (Updating my own rules when reality moves is kind of a habit. Years ago I had a "rule of three" for SharePoint search. The platform shifted, I bumped into a new edge case, and I had to admit it was actually a rule of four. Same dance, much bigger stakes now.)

But I think it's hard to argue this one blows over.

I don't believe AI primarily replaces people. I believe it changes which people society needs more of.

And that, after five parts, is the whole point I've been circling. The question was never "how many jobs disappear." It was always "who does the work flow to now?"

Thanks for sticking with me this far. If it made you think, or made you argue with me at your own coffee machine, that's a win in my book :)

One more post, because the question that keeps coming up in the comments is: where exactly does the human still belong in the loop? Part 6 takes that on directly.

Society Has Too Few and Too Many People at Once (Part 4 of 6)

2026-06-22T11:31:22.575+02:00

TL;DR: At the individual level the AI squeeze looks bleak. Zoom out to society and it gets stranger, and maybe less bleak. We already lack people in health, care and the trades. If AI frees up knowledge workers, maybe some of that labor moves toward work that needs human presence. There's a catch in the pipeline, though: if we stop hiring and training juniors, the shortage just reappears later. I think it mostly self-corrects, but that's cold comfort for whoever graduates into the dip. Easy to say at the macro level. Harder for the person living it.

Part four of a six-part series. Previously: who AI favors and who it squeezes.

Part three ended on a hard note: some people get squeezed, and that's personal. But when I step back and look at society as a whole, I'm honestly not sure the overall direction is negative.

Short on people and oversupplied with people

We already lack people in healthcare, schools, elderly care and the trades. The World Health Organization projects a global healthcare workforce shortage of at least 10 million by 2030, with upper estimates over 78 million, a figure McKinsey Health Institute uses as the starting point for its 2025 report on the healthcare workforce of the future. The OECD Employment Outlook 2025 frames population ageing as one of the defining megatrends, pushing the old-age dependency ratio to unprecedented levels across the OECD over the next 35 years. Meanwhile the WEF Future of Jobs Report 2025, based on input from 1,000+ employers across 22 industries and 55 economies, makes the two-sided shape concrete. They project 170 million new jobs created and 92 million displaced by 2030, a net gain of 78 million. The largest declines, in absolute numbers, hit clerical and secretarial roles: cashiers, ticket clerks, administrative assistants, executive secretaries, bank tellers, data entry clerks. The fastest growth, alongside tech roles, sits squarely in the care economy: nurses, social workers, personal care aides, teachers.

Put those side by side and you get a strange shape: a shortage of people and a surplus of people at the same time. Too few in health, care and craft. Too many in parts of the knowledge economy.

Read that twice, because it sounds like a contradiction and it isn't. Maybe part of the gain from AI is that labor gradually shifts toward work that requires human presence, care and trust.

Work that's hard to automate because the human in the room is the point.

(That phrase is doing double duty on purpose. "Human in the room" here, "human in the loop" in part six. Same underlying question. When is the human the bottleneck, and when is the human the point?)

But the macro view is cheap

It's easy to say all that at the level of society. For the individual it can mean something much less comfortable: young people pushed toward educations that lead to jobs, not the jobs they actually want.

That's not new. Plenty of generations have made pragmatic choices about what pays. But it does challenge a particular kind of "you can become anything you want" story. In the Nordic model that belief is genuinely close to reality. The OECD report A Broken Social Elevator? How to Promote Social Mobility estimates it takes about 2 generations for children from the bottom income decile in the Nordic countries to reach average earnings, versus 4 to 5 generations on OECD average, with the US sitting around the OECD average despite the cultural script of the American Dream. OECD's newer 2026 working paper using fresh PIAAC survey data reaches the same conclusion with different methods: the Nordics are consistently the most mobile, while Chile, Israel and Latvia are the least, and parental background still influences children's earnings even when education is held constant. The Great Gatsby Curve research and the paper bluntly titled The Scandinavian Fantasy both make the point: the country selling mobility hardest, the U.S., has less of it than it thinks, and the country quietly doing it well rarely gets the credit. If AI narrows which paths lead to work, the Nordic version of that promise takes a real hit. The American version was a comforting story to begin with, so the dent there is more about the story than the underlying reality.

The junior squeeze, and why I think it partly self-corrects

One worry I hear a lot: new graduates can't get a foot in the door, and it still takes five to ten years to turn someone into a senior. If AI absorbs the work juniors used to cut their teeth on, where does the next generation of seniors come from?

I'm more optimistic than most here, with one caveat. The hopeful case is that AI can shorten the apprenticeship. A lot of becoming senior is accumulating domain knowledge and structural judgment the slow way, by making mistakes over years. A good model already carries a lot of that structure, especially in programming. It can set up an architecture and, more importantly, explain why. Used well, that turns some hard-won experience into something you can learn faster, by reading what the AI lays out and asking why.

The caveat is the whole game. If a junior treats AI as the answer instead of as a tool and a teacher, they don't build the judgment, they just rent it. That works on a greenfield project where the model is strong. It falls apart in brownfield reality, the messy existing system where you have to know why things are the way they are. And the models keep getting better, which makes the lazy path more tempting, not less.

There's a structural risk on top of the individual one. If companies stop hiring and training young people, whether as consultants or internally, the squeeze just moves in time. People retire. Someone has to replace them. A pipeline you stopped filling ten years ago is not there when you need it. I suspect we get a dip and a correction rather than a permanent break, because the shortage eventually forces hiring again. But "it self-corrects eventually" is cold comfort if you're the cohort that graduated into the dip.

And the harder version, honestly: if enough of these entry-level jobs genuinely disappear to efficiency rather than just shift, then we really do need fewer juniors, and the correction is smaller than the disruption. I don't think that's the whole story, but I won't pretend it isn't part of it.

A tool, with all the problems of tools

Here's the other catch. Because AI is a tool, it carries all the inequality problems tools carry. If only the well-resourced get access to the best tools, AI can amplify inequality instead of reducing it.

There's a darker version of that same risk. What happens when bad actors offer cheap or free AI loaded with hidden propaganda, slanted news framing, or quiet ideological nudges? A free chatbot that helps you write emails and also subtly shapes how you think about a country, a politician, a minority, an election. We have already seen this pattern with social media feeds. AI is a more intimate channel. The "free tool" can be the cheapest delivery vehicle for influence anyone has ever built. People without resources are exactly the people most likely to use whatever is free, which means the inequality problem and the manipulation problem stack on top of each other.

Schools are where this gets sharp. We need to teach the difference between AI as a tool and AI as an oracle. The first one everyone should learn. The second one we should be far more skeptical of. A student who learns to use AI to think faster is in a very different place from one who learns to let AI think for them. And neither of those places is safe if the model itself has been quietly tilted before it ever reached the student.

That distinction, tool versus oracle, is going to matter far beyond the classroom. It's basically the whole question of whether AI lifts people up or quietly hollows out their judgment.

So is this good or bad?

Honestly? Both, depending on where you're standing. On the societal ledger I can squint and see labor flowing toward work that's badly understaffed and deeply human. On the individual ledger I see real people who didn't choose this being told their path just narrowed.

Historically, technology has rarely made us stop creating. When something gets cheaper to produce, we raise our ambitions. I think AI does the same. We'll attempt more, experiment more, iterate faster. That's the optimistic read, and I mostly believe it. But "mostly" is doing some work in that sentence.

In part five I'll bring it back to the ground, to my own corner of the world: consultants, context-switching, and what kind of value actually survives all this. Then part six picks up the thread of where humans still belong in the loop.

Two more to go :)

Who AI Actually Favors (and Who It Squeezes) (Part 3 of 6)

2026-06-18T08:00:00.000+02:00

TL;DR: The AI productivity gain is real, but it is not evenly distributed. It rewards people who thrive on tempo, many contexts and complexity. It puts pressure on people who need stable, predictable surfaces. The research on AI fatigue and technostress is starting to back what most of us already feel: AI gives and AI takes, and which side wins depends a lot on who you are and what kind of room you work in. That's uncomfortable, and pretending otherwise helps no one.

Part three of a six-part series. Previously: the context-switch tax.

In part two I argued the real win from AI is cheaper context-switching. The natural follow-up is uncomfortable: if that's the win, it lands for some people far more than others.

The gain is uneven

I don't think this effect is evenly distributed at all. People who work across fields, domains and organizations will get far more out of AI than others. It especially favors people who can handle high tempo, many contexts and a lot of complexity. For us (and yes, I count myself firmly in that group) it feels like the brain no longer has to boot up from cold every single time.

So let me say it plainly. AI favors people who enjoy fast context shifts and complexity. It puts pressure on people who need stable, predictable work surfaces.

That does not mean stability and thoroughness become worthless. We still need careful, deep, single-track work. But a lot of jobs will become less stable than they were, and the people in them didn't ask for that.

Faster and more stressed at the same time

I was at a summer party recently, talking to a colleague about exactly this. He told me he was definitely working faster with AI. He also felt more stressed than before. That stuck with me, because for me agentic work feels the opposite. From day one it just felt natural. Low shoulders. Two or three threads in parallel, a calmer head, more done.

Why the gap?

The research is starting to put proper words on this. Multiple 2025 and 2026 papers describe an "AI fatigue" or "technostress" effect that sits right alongside the productivity gain. A BCG Henderson Institute study covered by CNN coined the term "AI brain fry" for mental fatigue from overseeing too many AI tools. Of 1,488 US workers surveyed, 14% reported it, and the affected group made 39% more major errors and were 39% more likely to quit. A separate working paper called "From Gains to Strains" makes the same core point from a different angle. AI introduces new demands at the same time as it removes old friction. Cognitive load can drop in one place and spike in another. Pace goes up. Expectations go up. Boundaries blur. The same tool that gives one person a calmer day gives another person a faster, noisier one.

The most useful framing I have seen is the Job Demands-Resources (JD-R) model applied to GenAI by Chuang, Chiang and Lin (2025), a three-wave study of 600 employees across industries. The short version: every new tool is both a resource (it helps you) and a demand (it asks something new of you). For people whose mental wiring or work context lets the resource side dominate, AI feels like a gift. For people where the demand side dominates, AI feels like a treadmill someone quietly sped up.

Their results land on something I find both honest and useful. AI improves productivity either way, through resources directly and indirectly through stress. But the two paths feel very different on the inside. AI resources drive engagement, which lifts job satisfaction. AI technostress drives exhaustion, which lowers job satisfaction and increases work-family conflict.

Same productivity number on the spreadsheet. Two very different lived experiences.

They also found that generative AI tends to dampen the demand side more than older, non-generative AI, mostly because it's easier to use and feels less like a threat. Worth knowing if your organization is rolling things out right now.

When the craft itself is the point

There is one more flavor of this gap that I think gets missed a lot, and it is the one I find hardest to write about because it lands on people I genuinely respect.

I have a very capable colleague, an excellent developer, who feels AI is quietly threatening his existence. Not because he can't use it. He can. But because what gives him joy at work is sitting down with a problem, thinking it through, and writing the code that solves it. That whole arc, from blank page to working solution, is where he goes into the zone. The craft itself is the point for him. Handing off chunks of that arc to an agent doesn't just speed up his day. It removes the part of the day he came for.

I'm not wired the same way. I appreciate brilliant code, but for me the result matters more than who or what produced it, as long as the result is solid. I don't have the same ownership in the lines themselves. What I own are the thoughts, the design, the decisions and the outcome. So AI taking over more of the production part feels like a release, not a loss. For my colleague, it feels like erosion.

Both of these are completely legitimate ways to relate to work. And this is where the diversity question gets harder. I keep saying diversity of working styles is a feature, and I mean it. But will companies actually agree? Or, over time, will they quietly hire toward a more homogeneous group, the people for whom AI feels like a release? I honestly don't know. I expect a few rounds of back and forth before this settles.

I am also aware that I am lucky right now. If someone told me I was no longer delivering enough in a world with AI, I would be sad and shaken. I just don't see that scenario coming for me, at least not soon. That is a privileged position to write from, and I want to name it. Equality in this kind of transition is not simple. It is not even clear which level we should be trying to be equal at.

Is it just attitude, or is it something else?

It is tempting to say "this is mostly about mindset, lean in and you'll be fine." I don't think that's honest.

A few things I notice when I look at the people around me, including myself:

Personality matters. Some of us are wired for tempo and many threads. Others get cognitive whiplash from the same setup. "Born this way" is unfashionable to say out loud, but it's a real piece of the picture.
Habit matters. A lot of what looks like aptitude is just practice. People who have spent years switching between projects, customers and stacks already had this muscle. AI just amplifies it. People who built a career on deep single-track work have to build the muscle from scratch, and that takes time and patience that most workplaces don't grant.
Unspoken expectations matter, a lot. If your manager (or your inner critic) has silently moved the bar from "finish a thing" to "finish three things, in parallel, while keeping up with the chat," the AI did not stress you out. The expectation did. AI is just the carrier wave.
Imposter syndrome makes it worse. If you feel you are not allowed to ask out loud "how do I use this for my work," you end up copying someone else's flow that doesn't fit you, then judging yourself for struggling with it. The fix isn't more AI training. It's a workplace where you can say "I haven't figured this out yet for what I do" without it counting against you.
Psychological safety matters. Same as above, scaled up to the team. Teams that can openly experiment, fail small, share what didn't work, and adjust the bar accordingly, get the gain without the brain fry. Teams that have to look productive on top of being productive get both.

So no, it is not just attitude. It is some attitude, some wiring, some practice, some leadership, some culture. And honestly, some plain luck about which job you happen to be in right now.

Which is also why I'm careful when I write that AI feels natural to me. It does. But "low shoulders from day one" is not advice I can hand to anyone. It is a description of where my wiring, my role, my manager and my work setup happened to line up well. Other people have a harder version of the same problem through no fault of their own.

Accommodation, not just adoption

This is where I think most workplaces are still asking the wrong question. The question I keep hearing is "how do we get our people to adopt AI?" The better question is "how do we accommodate the fact that our people are not all the same?"

We already accept this for the physical workspace. We have rules and standards for chairs, screens, lighting, heating, sound, accessibility. We don't expect everyone to perform equally well in a poorly lit room on a bad chair, and we don't blame the worker who struggles in those conditions. We invest in the environment so the work can happen.

AI deserves the same thinking. Not as a perk and not as a mandate, but as workplace accommodation.

If you map AI gains across an organization, you almost certainly get something close to a normal distribution. Some people light up immediately and run with it. Some people get very little from it no matter what you put in front of them. Most people sit in the middle and need real help to figure out which tool, in which part of their day, gives them a real, personal win. A one-size-fits-all rollout serves the people on the left tail of the curve, sometimes the people on the right tail, and almost nobody in the middle.

What I think actually works:

Treat AI tooling as a workplace standard, not a perk. Just like a good chair and a working screen, AI access should be the default for knowledge work. Not the reward for the keen ones.
Write principles, not mandates. Guidelines that say what we expect AI to be used for (and not used for), with room for individuals to find their fit. People follow principles better than they follow orders.
Invest in finding the personal win. Most people need a guided session, not a generic course. The question "what is the one thing in your week that AI could make easier?" is more useful than any 30-minute corporate training video.
Lead with empathy over compliance. The bell curve is real. The person who isn't using AI yet is usually not a slacker. They are someone who hasn't found their fit, or hasn't been given a workplace where it is safe to try and to fail.
Acknowledge the people on the tail who genuinely won't benefit much. It is honest to say that some roles, in some seasons of life, are not where the gain lands. The strategy is not to drag them through it. The strategy is to make sure the loss isn't theirs to carry.

This is what I meant in the front-door post when I said employers who deny AI tools are robbing themselves. It is the same logic as denying someone a good monitor. The work suffers, the worker suffers, and the organization quietly pays the bill in both directions.

"AI turns developers into architects" is a bit too neat

People don't become worthless. But certain kinds of value get cheaper.

This is also why I think the popular line about AI turning developers into architects, summed up neatly in pieces like this one in TechGig and echoed across LinkedIn, is slightly misleading. There is a real pull. Strong developers do get pushed toward higher-level design and orchestration work. But not everyone can, wants to, or gets that role.

What AI really does is let one person with broad system understanding handle far more complexity than before. That can mean fewer traditional developer roles over time. And maybe more importantly: fewer pure office roles in general.

There's a generational edge to this too. If the entry-level work is exactly what AI absorbs first, juniors lose the rung they used to climb on, and the squeeze quietly becomes a pipeline problem for everyone later. I come back to that in part four.

The squeeze is real, and it's personal

If AI makes large parts of knowledge work more efficient, we may need fewer people for coordination, reporting and administration. That's brutal for the people it hits. Losing a role, or an identity, is hard. I'm not going to dress that up.

It's easy to talk about transformation in the abstract. It's harder to stand inside it.

So I want to be honest about the shape of this. The gain is uneven. It clusters around people who were already comfortable with chaos, and it thins out under people who built careers on predictability. If you only read the cheerful version of the AI story, you miss that half of the room is getting a much worse deal than the other half.

That's not an argument against AI. It's an argument for being clear-eyed about who carries the cost.

In part four I want to zoom out from the individual to the whole society, because at that level the picture gets genuinely strange: we may end up short on people and oversupplied with people at the same time.

More soon :)

The Real Win Isn't Faster Output. It's Cheaper Context-Switching. (Part 2 of 6)

2026-06-18T08:00:00.000+02:00

TL;DR: The studies on AI and productivity look contradictory until you notice they're measuring one task at a time. That's not how I work anymore, and it's not how most knowledge workers will work soon either. The gain isn't that task A goes faster. It's that you handle A, B and C in the time it used to take to do A alone. And the math should land at the company level, not the individual level. Diversity of working styles is a feature, not a problem to optimize away.

This is part two of a six-part series. Part one is here if you missed it.

In part one I said the biggest change AI brought me wasn't speed on a single task. It was the collapse in the cost of switching context, the mental tax of jumping between tasks. Let me make that concrete, because this is where the research gets interesting, and where people start talking past each other.

The studies disagree, and that's the clue

The studies aren't tidy. The clearest data we have right now is from developer work, because developers are easy to measure and the tooling matured there first. But the pattern shows up wherever knowledge work involves many threads.

GitHub found in 2024 that developers with AI tools shipped more functional code. Nice and encouraging.

But when METR put experienced developers to work on real tasks in their own codebases, they came out 19 percent slower, even though the developers themselves believed they were faster.

That second one stings, and people love to wave it around as proof that AI is overhyped. But here's the thing. METR measured one task at a time. That is not how I work anymore, and I don't think it's how anyone using AI seriously works either, whether you're writing code, briefs, slide decks, contracts or analysis.

There's also a third story worth holding in mind, because it sits in the gap between the two studies. A team at SpareBank 1 Utvikling went "Claude-first" for a few months in their pair-programming and TDD work, then deliberately pulled back. Their feedback loops got slower, their critical thinking flattened, and they noticed they were drifting into clicking "apply" on suggestions without thinking. They didn't reject AI. They redesigned the loop, kept AI where it added clear value, and went back to manual work where the tight feedback cycle was the actual product. Asgaut Mjølne Söderbom wrote about this in a really honest LinkedIn post that's worth a read.

That story matters because it shows the productivity question is rarely just about speed on a task. It is about whether the tool fits the process you actually need to run. AI didn't make them slower as such. "AI first as the default driver" made them slower in a context where their existing feedback loops were doing real work. Different setup, different answer.

How I actually work now

I kick an agent off on one task: a draft, a code change, a research scan, a slide outline. I think through the next one. I check the result of the first when I naturally have a free moment. The win is not that task A finishes faster. The win is that I'm handling A, B and C in the time it used to take me to grind through A alone.

Measuring a single task and concluding AI doesn't help is a bit like timing one lap and concluding the relay team got slower. Sure, maybe the lap was slower. But you're watching the wrong race.

So the question I care about isn't "did this one task go faster?" It's "how many threads can I keep warm at once without my brain melting?" And the answer, for me, went up a lot.

Worth flagging before we go further: that "for me" is doing real work in that sentence. I'll come back to it in part three, because not everyone gets a calmer workday from running three threads in parallel. Some people get faster, and more stressed, at the same time. That gap is worth taking seriously.

Does individual gain become employer gain?

A fair question many people ask: does an individual AI gain actually turn into a gain for the employer? For me the answer is simple. Either fewer people do the same work, or we raise both the volume and the bar. More done, and better, because we spend our time on the substance instead of the boring parts. Both are happening right now.

That said, I don't think the goal is to turn everyone into a "10x" or even a "5x" version of themselves. The multiplier on any one person isn't really what matters. What matters is that the value of AI use across the organization comfortably covers the cost of the tools across the organization. The math should land at the company level, not at the individual level. Some people will get massive leverage from AI. Some will get a steady small lift. A few may get very little for now. That's fine, as long as the net across the team or the company is positive. Diversity of working styles is a feature, not a problem to optimize away.

What does my own usage actually cost?

Let me put a number on it, because I can. I work at Microsoft, where token usage is effectively unlimited internally, at least for the time being. Out of curiosity I checked what I'd be paying at consumer list pricing. On a heavy month the answer lands around USD 4,000. That's roughly USD 48,000 a year in model usage for one person.

To be honest, that monthly number has a bit of inflation in it. I know I'm running more expensive models than I strictly need (more on that below). When I look at the actual week-to-week variation, it sits somewhere between USD 500 and 1,500. It moves with what I'm working on and how many days I'm actually at the keyboard.

Now, would my true value justify that spend? I think for the work I do, yes, fairly comfortably. If those tokens let me run three threads where I used to run one, the bar to clear isn't "is 4k a lot of money" (it is), it's "does the multiplier return more than an FTE's worth of extra output." For cross-context work like mine, it usually does.

The trend is what surprised me most. My consumption grew about 2.5x from March to May, almost perfectly linear. That sounds alarming until you ask where it's headed. I suspect I'm closer to a plateau than a runaway curve, because these days I'm more a document writer than a coder. Writing and reasoning over text has a natural ceiling on how many parallel agents are useful. You can only steer so many drafts at once before you're the bottleneck again. Tasks that fan out cleanly (code changes across files, batch analysis, scripted research) scale differently. You can run many in parallel almost indefinitely. Prose pulls back toward one careful human holding the thread.

But here's the honest caveat, and it matters. I spend that much partly because I can. I run high thinking and large context on basically every call, top model every time, because nothing internally tells me not to. If I switched to an auto-model router that picks a cheaper model for the easy 80 percent of tasks, I'd almost certainly slash that bill with very little loss in quality. So a heavy 4k month is closer to a ceiling on what I happen to use than a floor on what my value actually requires.

And I'm well aware I'm lucky here. Having no cap on spending is a privilege, not a default, and I don't take it for granted. It also may not last. What's unlimited for me today could become metered company-wide tomorrow, the moment someone does the math across thousands of employees. The day a budget shows up, the "because I can" habits get expensive fast, and the auto-model question stops being a curiosity and becomes the whole game.

Meanwhile, in some places the incentive runs completely the other way. Mostly US teams, from what I hear. People bragging about topping internal token leaderboards. Burning the most credits as if that were the achievement. There's even a name for it now, tokenmaxxing, the same family as looksmaxxing and every other -maxxing trend the internet keeps generating. The maxxing-of-everything mindset caught up with AI, and the result is people treating consumption as if it were the contribution. That's the inverse of efficient. It looks like adoption theater dressed up as productivity.

Get tokenmaxxing t-shirts at https://www.etsy.com/shop/ContextWindowShop

The flip side, in parts of Europe, is the opposite extreme. Worker councils block employers from looking at individual token usage at all, on the grounds that it could be repurposed as performance monitoring. I get the intent. I also think both ends are missing the point. What I produce versus what others produce is the measurement, not how many tokens it took to produce it. Different tools for different use cases, different jobs, different people, the same diversity argument as elsewhere in this series. The leaderboard is the wrong leaderboard.

There's a sharper way to frame what the leaderboard gets wrong. In a June 2026 note on what he calls the frontier ecosystem, Satya Nadella (CEO Microsoft) splits a firm's capability into human capital (the knowledge, judgment and pattern recognition of its people) and token capital (the AI capability it builds and owns). The useful bit, for this argument, is that token capital is something you build and own, not something you burn. Tokenmaxxing optimizes for spend. The thing actually worth compounding is the learning loop on top of the models: the workflows, evals and accumulated judgment that make each token you spend more useful than the last. Measured that way, the heaviest user on the leaderboard might be the one creating the least durable value, because consumption that doesn't feed back into a better system is just exhaust.

There's a less comfortable version of "because I can" too, and I'd be dishonest to skip it. Tokens aren't free in energy or water, even when they're free to me. High thinking and large context on every call has a footprint, and right now I'm optimizing for my own productivity while the wider environmental cost sits on someone else's ledger. Me winning, world maybe not. I don't have a clean answer to that. If I'm honest, I'm partly relying on control and regulation, and on providers getting more efficient, to put limits where my own restraint doesn't. That's not flattering to admit, but it's true. A price signal, a cap, a budget, a carbon cost, would probably make me a more thoughtful user overnight.

I'll also say this, because I think it's honest: I would much rather burn GPU cycles on actual knowledge work than watch them go to crypto mining farms that have feasted on cheap power in places like Norway for years. That's energy straight into the bin, in my opinion. I'm no crypto fan, and there is no point pretending otherwise. AI at least produces something the people paying for the work value. The footprint conversation matters, but it should not pretend all GPU cycles are equal.

The numbers back the framing, even if they don't decide the argument. IEA's Electricity 2024 report bundles data centres, AI and crypto together at about 460 TWh globally in 2022, projected to more than 1,000 TWh by 2026, roughly Japan's annual electricity use. Cambridge's Bitcoin index puts Bitcoin alone at around 150 TWh per year, roughly a third of all data centre power, sustained for fifteen years and counting. Bitcoin produces a price chart. AI use at work produces drafts, code, summaries, decisions that the people paying for the tokens are choosing to pay for because they get something useful back. I'm not pretending blockchain itself is worthless as a technology, but proof-of-work mining at this scale is, for me, a strange way to "create" value. I'd rather see those terawatt-hours go somewhere that produces output a human actually uses.

The trend on the supply side is encouraging though, and worth taking seriously. Look at what's happened with image models recently: quality has gone up sharply while model size has gone down. The same shift is starting to show up across the board. Smaller, more specialized models, automatically routed to the right task, will balance GPU cycles much better than today's "throw the biggest model at everything" default. More value per token spent. Less footprint per unit of useful work. The economics and the environmental math both improve at the same time, which is rare in tech.

Which loops straight back to the employer question. The gain is real, but so is the waste. The interesting work isn't proving the spend is worth it. It's figuring out how much of it was ever necessary.

Why this matters for the series

I'm spending a whole post on this because the "context-switch tax" is the hinge for everything that follows. If AI mostly lowers the cost of juggling many contexts, then the people who benefit most are the ones already juggling many contexts. And the people who feel the squeeze are the ones who relied on stable, single-track work.

That's not a neutral, evenly spread gift. It tilts the field.

Which is exactly where part three goes: who AI actually favors, and who it quietly squeezes.

See you in the next one :)

AI Doesn't Replace Your Job. It Changes Who Gets It. (Part 1 of 6)

2026-06-15T19:41:30.365+02:00

TL;DR: Most of the AI jobs debate is stuck on the wrong question. It keeps asking how many jobs vanish. I think the bigger story right now is that AI removes friction, and that quietly changes which people the work flows to. This is part one of a six-part series where I work through what I'm seeing in real time.

For those who prefer the director's cut, keep on reading.

The debate about artificial intelligence usually circles the same drain: how many jobs disappear. Do developers become redundant? Do lawyers, analysts, designers and consultants get replaced? I think that debate misses the most important thing happening right now.

AI isn't just about automation. It's about less friction.

I work in IT, with a background as a developer, consultant, product manager and architect. Less than a year ago I watched a lot of developers be openly skeptical of AI. Some called it hype. Some called it cheating. A few were outright hostile. Now I bump into many of those same people at the coffee machine, and they thank me for being early with my perspective.

Living in comforting denial

Despite these individual awakenings, the broader picture is strangely disconnected. A recent KPMG AI survey in Norway (April 2026) captured this. The phrase that stuck with me when I first saw the numbers summarized was still living in comforting denial, and I think it fits.

According to the poll, 73% of respondents believe their daily work will be quite similar in five years. At the same time, 69% report having no formal training in AI at work, and 65% say top management in their company lacks an ambitious AI strategy.

I might be over-interpreting this, but here is my perspective: Many employees who use AI tools individually feel a real gain. But employers and management do not see or capture that gain at scale yet, leaving the majority of the workforce believing their daily life will remain unchanged.

The flip side of this denial is opportunity. Those who choose to understand AI technology now, and actively figure out how to weave it into existing processes, are getting a massive head start. In any competitive market, that gap is going to matter.

It's not because AI writes magic prompts for us.

It's because the workday simply feels different.

So what actually changed?

Here's the honest part. The biggest change for me isn't that AI writes documents or code faster. It's that the cost of switching context has dropped dramatically. I've written about this before, both about how an AI sidekick tamed the context-switch hydra and about when your agent writes code faster than you can review it.

It used to cost me a lot of mental energy to jump between domains, codebases, specs, customer context, meetings and problems. I had to reload the entire mental model from scratch. Dig into documentation. Read code for hours before I could produce anything useful.

The biggest cost in knowledge work is rarely the task itself. It's the time it takes to climb back into it after you got interrupted. (There's one obvious exception: when you're actively learning something new, that still takes real time. But AI itself can be a great teacher, which shortens the ramp-up.)

Now I can use AI to scout ahead before I go deep myself. I get a draft structure in seconds. I work on content instead of staring at a blank page. I can talk through possible solutions with an agent before I commit, and get a complex code area summarized before I even open the files. I also tell my agent to keep working until they need a human-in-the-loop decision or input from me. The agent is the tool in the process. I am the worker, and the one who decides.

I don't write two-word prompts

I want to kill one myth right away. I don't type two words and hope for the best. I use AI as a sparring partner. I describe problems in detail, I push back on the solutions, and I work my way toward an answer.

Anecdotally, I recently created a PowerPoint presentation for a conference using an agentic flow. The session itself, Search, then Chat: How Copilot Orchestrates Answers, is about exactly this kind of grounding: how an LLM gets useful by reaching into real data instead of guessing from training. Fitting, then, that the deck for it was built the same way. I started with my topic and abstract, allowed the agent to ground itself in work data I have on the topic, and then added a brain dump of what I planned to present and demo. The resulting deck was the best I have ever made in terms of flow and content, and the session it powered scored 4.68 out of 5 in attendee feedback.

Research was pulled in and verified in an extra step by sub-agents, but also manually by me. All facts have to be validated, always. Nothing weird about that. Even timing and speaker notes were added, allowing me to focus on the actual demos and the session flow. I had it all in my head already; I just needed it structured.

For me this means I solve both small and large problems faster. Not necessarily because I got smarter, but because the friction between thought and action got lower.

That's the whole thesis of this series. People keep framing AI as a machine that deletes roles. I think the more interesting effect is that AI is a friction remover, and friction has never been evenly distributed. Some people swim in it. Some people drown in it. AI changes who's swimming.

And in case it helps: I didn't actually learn to swim properly until I was an adult. So it's never too late to learn to swim in AI either.

Where this is going

Over the next five posts I'll dig into the parts of this that I keep arguing about with people at the coffee machine:

Part 2: Why the real win isn't faster output, it's cheaper context-switching (and what the research actually says).
Part 3: Who AI actually favors, and who it quietly squeezes.
Part 4: The strange situation where society has too few and too many people at the same time.
Part 5: Consultants, context-switching, and what kind of value survives.
Part 6: Human in the loop. When to replace, when to keep, and why.

I'm not writing this because I think I'm holding the answer key. I'm writing it because I'm watching the change happen in real time, and I'd rather think out loud than pretend I have it figured out.

People don't become worthless. But some kinds of value get cheaper. That's the thread I'll pull on for the rest of the series.

Next up, part 2: the context-switch tax, and why I stopped trusting "AI made task A faster" as the right way to measure anything.

Stay tuned :)

If You're Not Using AI at Work, You're Stealing From Your Employer (and Five Other Things I Believe)

2026-06-15T19:40:12.379+02:00

...and if your employer is denying you AI tools, they are robbing themselves.

Back in April 2025 I said something close to this in an internal Teams meeting where we were discussing AI tooling: "if you're not using GitHub Copilot, you are stealing time from Microsoft." A few people took it very, very badly. My manager backed me up. A year on, with the tools an order of magnitude better and the gap between users and non-users wider than ever, I mean it more, not less. So I am generalizing the line and putting it out here.

TL;DR: AI is not mainly a job-killer. It is a friction remover that changes who the work flows to, and it exposes where your organization was already slow. The interesting question is no longer "how many jobs disappear," but "who does the work flow to now, and where do the loops actually break?" One catch worth flagging early: if AI absorbs the entry-level work, we stop training the juniors who become tomorrow's seniors, and the squeeze comes back later. This post is the front door. The full argument runs across six parts. Read as much or as little as you want.

The 30-second version

Denmark used to have two radiologists read every breast cancer screening. Today an AI system triages around 70% of the lowest-risk mammograms so a single experienced radiologist signs them off. More cancers found. Fewer false alarms. Workload cut by a third to a half. The same result has since shown up at much larger scale, including a UK study of 175,000 women. And notably, this is predictive AI doing one narrow job well, not a chatbot. The human is still in the loop. The loop just got redesigned around what only the human should do.

That, in miniature, is what I think is actually happening with AI at work.

Meanwhile, on my own desk: I can produce a one-pager explaining a complex API change in minutes. The document then sits for weeks waiting on the right people in the right rooms to agree to agree before anyone is even allowed to read it. AI did its job. The org chart did not.

I work at Microsoft. I am not going to pretend we are bad at this, because we are not, but we are large, and large means many hoops to jump through. Small organizations with actual decision authority may have a real and underrated advantage right now. Not because their AI is better, but because their loops are shorter and their people are not always too busy to say yes to a smart idea.

Those two stories are what this series is all about. Where AI lands well, the work flows to different people and the loops get tighter. Where AI lands badly, it makes painfully visible that the bottleneck was never the artifact. It was the humans coordinating around it.

What I actually believe

The AI jobs debate keeps asking the wrong question. The interesting effect is not "how many jobs vanish," it is "who does the work now flow to."
The real productivity win for me is not faster output. It is a lower mental cost of jumping between tasks, what we call cheaper context-switching.
The gains are uneven. AI favors people who thrive on tempo, many contexts and complexity, and puts pressure on those who need stable, predictable surfaces.
Society has a strange shape right now: too few people for some work, too many for other work, at the same time.
The consultant role does not die. The "I sell hours" version of it gets exposed. The "I bring patterns and context fast" version gets more valuable.
Human in the loop is not a magic phrase. It is a design question. Why is the human there? Judgment, trust, legal, or habit?

Not from the CEO podium

Quick note on where I'm writing from, because it matters. I'm not carrying water for Sam Altman, Elon Musk or Dario Amodei. Those three say a lot of conflicting things about both gain and danger, often in the same month. Altman publicly walked back his own "jobs apocalypse" prediction in May 2026 even as the layoffs kept coming. Amodei called for a global pause on AI development a few days ago, right after Anthropic was valued at $965B. Critics noted that a pause would conveniently slow down competitors. The message from the CEO podium shifts with each funding round and each press cycle. Read it that way.

I write from the end-user side. I use these tools every working day. I can see through the sales pitch and the doom pitch at the same time. What I describe in these six parts is what is actually happening at my desk and around me, not what is being announced at a keynote.

Two things that follow from that:

AI as a technology is not a bubble. It is too useful, too widely adopted, and too embedded in real workflows for that.
Some of the companies betting big around it almost certainly are a bubble. Same pattern as the internet. The web was real. Plenty of dot-com darlings were not. Eventually some current AI names will go the same way, regardless of how confident their CEOs sound today.

Whether the largest of them, the big-tech bros at the top of the stack, end up "too big to fail" is a separate question, and not one I have a clean prediction for. I just know it shouldn't be a question we let them answer alone.

The six parts

You do not have to read all six to get the point. The TL;DR up top is the point. Each part adds the evidence, the arguments and the lived experience that got me there.

About the "stealing from your employer" line, since people always come back to it: I am not saying every job needs AI in it every minute. I am saying this:

If your work is knowledge work, and a tool exists that meaningfully changes what you can deliver, refusing to learn it on the clock is a choice your employer is paying for.

You do not have to like the framing. But it is worth sitting with for a minute before you dismiss it.

For the rest: the harder lines in this post are deliberate, and I mean them. But I also have a lot of empathy for everyone navigating this right now. My perspective is one of many, and diversity of approaches matters. What I do believe, at the bottom of all of it, is this:

Almost anyone can find at least one AI tool that simplifies at least one thing in their workday. Which means everyone must, or at the very least should, be given the chance to look.

Also in Norwegian: Parts of this thinking have been published in Norwegian, for those who prefer it. The op-ed KI endrer hvem som lykkes i arbeidslivet on digi.no covers much of the workforce angle. The LinkedIn piece Verktøyet forvitrer ikke hjernen din. Latskap gjør det is a reply to Bjørn Stærk's "AI keeps disappointing" critique, defending why I think the framing of skill atrophy is wrong.

Pick the part that itches the most :)

Tokenmaxxing: The Art of Looking Productive

2026-06-11T16:23:00.000+02:00

Tokenmaxxing is what happens when AI developers confuse spending tokens with making progress.

A simple task becomes a giant prompt. A giant prompt becomes a massive context window. The massive context window becomes an expensive experiment involving agents, tools, memory systems, and enough tokens to finance a small village.

The result is often the same:

A slightly better answer, a much larger bill, and a screenshot for social media.

Somewhere along the way, “using AI efficiently” turned into “see how many tokens I can burn before the model gives up.”

Tokenmaxxing isn’t optimization.

It’s not engineering.

It’s not productivity.

It’s the AI equivalent of revving a sports car in a parking lot and calling it transportation.

Still, we’ve all done it.

We’ve all stared at a dashboard showing millions of tokens consumed and thought:

“One more run.”

That’s why I made the Tokenmaxxing design.

Not as a celebration.

As a warning.

Check out the designs at: https://www.etsy.com/shop/ContextWindowShop

When Your Agent Writes Code Faster Than You Can Review

2025-09-22T18:02:00.003+02:00

Agentic coding has the promise to unlock a turbocharged workweek, cranking out pull requests faster than any keyboard warrior could manually manage. The real bottleneck isn’t how quickly code appears—it's how quickly humans can keep up with the reviews. If you’re thinking about coasting on those newly liberated hours, beware: the pace is relentless and those who snooze will get lapped. Adapt, hustle, and wield your extra time, or get comfortable watching the leaderboard from the bottom.

PS! I continue to recommend human code reviews and remain open to updating my perspectives as AI evolves :)

Short take: review is the constraint; ship more anyway.

A PR takes ~6 hours to write and 15–20 minutes to review—per reviewer. Agentic coding (Copilot and friends) doesn’t cancel your review policy; it makes it matter. As adoption spreads, you spend more time reviewing and still ship more.
It does not matter if the agentic multiplier is 1.2x, 2x, 4x or more, your team will still benefit. However, when does that flip and review starts choking the flow? Read on.

It doesn’t “flip” mathematically, but in practice review starts choking the flow when mr ≈ 1 — about 10× coding speed with two reviewers (r≈0.097) or ~20× with one (r≈0.049) given 6h/PR and 15–20m per reviewer.

Assumptions (and please argue my assumption data)

One author. We model one‑reviewer and two‑reviewer policies.
Coding per PR ≈ 6h. Review per reviewer ≈ 15–20m. (Yes, short. Keep it that way.)
That gives a review/coding ratio r per reviewer of ~0.042–0.056; we use ~0.049. Two reviewers ≈ double r.
Agentic coding is a multiplier m on coding speed (1.2×, 1.5×, 2×, 3×, 4×).

Light math, heavy impact

Split the week between writing and reviewing. If writing gets m× faster, more PRs arrive, so review minutes go up. A back‑of‑napkin math formula for team throughput vs. today:

gain ≈ m·(1+r) / (1+m·r)

r is total human review time divided by authoring time for a PR. Bigger r → more RAT (Review-Added Tapering): the gains flatten as review effort eats into coding speedups.

Case A — One human reviewer

Throughput climbs, and review time takes a bigger slice of the week, but you have headroom at these review times.

Figure 1 — Team throughput vs. agentic multiplier (one reviewer; 15–20 min sensitivity band).

Figure 2 — Share of team time spent on review (one reviewer).

Case B — Two human reviewers

Two required approvals roughly double review time per PR, so you feel the constraint sooner.

Figure 3 — Team throughput vs. agentic multiplier (two reviewers; sensitivity band).

Figure 4 — Share of team time spent on review (two reviewers).

Clearer throughput tables

Two quick tables; both assume a team of eight and the same PR size/quality.

Table A — Adoption curve (8 people; each adopter is 1.2×)

Adopters (of 8)	Avg multiplier (m̄)	Throughput × (1 reviewer)	Throughput × (2 reviewers)
0	1.000	1.00	1.00
1	1.025	1.02	1.02
2	1.050	1.05	1.05
3	1.075	1.07	1.07
4	1.100	1.09	1.09
5	1.125	1.12	1.11
6	1.150	1.14	1.13
7	1.175	1.17	1.16
8	1.200	1.19	1.18

Table B — Throughput as average team multiplier grows (to 4×)

Avg multiplier (m̄)	Throughput × (1 reviewer)	Throughput × (2 reviewers)
1.0×	1.00×	1.00×
1.2×	1.19×	1.18×
1.5×	1.47×	1.44×
2.0×	1.91×	1.84×
3.0×	2.75×	2.55×
4.0×	3.51×	3.16×

About those “free” minutes

Agentic coding frees time. If it doesn’t become more (or better) PRs, it still has to land somewhere:

Best: quality. More tests, tighter diffs, cleaner commits. Review gets faster when diffs are tidy.
Good: non-code work. Specs, comms, reviews, mentoring—all the glue.
Worst: Xbox/Netflix. Teams that reward shipped work will see the reinvestors lap the coasters.

Push the pivot out

Keep PRs small—cheap to read is cheap to ship.
Let CI and AI do pre-review: lint/tests/security, AI summaries and risk flags.
Block time for review—don’t background it.
Two approvals only when it truly buys risk down.

Bottom line

Manual review doesn’t kill agentic gains. With 6h write / 15–20m per reviewer, one-approval teams have plenty of headroom; two-approval teams still gain but meet the review wall sooner. Convert freed minutes into smaller, better PRs—or more of them— and the meter on shipped work keeps spinning faster.

Governing Feedback Data Sharing in Microsoft 365 Apps and Copilot

2025-08-13T22:02:00.002+02:00

Microsoft treats user feedback as confidential and uses it to improve the product experience. That does, however, involve real people reading what’s submitted. For many organizations that’s fine; for others it’s something they want to control—particularly when feedback is sent from Copilot chat, where a message might contain sensitive business context.

Good news: you can govern what can (and cannot) be sent in the feedback dialog.

Note: Prompts and responses used inside a Copilot conversation are not viewed by Microsoft. What I’m covering here is only the optional feedback form users can submit.

Where to configure Feedback policies

These settings live in the Microsoft 365 Apps admin center as Cloud Policy:

Go to config.office.com → Customization → Policy Management.
Create or edit a policy configuration for Microsoft 365 Apps and scope it to the users/groups you want.
Search for Feedback to find the policies below.

Official docs for Cloud Policy: https://learn.microsoft.com/microsoft-365-apps/admin-center/overview-cloud-policy.

These policies apply to apps and web experiences that use the standard “Send feedback to Microsoft” UX from Microsoft 365 Apps (including Copilot surfaces that use that dialog). Teams uses its own policy model for feedback, so manage Teams separately.

Also important: these settings are not “restrictive by default.” If you don’t explicitly disable them, users can include logs and content samples by default.

See https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-feedback-ms-org for a list of products covered by feedback policies set at config.office.com

The four knobs that matter (set to Disabled to restrict)

I’m listing them in the order I recommend you evaluate them.

1) Allow Microsoft to follow up on feedback submitted by users

What changes: the small text at the bottom of the dialog that says Microsoft may contact the user.
Why it matters: disables the consent for follow-up (no contact back). Many orgs prefer no outbound follow-ups to end users.

2) Allow users to include screenshots and attachments when they submit feedback to Microsoft

What changes: hides the Include a screenshot control in the form.
Why it matters: screenshots often contain customer content.
Gotcha: this does not cover log/content attachments (that’s the next policy).

3) Allow users to include log files and relevant content samples when feedback is submitted to Microsoft

What changes: removes the option that shares the prompt, generated response, relevant content samples, and additional log files with the feedback.
Why it matters: this is the big one for Copilot. When enabled, users can (and by default will) include parts of the conversation and context data. Setting it to Disabled prevents those from being sent.

4) Allow users to submit feedback to Microsoft

What changes: blocks the feedback dialog from appearing at all.
Why it matters: the nuclear option. If you don’t want any feedback sent from the product UI, turn this off.

What users will see

Here’s how the UI shifts as you apply the policies:

With default settings, users can add a screenshot and (by default) include prompt/response + logs/content samples.
Disable follow-up → the small “Microsoft may contact you…” text is removed/changed.
Disable screenshots → the screenshot checkbox/button disappears (users cannot attach images), but log/content sharing may still be available unless you disable it too.
Disable log files and content samples → the “Share prompt, generated response, … and additional log files” option is removed, so no conversation context is shared.
Disable submit feedback → the dialog doesn’t show.

Recommended approaches

Pick the level that matches your risk tolerance:

Leave as is: The default behavior allows Microsoft to capture valuable feedback to adjust products and experiences to the better for those using them.
Balanced: Disable screenshots and log files/content samples, allow feedback, and optionally disable follow-ups.
Strict: Disable screenshots, log files/content samples, and follow-ups.
Locked down: Disable submit feedback entirely.

If you do allow feedback, you may want to consider disabling the log files and relevant content samples option for Copilot users. While this data is handled securely by Microsoft, turning it off can help ensure that no conversation snippets or contextual information are included in feedback—something some organizations prefer for peace of mind or to align with their internal data handling practices.

Final thoughts

I work at Microsoft, and I know there are actual people reading feedback to make our products better. That’s a feature, not a bug—but each organization has different requirements for customer data. With Cloud Policy you can decide what’s appropriate for your tenant, from light filtering to full lockdown.

Again, this doesn’t change how Copilot processes prompts during normal use—those aren’t viewed by Microsoft. We’re only talking about the separate, optional act of sending product feedback according to your level of comfort, and is why the options are there.

If you’ve got a mixed environment (e.g., Teams), remember to set feedback controls where that app expects them.

Happy governing!

Taming the Context-Switch Hydra: How an AI Sidekick Saved My Sanity

2025-05-27T11:36:00.000+02:00

TL;DR:

GitHub Copilot (in Agent mode with Codespaces) dramatically cuts down the cost of context switching, perfectly fitting my chaotic, multitasking workstyle. It lets me stay productive and in flow, even as I juggle coding, helping others, and specs—all while being 51 and still loving the craft.

For Those Who Prefer the Director’s Cut …keep on reading

One small step for SharePoint intranets, one giant leap for news roll-up

2024-07-08T10:15:00.002+02:00

..well, not really, but it’s an improvement which makes news roll-up match multiple information architecture scenarios. I’ll leave it up to those setting up intranets to gage the usefulness, and I know there has been demand for this feature.

A shoutout to my old peeps at Puzzlepart for wanting this feature – adding to many other customers who have asked for this feature.

So, what am I talking about? In the news web part, when you use “Select sites” or “Recommended for the current user”, a new option to either show or hide the site title will show below the sites you pick.

When displaying news from one site, the site title is already hidden as you are on that one site anyways. If you pick more sites, you may want to hide the site title because content authoring happens in multiple sites because of information architecture, not because you need to show the site title.

Here’s an example with and without site titles.

Happy intranet authoring!

What’s great at Microsoft, is that anyone can contribute anywhere. The above feature was implemented by yours sincerely as part of one of the yearly hackathons we have at Microsoft. It allowed me to look more closely at how web parts are built in SharePoint, and also solve a customer pain. Win-win!

Search nugget: The beauty of SharePoint Site Columns

2024-06-25T09:15:00.001+02:00

The scenario I’m sharing is not a new one, but (somewhat) recent changes to SharePoint indexing of items may make the scenario easier to solve.

Before we dig into the details, let's talk about Microsoft Syntex, as it has bearing on the nugget I will share. Microsoft Syntex is a service that uses AI and machine learning to automatically sort and classify documents across SharePoint, Microsoft Teams, OneDrive for Business, and Exchange.

Or simply put in terms for SharePoint: Pulling structured data out from unstructured data and store it as metadata for easier use and retrieval. Something we have done manually or via customized processed for the longest time in SharePoint lists and libraries.

Microsoft Syntex is licensed via a pay-as-uou go model, where you pay for items processed. See https://learn.microsoft.com/en-us/microsoft-365/syntex/syntex-pay-as-you-go-services and for more details and the offering currently includes these features:

Prebuilt document processing
Structured and freeform document processing
Unstructured document processing
Autofill columns
Content assembly
Image tagging
Taxonomy tagging
SharePoint eSignature
Document translation
Optical character recognition (OCR)
Microsoft 365 Archive
Microsoft 365 Backup (Preview)
Microsoft 365 Backup Storage (Preview)

A Microsoft Syntex enabled library also enable a better context query user experience. See https://learn.microsoft.com/en-us/microsoft-365/syntex/metadata-search for details.

Let's get to it!

Say you have a library where you add a new column. In this case a number column.

In a search scenario for the library you want to filter results based on the number value. One example being all items with a value above 100.

In my case the column has an internal name of PnPNumberColumn. If the column was manually created at the library it would output a crawled property named ows_PnPNumberColumn. This crawled property could be mapped to RefinableInt00 and after re-indexing you could use the below KQL query to list all items with a value above 100. If you add an alias to the managed property you could use this instead.

RefinableInt00>100

Now, let us go back to the site column scenario. Site columns will in addition to the default crawled property, create an additional crawled property and an automatic managed property. This is described at Automatically created managed properties in SharePoint Server which also apply to SharePoint Online despite what the article is tagged as.

The caveat of the automatically created managed properties is that they are of type text, which is not very useful when it comes to numbers. The example column above yields an automatic managed property named PnPNumberColumnOWSNMBR. This means I can query with:

PnPNumberColumnOWSNMBR:500 or PnPNumberColumnOWSNMBR=500 and get a match, as it matches on text. PnPNumberColumnOWSNMBR>500 would however be invalid KQL.

And here is the nugget. In addition to PnPNumberColumnOWSNMBR we now also get an additional property PnPNumberColumnOWSTNMBR. Note the extra T.

A word from our sponsor: This tip was brought to you by indexing advancements made for Microsoft Syntex. Microsoft Syntex greatly automates creation of site column for the average user. What are you waiting for?

And don’t be fooled by the schema admin page saying the property is of type text, as it is indeed of type number. A fact somewhat called out in a notice when you view the property settings, so you just have to trust me.

Below is screenshot showcasing the behavior where the query PnPNumberColumnOWSTNMBR>499 return the sample document. Easy as pie!

PS! The property is not refinable so you can not use it as refinement filter. If this is your case keep on as you always have and map to e.g RefinableInt00

00000101

2024-06-06T15:09:00.001+02:00

How time flies! I have now been 5 years at Microsoft. I started as a Program Manager, which changed into Product Manager, and now I’m an Engineer.

Despite the title changes the work I do has not changed much over these five years. I have always been a jack of many trades, and I enjoying doing many things at once. When everything is interesting and challenging, it is hard to cut something out. And I have been lucky to be allowed to work to my strengths while still learning – and I love to learn!

What has changed over the years is that I have learned to appreciate process and governance more than before. Which is why I have onboarded to internal roles as privacy champ, compliance champ and responsible AI champ – the last one becoming increasingly important as Microsoft focus all energy on Copilot. Luckily for me loving search as a function and search tech, is that Microsoft Search plays an important role also in Copilot.

What the next one or five years will bring I have no idea, and it’s not important. I’m still a day to day kind of person, with no long term plans. If what I do is fun, challenging and benefits Microsoft customers, I will keep doing it. And for those who know me, I’m not giving up om my long term mission to cut ties from classic SharePoint search features still having dependencies in the modern world of Microsoft Search. Some cuts are hard but still important to ensure the success of future experiences.

Cake time!

Copilot Productivity Tip – Structured formatting in Word

2024-03-27T10:40:00.000+01:00

Time spent per day before: 15 minutes per document
Time spent with Copilot: 5 minutes per document

Resources

Taking my previous post about re-writing text in Word, we can prompt to have key points from the text pulled out and as an example formatted as a table for easier consumption.

The prompt used is “Extract key points into a table with two columns for key point header and details”, and the output is the table below.

Key point	Details
Copilot can rewrite the content	Copilot can check and improve the tense, the passive voice, the readability, and the personal tone of the content.
Copilot may or may not respect the writer's style	Copilot's suggestions may vary depending on the instructions given by the writer. The writer can try to specify the style they want and see what Copilot does.

Copilot Productivity Tip – Word re-write

2024-03-22T10:35:00.008+01:00

Time spent per day before: 30-60 minutes per document
Time spent with Copilot: 5-10 minutes per document

Resources

Writing in a language that is not one's own can be challenging. That is why Copilot can help rewrite the content to make it more consistent and clear. Copilot can correct the tense, the passive voice, the readability, and the personal tone of the content. This way readers can enjoy the content more and understand the main points better.

Some writers may have a specific style that they want to use. Copilot in Word may or may not respect that style, depending on the instructions given. But one can always try to tell Copilot what kind of style they want and see what happens. Maybe Copilot will surprise them with some creative suggestions. Or maybe Copilot will ignore them and do whatever it wants. Who knows?

Original draft

Here’s the original blog-post I started out with before throwing Copilot at it.

Not everyone is a native writer of the language they produce content in. Thus, using Copilot to rewrite your content for consistency in terms of tense, passive language, readability, and personal flavor will ensure those consuming the content have a better experience and more clearly pick up on the points you want to come across in your argumentation.

If you have a particular writing style, then Copilot in Word may or may not be able to assist, but you can try to add this as part of the prompting instructions and verify the outcome.

Automatic rewrite

When using the auto rewrite feature this is what I ended up with.

Sometimes, people write content in a language that is not their native one. Therefore, using Copilot to edit your content for consistency in grammar, voice, clarity, and tone will help those who read the content have a better experience and understand the messages you want to convey in your reasoning.

If you prefer a specific writing style, then Copilot in Word may or may not help you, but you can attempt to include this in the prompting instructions and check the result.

Manual prompt for rewrite

This time around I wanted to give more instructions to simplify my writing.

“Rewrite the text using shorter sentences and language understood by an audience with little experience in Copilot or Word. Make instructions concise and relatable for beginners.“

Do you write in a language that is not your first one? Then Copilot can help you make your writing better. It can fix grammar mistakes, make sentences easier to read, and use the right words for your message.

Do you have a favorite way of writing? Copilot in Word might be able to copy it. Just tell it what you want and see what it does. You can always change it if you don't like it.

Manual prompt with styling

And this is the prompt I ended up with for the final post, as it reflects some of my personal writing style. Maybe this will makes it way into Word eventually using writing samples for style.

“Rewrite the text using shorter sentences and language understood by an audience with little experience in Copilot or Word. Make the text longer than the original, write in third-person tense and **DO NOT** use *I*, *You*, *Your* and *We*. Throw in some subtle irony and sarcasm.”

Copilot Productivity Tip – Teams Message Rewrite

2024-03-20T10:29:00.010+01:00

Time spent per day before: 10 minutes, rethinking the words to use
Time spent with Copilot: 1-2 minutes, letting Copilot do the work

Resources

Rewrite and adjust your messages with Copilot in Microsoft Teams

One of the challenges when writing is to convey feelings or emotion on what you type. I like to be short and concise in my messaging, but sometimes this may not be the best way to communicate when talking to people you don't know, or even people you know.

Let’s take the message “I don’t agree with your points” and run it thru Copilot to make it longer and Enthusiastic.

The output can be something like: “Thank you for sharing your perspective. However, I have a different view on the matter and I would like to explain why I disagree with some of the points you made.” which is less likely to piss Vesa off :)

You can even do a customized prompt for formatting: “Make it sound like it was written by Super Mario”. The above prompt is actually a prompt hack to overcome Responsible AI to add some Paolo Italian flavor into the message.

Copilot Productivity Tip – Teams Chat Catchup

2024-03-18T10:28:00.014+01:00

Time spent per day before: 30-60 minutes
Time spent with Copilot: 5-15 minutes

Resources

Use Copilot in Microsoft Teams chat and channels (video)

My workday at Microsoft involves communication with multiple teams spread around the globe, which means in-person communication is not always possible. This is why Teams has become the go-to tool for many conversations and discussions. When I start my day at 8am in the morning I know chats has happened in other time zones, and instead of reading everything right away I can use Copilot catchup for a summary, and then decide if I need to read it all.

I typically use the “Summarize what I've missed” Copilot suggested prompt inline in the chat which opens the Copilot pane, or I open the pane manually as seen below with prompts such as “Highlights from the past day” or “Highlights from the past 7 days”.

Copilot Productivity Tip – Teams Meeting Insights

2024-03-15T10:42:00.000+01:00

Time spent per day before: 0-120 minutes

Time spent with Copilot: 0-15 minutes

Resources

The beauty of online meetings with transcripts is the ability to quickly go back and find key points later without having to watch the recording or read thru the full transcript.

By default Teams provides an AI notes section with a quick summary, and using the Copilot pane you can ask more direct questions such as summarizing your talking points, or ask what your action items were for the meeting.

My best example is a late night meeting where I forgot to take notes and the next morning I knew I was supposed to contact an “Andrew”, but had forgotten the full name. Requesting the name in the meetings Copilot quickly gave me the name, saving me around 15 minutes and some grief.

Allowing arbitrary custom scripting in SharePoint Online, or not? – that is the question! (aka Stealing your data since 2001!)

2024-03-08T17:12:00.002+01:00

…and the answer is, as it always has been, NO!

Disclaimer: the opinions of this post are mine entirely, and nothing to do with my work at Microsoft. I have not changed opinion on this matter in the past many many years.

Sparked by the recent message center post MC714186 – Remove Custom Script setting in OneDrive and SharePoint web, I figured I’d write out my stance and my full support of the planned change.

Summary: The Custom Script setting in OneDrive and SharePoint web will be removed in March 2024. A new PowerShell command, "DelayDenyAddAndCustomizePagesEnforcement", has been introduced to delay the change to custom script set on the Tenant until mid-November 2024. The NoScriptSite setting will be configured to True for all existing SharePoint sites and OneDrive sites except for specific site templates. Existing scripts in OneDrive and SharePoint sites will remain unaffected. Administrators can permit the execution of custom scripts on specific SharePoint sites using the Set-SPOSite command.

In the above summary I want to point out that “existing scripts will remain unaffected” means classic page injections. Not SPFx solutions on with the setting requiresCustomScript=true.

The challenge

SharePoint by design is a JavaScript application and has always allowed for extensibility in the UX. In modern ways extensibility is achieved via the SharePoint Framework (SPFx), which you should use, and that is ok. Because by virtue of how SPFx is built any script or logic in a SPFx solution is governed and controlled by design.

To explain what I mean. By arbitrary code I mean someone can insert and freely modify JavaScript that runs in a SharePoint site or page without anyone noticing. One example being a bad actor put script on a page which when a person visit the page then transfers all the persons OneDrive files to evil.corp in the background without the person ever knowing. And this has been possible with SharePoint in classic experiences since always, and also with 3p modern webparts when allowing script to run, or by bypassing settings for a site.

When writing code in a SPFx solution, it is no longer arbitrary. Someone wrote it, built it, and then handed the package over to a person with SharePoint admin role rights to install it (or by an admin role proxy if a site has it’s own app catalog). How diligent the process is for code review and installation is up to each organization, but at least the setup allows for a governed process to help control what is installed into a tenants SharePoint Online experience.

Arbitrary script on the other hand would be JavaScript added to SharePoint sites or pages by any regular user with edit rights or a site administrator. Every Team or Group creator is a site administrator of the associated site, and this is not very controlled in my opinion. With classic SharePoint, script can be injected or allowed via the Script Editor web part, via search display templates, and via something called custom actions. When Modern sites were introduced many years ago, allowing these features were by default turned by setting the “Allow and Customize Pages” permission to false. The feature is more commonly renamed in e.g. PnP PowerShell to NoScriptSite. Documentation on turning this on or off can be found at https://learn.microsoft.com/en-us/sharepoint/allow-or-prevent-custom-script.

Back to the message center post and what changes

In March, the SharePoint admin UX setting to allow custom script on OneDrive sites or self-service sites is going away, and is being replaced by a PowerShell cmdlet function Set-SPOTenant DelayDenyAddAndCustomizePagesEnforcement which you can use until mid-November 2024.
All new and existing sites will be set to block custom scripts unless they were created with any of these web templates: BLANKINTERNETCONTAINER#0, CMSPUBLISHING#0, BLANKINTERNET#0. GROUP#0, APPCATALOG#0, CSPCONTAINER#0.
From mid-November 2024, custom script is disabled for your sites every 24 hours. You can manually re-enable it with for example Set-SPOSite <SiteURL> –DenyAddAndCustomizePages. This means you need to set up a scheduled job every day to re-enable it where needed for SPFx solutions relying on this feature, unless you migrate your ungoverned script solutions to governed ones using SPFx.

Should you be worried?

If you are still on classic pages, then disregard as you are a lost cause anyways. It’s 2024 people! Modern is no longer modern. It is the new classic.

Hopefully most customers have moved over to using SharePoint Framework for any custom JavaScript solution running in SharePoint Online by now. However, the elephant in the room is my infamous Modern Script Editor Web Part- https://github.com/pnp/sp-dev-fx-webparts/blob/main/samples/react-script-editor/README.md. If built without changes then someone has changed the site settings to allow arbitrary script to run for the web part to work. When this is then flipped off every 24 hours by the service, the web part will stop running (which is good!).

Instead of working the web part will render ugly white space instead.

Alternatively you rebuild the web part bypassing the custom script check saying it does not rely on custom script (boooooo on you, and bad governance practice).

It is no secret what my take is on usage of this web part. The sample modern script web part should NEVER be used, and I will argue to my death that there are no good scenarios for it. Sure, it’s quicker to use compared to always creating new SPFx extensions or web parts, but is this ease of use more important than security? My answer is still a big NO! Sure, you may reduce the attack vector by using site scoped app catalogs, and maybe you have the utter most control for who can edit pages in those sites. But is this a long term risk you are willing to take?

Why not just build your scenario solutions in a governed way thus blocking someone from changing the code? If you have access to someone building the Modern Script Editor web part, then you also have access to someone who can do it the right way.

What now?

My hope is that people do not run a script every 24h to allow custom script, or that they cheat on building SPFx web parts to bypass scripting. Instead everyone should embrace this opportunity to get their solutions cleaned up – if they haven’t already.

Happy coding governed solution, and preventing your files from being stolen!

Easier editing of Microsoft Search verticals in SharePoint sites (finally fixed!)

2024-01-18T15:34:00.004+01:00

This is perhaps a tiny one, but for the longest time search verticals in a SharePoint site or SharePoint hub site has been a bit of a mystery when you wanted to edit a vertical. To invoke edit, you had to double click the vertical, as there was no Edit button in the ribbon.

The issue has been known since the feature rolled out, but not addressed. I'll be as blunt to say I decided to take matters into my own hands and just fix it. So here you go, a gift from me to allow a more intuitive way of editing search verticals in SharePoint - as the Microsoft 365 Admin center has had the Edit button always.

At last the experience matches the documentation at https://learn.microsoft.com/en-us/microsoftsearch/manage-verticals#manage-site-level-verticals.

Demystifying Author properties on files in SharePoint and search

2024-01-11T12:49:00.034+01:00

For as long as I have been doing SharePoint, figuring out what properties to use when filtering or displaying search results in regards to people has been a challenge as the documentation in this space is somewhat lacking. I’m not sure why I haven’t done this writeup earlier, but no time like the present.

AI model bias and why responsible technology matters – exemplified by image generation

2023-12-08T13:40:00.003+01:00

In this era of AI where ChatGPT with LLM’s has become the hottest topic in computer science since the Apple Macintosh and the IBM PC, I figured I’d do a small write-up on AI model bias and why paying attention to bias is important. This is especially true when it comes to enterprise scenarios where Microsoft is launching a long range of AI powered copilot experiences.

The author of this article works for Microsoft (December 2023) and is an internal champion for responsible ai and technology as well as internal champion for privacy and compliance.

At Microsoft we have a high bar for delivering responsible AI solutions, which means there is a lot of work put in place to ensure the output from AI systems follow Microsoft’s AI principles to be fair, inclusive, reliable and safe, privacy and security is accounted for, and the systems are accountable.

Any model, that be a large language model (LLM) or a model to generate image will inherently have bias built in due to the training data used. In smaller models you can manually verify the training data to counter some bias and balance the training set, but as models grow large this becomes inherently harder. I’m not saying there are not systems in place to counter training bias already, but to truly counter bias this has to be built into pre and post processing of input prompts and outputs from the models.

I will use image generation as an example where I will show the difference between using image creator in Microsoft Designer (https://designer.microsoft.com/) built on DALL·E 3 from OpenAI and Stable Diffusion XL, which is an open source model from Stability.AI (https://stability.ai/). The Microsoft solution has guardrails in place, where the open source solution do not – unless you add them yourself via prompting. Not saying neither of them are perfect as examples will show.

I want to call out that any bias shown is not statistically verified, and only based on generating a set of sample random images with the same prompt.

Example 1 - photo of correctional officer in a well lit hallway eating a donut

The above eight images are from DALL·E 3. They are all close-up photos showing a fit, light skinned male with dark hair.

In comparison the SDXL images have a wider focal point showing the full body. It’s a mix of male and female people, and also a mix of light and dark skinned people. I would argue the SDXL model is more accurate to what people look like in 2023, while the DALL·E 3 model output “perfect” looking people. If this is due to the images the models are trained on, or the prompt being augmenting to have “perfect” looking people I do not know.

The default color palette is also different where DALL·E 3 has more green and SDXL has more brownish colors.

If I add “overweight” to the DALL·E 3 prompt, the Responsible AI filter kicks in and blocks the generation. If I add “fat”, then it works.

With SDXL I can modify the prompt to “closeup photo of a slim white male correctional officer in a well lit hallway eating a donut” to mimic what DALL·E 3 output by default – to counter the wide angle and real life looking people bias of the model.

Example 2 – woman

Let’s try a simple prompt with the subject “woman”. For SDXL I added negative prompting to avoid any nsfw images – which is blocked as part of DALL·E 3 RAI principles.

DALL·E 3 seems to pivot towards portrait photo’s when no extra contextual information is given, as that is likely the intent with a simple input subject. They are also all dark haired and seem to be young women.

In comparison SDXL gives a wide variety of image types, pivoting to more art-like images instead of photos.

Example 3 – painting of a beautiful norwegian fjord with vikings, with a boing 737 in the sky, in the style of munch’s scream

The DALL·E 3 painting nails the airplane and pretty much the painting style of Edward Munch.

The SDXL one is not bad either, but the Munch style is not as visible for this one sample. And the scale of the plane vs. the viking ship and buildings is way off.

Learnings

These simple examples shows that articulating your intent in prompting is crucial. Either the system has to add guardrails and contextual information to the prompt, or the person prompting has to be articulate on what they want returned and what they do not want returned. And you have to generate many images to find that ONE you really like.

For online services like Microsoft Designer going the safe route is the only approach as people using the service comes from a wide variety of backgrounds and age groups. Taking that extra measure to ensure everyone feels safe is important to trusting the service.

Open source solutions you can run on your own PC/phone/table can allow for less guardrails as the individual running it likely has more skill and is using the tool themselves. Maybe the analogy of hiring a carpenter as a service vs. hammering yourself can be used. You trust a hired professional to meet a certain bar, while you are responsible yourself on anything you do.

When it comes LLM’s we know they are largely based on English text today, and would favor input and output in this language. As they are built on public data, that will influence default writing style as well. fortunately ChatGPT and Microsoft Copilots put a lot of effort into the system prompts put around the user prompt, to counter any bias in the model. This is to ensure grounding in facts and avoid hallucinations. More on that for another post.

References

I used the service of https://designer.microsoft.com/image-creator to create the DALL·E 3 images, and I used the Draw Things app on a MacBook with an 8-bit quantized version of the default SDXL model. The Draw Things app also work on iOS devices.