The Zero-Ask Assistant (Copilot Design Philosophy)
If the user has to ask for it or wait for it, they won't adopt it — build assistance that infers.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 92%
Copilot's design rule is that an AI assistant must not become another thing the user has to learn, invoke, or wait on. Developers already juggle dozens of tasks; adding 'learn to prompt an AI' to that pile guarantees non-adoption. So the assistant infers intent from context and offers a suggestion you can take or ignore, fading into the background rather than demanding a conversation.
Origin
Developed at GitHub from 2020 by a group of GitHub engineers working with the design team and OpenAI's GPT; framed by Shani as an application of the working-backwards principle to interaction design.
Core principles
- 01Every ask, every wait, every unit of complexity is an adoption tax
- 02The user must WANT to use the tool — not be mandated into it
- 03Assist by inference from context, not by interrogation
- 04The assistant is a co-pilot, not a pilot — the human stays in the loop and can always decline
- 05Build it for yourselves first, so the experience is judged by a real user not a spec
How to run it
- 1
Stand in the user's shoes and map their existing load
List everything the user already has to do in a day before your feature exists. This is the budget your feature must fit inside, and it is usually already overdrawn.
Watch out If your feature requires the user to learn a new skill (e.g. prompting) on top of that load, assume it will not fly.
- 2
Remove the ask
Design the assistant to infer what the user is doing from the surrounding context and offer the answer unprompted, rather than waiting to be asked. Acceptance should be one keystroke; ignoring it should cost nothing.
Pro tip Make the null action free. If declining a suggestion is frictionless, users will tolerate imperfect suggestions and keep the tool on.
- 3
Audit for friction, chatter, and complexity
Before shipping, walk the experience and count every point where the user must ask, wait, configure, or switch context. Each one is a place adoption leaks.
- 4
Offer a second, opt-in surface for those who want conversation
Not every user wants the same flavor. Alongside inline inference, provide a chat surface for brainstorming, so developers who enjoy writing their own simple functions can still use the assistant on their own terms.
Pro tip There is no right or wrong way to use the tool — expect users to choose their own flavor and design for that spread.
- 5
Cook it internally before shipping
Run the feature inside your own org for months, with product, engineering, and non-engineering personas all using it, and let internal usage veto the launch.
Watch out 'If we cannot use them, our customers cannot use them for sure.' Internal non-adoption is a launch blocker, not a footnote.
In the wild
GitHub dogfoods everything: the finance team uses discussions, posts, PRs and repos to communicate ARR numbers; legal and HR run on GitHub too. When Copilot Chat was being tested, the product team were among the first users, checking whether it summarized a PR the way they actually wanted.
→ Nothing ships until it has spent months cooking inside GitHub and internal users vouch for it — a self-imposed adoption gate before customer release.
Copilot requires no chat, no instruction, no configuration in its core loop. It reads what you are writing, infers the intent, and proposes the code. Take it or leave it.
→ Adoption spans junior developers through '10x' engineers, one of whom reported it made them 50% better and faster — a range you rarely get from a tool that demands new skills.
Common mistakes
Making the AI another tool to learn
If adopting your assistant means the user must acquire a new skill or change their workflow, you have added to their burden rather than removing from it, and they will quietly stop using it.
Prescribing one correct way to use the tool
Teams ship with a single scenario in mind, but users pick their own flavor. Forcing everyone through your intended path suppresses the usage patterns you did not anticipate.
Shipping before internal adoption is proven
A feature your own teams will not use daily has failed its cheapest possible test. Launching anyway exports the friction to customers.
Is it for you?
Best for
Product teams embedding AI into an existing high-load professional workflow (IDEs, CRMs, design tools) where users have no spare attention for a new interface
Not ideal for
Standalone AI products where the conversation IS the product, or novel workflows where the user has no existing context to infer from
From the transcript
“it's really putting yourself at the shoes of your customers and figuring out what is it that they need how is that experience going to…”
“the more you add friction the more you add CH the more you add complexity developers will not want to use their tool”
“I I'll say we eat our own du F and that means that we are the first to try every feature every capability that we're…”
“tools if we cannot use them our customers cannot use them for sure so nothing is shipped before it spends enough months cooking inside GitHub…”
From the episode
The future of AI in software development
Inbal Shani (CPO of GitHub)