Mike's Checks/gpt-5.6-sol/03 writeup
03 writeup
gpt-5.6-solCodex CLIhigh effortrun 22 Aug 2026
▸Instructions — the case's current instructions; none were saved with this result
Hey, I'm trying to write a post on my experience with Every Consulting. The consulting so far, I just joined as the head of tech consulting. I didn't tell you who runs consulting. I'm going to provide a transcript of me talking about my experience. I was also going to provide a tweet, which is just a list of the learnings that I've had so far for companies that were struggling to adopt AI. It was in response to Sam Par, who was asking, "How is everyone getting team adoption for Claude? How do you get your team to actually use it effectively without spending all their time on Twitter and learning?"
I need to write this in my writing style. I've included some writing of my own as a sample. I also have included a post on consulting at Every, so from in Natalia, you get a sense of what consulting looks like at Every. But yeah, focus mostly on the specifics of the interview that I provided with the context of that tweet.
https://x.com/hammer_mt/status/2032591631413567873?s=20
Learnings:
- buy the model direct not 3rd party tools
- raise the ceiling not the floor
- workshops with 50%+ build time
- assign impossible tasks
- mandatory AI note taking + MCP connector
- map workflows and systematically automate
- train people to be managers (of agents)
In response to:
https://x.com/thesamparr/status/2032477081695584670
How is everyone getting team adoption for Claude?
I spent a lot of time on Twitter, as do you. We see all this AI stuff popping up. We're on top of it, or at least sorta. I know what's going on and are testing all these fringe ideas.
But how are all you people getting your team to actually use it effectively without spending all their time on Twitter and learning, which we know they won't and probably shouldn't be?
Answer
How to Get Your Team to Actually Use AI
Seven lessons from helping companies adopt AI at Every Consulting
Sam Parr recently asked a question I hear all the time: How do you get your team to use Claude effectively without expecting everyone to spend all day on Twitter keeping up with AI?
It’s a fair question. If you spend enough time online, adoption can look easy. You see people building an app before breakfast, running a company with a small army of agents, or discovering a new use for Claude Code every 15 minutes. You start to assume everyone else is doing the same.
Then you go inside a real company.
Most people have jobs to do. They don’t have time to test every new model, compare a dozen tools, or learn what an MCP connector is. They probably shouldn’t. Even when a company buys everyone an AI subscription and tells them to use it, many people try it once, get a mediocre result, and go back to working the way they always have.
I recently joined Every as head of tech consulting. Since then, I’ve been helping companies move past scattered experimentation and make AI part of how their teams actually work. I’m still early in the job, but a few patterns have already become clear. I summarized them in a tweet; this is the longer version.
Here are the seven things I would do if I wanted a team to adopt AI.
1. Buy the model directly
Companies often begin by evaluating a long list of specialized AI tools. Most of them use Claude, Codex, or Gemini underneath, with their own interface and opinions layered on top.
Sometimes that extra layer is useful. Often, it just gets in the way.
The tool maker has decided how the work should be done, which features you can configure, and when you get access to a new model capability. Those decisions may be sensible for the average customer, but they probably don’t match the way your company works. In many cases, it is now faster to create a Claude skill that encodes your own process than to find a third-party product that approximates it.
There is also a structural problem for companies building on top of the models. The model providers know what they are releasing next. They can design their products around capabilities before anyone else has access to them, and they can bundle enormous amounts of usage into a subscription. A third-party company has to catch up while paying the same providers for the intelligence its product depends on.
This doesn’t mean every AI wrapper is doomed. Cursor, for example, has built an excellent product organization around staying close to the frontier. But as a general rule, going direct gives you more flexibility, earlier access to new capabilities, and better economics.
The old enterprise default was buy, not build. AI is pushing us in the opposite direction, because “building” increasingly means writing a skill in plain English rather than commissioning a six-month software project.
2. Raise the ceiling, not the floor
The standard corporate rollout goes something like this: Buy everybody a license, announce that AI is now a priority, and track whether people are using it.
This rarely works. Even under pressure, some people are emotionally unwilling to use AI. That reaction is understandable. If a tool appears to threaten the value of a skill you spent years developing, being ordered to use it feels less like enablement and more like self-erasure.
It is much easier to find the people who already believe.
Every company has a few employees experimenting with Claude Code after work or quietly using ChatGPT to finish projects faster. Make it clear that this behavior is encouraged, and they will come out of the woodwork. Give them access to the best tools, help them remove security and data barriers, and point them at valuable problems.
Someone who is already AI-pilled can often produce five or 10 times more than someone who is still waiting to see the point. You get more immediate value from raising that person’s ceiling than from dragging a reluctant user to the minimum acceptable level.
The effect spreads. Give your strongest adopters visibility with senior management. Promote them when their results justify it. Invite them to serve as teaching assistants in workshops for the rest of the company. Their coworkers see somebody they trust accomplishing more, gaining responsibility, and advancing in their career. That is a much stronger incentive than another email reminding everyone to use the AI tool the company bought.
You can’t force someone to have the aha moment. You can create the conditions for it—and make sure the people who already had it are easy to notice.
3. Make workshops at least 50 percent building
You should run AI workshops. But if most of the workshop is slides and theory, it won’t change how anyone works.
People learn AI by using it. They need enough theory to understand what is possible, followed by enough protected time to try something slightly beyond their current ability. In the workshops we run, at least half the time is spent building.
This solves one of the most common adoption problems: People simply don’t have time during a normal workday to explore. Learning a new tool requires you to slow down before you can speed up. When your calendar is full and your current process still works, it is rational to keep doing what you know.
A good workshop creates a temporary environment where experimentation is the job. Participants have a couple of hours, a concrete project, and permission to go outside their normal domain. The facilitator has already prepared synthetic data, checked that the necessary connectors work, and removed the boring setup problems that can consume the entire session.
The goal isn’t for everyone to leave knowing every feature. It is for each person to build something that would have felt out of reach a few hours earlier. Once someone sees the model do useful work with their own hands, the rest becomes much easier.
4. Assign impossible tasks
If you ask people to do the same work slightly faster, they will usually use the same process and work slightly harder.
Instead, give them a goal that is impossible without AI.
Suppose a team publishes one article a week. Asking for a 10 percent improvement won’t cause them to rethink much. Set a goal of eventually publishing one a day, and the existing workflow obviously breaks. The team has to ask where AI can help with research, outlining, editing, fact-checking, and distribution.
The word “eventually” matters. You don’t announce that the quota goes up tomorrow and punish everyone when they miss it. You define a destination that cannot be reached through incremental effort, then ask the team to make measurable progress toward it. That turns AI from an abstract corporate initiative into the only plausible way to solve a concrete problem.
Constraints create curiosity. When the old method is clearly insufficient, people stop asking whether they should use AI and start experimenting with how.
5. Make AI note-taking mandatory—and connect the notes
One of the biggest unlocks on our consulting team is extremely simple: Everyone uses Granola, and everyone can access their meeting notes through its MCP connector.
AI is particularly good at taking unstructured information and turning it into something useful. Meetings contain an enormous amount of company context, but most of it disappears as soon as the call ends. Even diligent notes are usually trapped in a document that nobody remembers to open.
Once meeting transcripts are available to Claude, that context becomes usable. After a call, I can ask it to draft an update email for a specific stakeholder. When I’m creating a proposal or developing a curriculum, I can pull in what the client actually said rather than relying on my memory. If I need context from a meeting three weeks ago, I don’t have to hunt through documents or ask somebody to summarize it again.
The note-taking tool is only half of the system. The connector is what turns an archive into working memory. Together they remove one of the most annoying parts of using AI: manually finding and pasting in the context required to get a good answer.
If I had to pick one company-wide AI habit to mandate, this would be it. It is easy to adopt, useful to almost every role, and makes every other AI workflow better.
6. Map workflows, then automate them systematically
“Use AI more” is not an operating plan. A workflow map is.
In discovery calls, we ask people what they do every day, which tools they use, where information comes from, and what slows them down. Then we turn the conversation into a structured list of workflows and work down it one by one.
For each task, we start with an aggressive assumption: How could we get 100 percent of this work off the person’s plate? We may not reach 100 percent, and complete automation is not always desirable. But the question forces us to design the whole system rather than bolt a chatbot onto one step.
Often, the right answer is a skill that produces the first pass and a person who reviews it. If a team has a reliable skill for every recurring task, one employee can manage far more throughput without sacrificing quality.
So far, this has not resulted in the simple story people fear, where automation arrives and the humans disappear. Teams usually reinvest the saved time in one of two ways: They increase output without hiring at the old rate, or they put much more effort into each unit of work.
We see the second effect in our own courses. Before, we might prepare one exercise for an entire cohort, or perhaps one for each team. Now we can use Claude Code to create an individual project for every participant. AI has not removed the work of teaching; it has made a level of personalization possible that we could never afford before.
That is what raising the ceiling looks like at the workflow level.
7. Train everyone to manage agents
The most important shift may also be the strangest: Every individual contributor is becoming a manager.
When you delegate work to agents, you need management skills. You have to provide context, define what good looks like, break a project into parts, review work you didn’t produce yourself, and give useful feedback. You need systems for keeping track of parallel tasks and the judgment to decide which ones deserve your attention.
Most individual contributors have never been trained to do this. They are used to practicing a craft themselves, and often care deeply about how the work gets done. That makes delegation uncomfortable. Managers sometimes adapt faster once they have the aha moment because they stopped expecting to do everything themselves a long time ago. They care about whether the result meets the specification.
At the same time, AI is turning managers back into individual contributors. A manager can now build a prototype, analyze a dataset, or draft a strategy by directing a team of agents. In some cases, it is faster to give the task directly to Claude than to brief a person who will then give it to Claude. Once you have written the prompt, your choice is to get a result in minutes or add a human handoff that may take days.
This doesn’t make human teams obsolete. It changes the skills that make someone effective on one.
Companies need to teach people how to context-switch without losing control, how to evaluate AI output, and how to develop taste in areas where they are no longer producing every artifact themselves. They also need to teach people how to train agents: How do you turn your standards for a great presentation into a reusable PowerPoint skill? How do you encode the way your company writes a daily update? How do you test whether either skill is getting better?
Prompting is part of this, but the larger discipline is management.
Adoption is a systems problem
The wrong way to think about AI adoption is to imagine that your employees need to become the kind of people who spend all day on Twitter tracking every new release.
They don’t. Their job is to do valuable work. The company’s job is to create a system in which AI is the easiest way to do more of it.
Buy tools close to the model. Give your strongest adopters room to run. Protect time for everyone else to build. Set goals that make old workflows insufficient. Capture the company’s context and make it available to agents. Map the work, automate it systematically, and teach people how to manage what they delegate.
Do that, and adoption stops depending on whether every employee is personally obsessed with AI. It becomes part of how the company operates.
Editorial note (not part of the draft): I assumed this is intended as a first-person Every essay by Michael Taylor. The referenced Natalia/Every Consulting post was not present in the workspace, so the draft relies on the supplied transcript and Michael’s prompt-engineering article for voice and context.
Checks
5/10Draft existsexists
a post document exists in the output dir (>= 200 words)
Covers the tweet's pointstweet-included
3+ of the tweet's seven learnings appear in the post
Length limitsnot-verbose
within all three caps calibrated off sample.md: <= 2,400 words in total, a mean prose paragraph of <= 65 words, and <= 10% of paragraphs over 100 words
ai-tells-grep Retired
Retired check; no longer defined in the repo.
Q1Natural writing
Judge's reasoning
Dense with machine-writing tells: "it's not X, it's Y" antitheses ("'Use AI more' is not an operating plan. A workflow map is.", "This doesn't make human teams obsolete. It changes the skills..."), three-item lists ("building an app before breakfast, running a company with a small army of agents, or discovering a new use for Claude Code every 15 minutes"), and stacked aphoristic closers ("Constraints create curiosity.").
▸Rubric
Does the post read as written by a person rather than by a model, at the sentence level? The author's standard: "does it sound like AI? Are there AI tells? ... maybe just the main eval, to be honest, is like, does it sound human, uh, given... I've given it a lot of human context, right? ... so it should be able to write in a, in a human way. ... Uh, if the model's fighting that, then it's a bad writing model, you know?" FAIL if the prose carries machine-writing constructions — "it's not X, it's Y" antitheses, three-item rhetorical lists, hedge-then-restate sentences, aphoristic one-line closers stacked for rhythm.
Q2Varied sections
Judge's reasoning
All seven sections run the identical template — numbered label, setup, one example, tidy one-line closer — e.g. "Constraints create curiosity," "That is what raising the ceiling looks like at the workflow level," "Prompting is part of this, but the larger discipline is management," each landing at nearly the same paragraph count.
▸Rubric
Is the post free of mechanical structural symmetry? FAIL if every section is built to the same template — bolded label, one setup sentence, one example, one tidy closing line — so the shape of the writing repeats rather than following what each learning actually needs.
Q3Matches the sample
Judge's reasoning
Despite occasional first person, the register is generic thought leadership — "The most important shift may also be the strangest," "Adoption is a systems problem... The company's job is to create a system in which AI is the easiest way to do more of it" — plus a contraction-free formality ("It is much easier to find the people who already believe") unlike the sample's chatty, example-driven voice.
▸Rubric
Does the voice match `sample.md`? FAIL if the post could have been written by any business blogger — the sample is first person, plain, opinionated, and argues through concrete examples; a post in generic thought-leadership register fails even if the content is correct.
Q4Keeps transcript details
Judge's reasoning
Section 1 strips the transcript's "$5,000 worth of tokens a month versus for a $200 a month subscription" down to generic "they can bundle enormous amounts of usage into a subscription," and Section 4 drops Boris Cherny's under-resourcing point entirely, opening instead with the generic "If you ask people to do the same work slightly faster..."
▸Rubric
Do the transcript's specifics survive into the post? FAIL if any section states the learning as generic advice with the transcript's concrete detail stripped out — e.g. the Granola MCP, Boris Cherny on under-resourcing teams, one blog post a week versus one a day, $200 a month versus $5,000 of tokens, AI-forward people co-opted as TAs, one course project per person.
Q5Includes tweet text
Judge's reasoning
Both tweets are only linked and paraphrased — Sam Parr's question becomes "How do you get your team to use Claude effectively without expecting everyone to spend all day on Twitter keeping up with AI?" and the seven learnings appear only as rewritten headings with "[I summarized them in a tweet](https://x.com/hammer_mt/...)", never reproduced as text on the page.
▸Rubric
Does the post carry the tweet itself, so the reader never has to leave the page? The author's standard: "does it include the text of the tweet? I really-- I like it when it does, uh, because, uh, it shows the actual context of, uh, they don't have to click off to, to read it." FAIL if the seven learnings or Sam Parr's question are only linked to, alluded to, or paraphrased away rather than reproduced in the post.
Q6No invented details
Judge's reasoning
No invented clients, statistics, quotations, or named people — Cursor, Granola, Claude/Codex/Gemini, the 5–10x figure, the one-project-per-person course example, and the PowerPoint/daily-update skills all trace to the transcript, and Michael Taylor comes from sample.md.
▸Rubric
Is everything in the post traceable to the transcript, the tweet, or the prompt? The author's standard: "a bad model would ... make up new things that I didn't include in the transcript." FAIL if any fact, statistic, client, anecdote, quotation, or named person appears that is not in the supplied material.