A PM can build a working flow. A designer can work directly in code. An engineer can explore several approaches in the time it once took to implement one.

I’ve been living this change. It’s a large part of why I started Super IC: expertise can travel further when AI helps you do work that previously sat outside your role.

But what happens when these people need to build something together?

As I wrote in Individual Speed Is Not Team Speed, the gains don’t automatically add up. A feature generated in an afternoon can still spend days waiting for review. A working prototype can conceal product decisions nobody has made. More output also means more things for someone to inspect, question and take responsibility for.

This is where end-to-end AI-driven development gets interesting. The team has to change how it works.

Product intent, design decisions and technical constraints need to be available to everyone and their agents. Work needs to be small enough to review and revise. Ownership needs to remain clear even as people contribute across disciplines. And we need to protect the human judgement that all this faster generation depends on.

My next free lightning lesson, Super IC Teams: What End-to-End AI Development Really Takes, brings these threads together. We’ll examine how PMs, designers and engineers can take a feature from intent to release, and the agreements that make that collaboration work.

This is the question I keep returning to in my work and in this newsletter: how do we turn expanded individual capability into a team that builds better products?

Join me on 11 November, 3–4 PM PST. Register on Maven →

I have a growing archive of recorded courses and lightning lessons. Inside those long recordings are shorter explanations that could be useful on their own. Finding them means deciding where an idea begins, where it ends and whether someone can understand it without watching everything that came before. A good passage in a six-hour course is not automatically a good two-minute clip.

This was one of the workflows I demonstrated in a recent Maven lightning lesson on Jev. I supplied timestamped transcript text, asked it to select an opening and a compatible closing, then assess the resulting excerpt. It proposed passages for me to review. The video still needs to be checked and cut, but part of the editorial judgement can now sit inside a repeatable workflow.

Jev, from TypeSafe, is built for these kinds of bounded judgements. You supply evidence and specific questions, and it returns structured answers your software can use. It has three question types: Choice selects from options you define; Score places the evidence on a rubric; Noul returns a probability that a statement is true. General-purpose models can also classify and return structured output. Jev focuses specifically on this decision layer.

I think models like Jev are worth exploring wherever we make similar decisions repeatedly. They give us another way to build around the expertise we already have.

You can watch my lightning lesson on Jev on Maven. Alongside the transcript example, I demonstrate support-ticket triage and an AI task router, and explain how to define questions, interpret the answers and evaluate whether the workflow actually works.

During one of my courses, with Granola transcribing the session, I asked it what we had covered so far. The class was still going on. It pulled together the topics we had discussed, including the demonstration I had just given. The notes were already useful before the session had ended.

A lot of our thinking happens in conversations. We explain why an idea won’t work, negotiate a constraint or help someone work through a problem. Granola makes that context available to ask questions of and use in the work that follows. I’ve been exploring several ways to do this in my courses and workshops.

While a meeting is going on, you can query what has been said so far. In an interview, ask what follow-up would help you understand a candidate’s account of a project. In a customer conversation, ask which concern you haven’t followed up on. Before closing a planning meeting, ask which questions remain unanswered. Or simply ask what you missed when you lost the thread. The conversation itself supplies the context for a useful next question.

Afterwards, those notes can become a follow-up email, a project brief or preparation for the next discussion. You can ask what was agreed, what remains open and who committed to doing something. The explanation behind a decision is available alongside the decision, which is useful when you need to carry it into another piece of work.

Across meetings, you can look for patterns that no individual summary would reveal. In that course, I also asked Granola what advice I most commonly give founders in one-on-one conversations. It looked across about twenty calls and returned recurring themes: narrow your focus; validate before building. It pointed me to the conversations behind them. I hadn’t written a document collecting these ideas. I had said them repeatedly to people facing different problems. Customer interviews, project discussions and recurring one-on-ones offer similar material to work with.

There doesn’t have to be another person in the conversation. Granola can capture a solo thinking session too. Speak through a problem, explain what you’ve tried and why you’re stuck, then work with the note. I also dictate emails, prompts and building instructions using speech-to-text tools. Speaking lets me give the AI more of the thinking behind a request without first turning it into a tidy written prompt.

Granola’s Recipes let you save useful prompts and reuse them. Its MCP connector lets compatible AI tools draw on your meeting notes, carrying that context into work elsewhere.

I’ll explore these uses in The Voice-First AI Stack for People Who Live in Meetings, a free Maven lightning lesson on 27 October, part of a campaign with Maven and Granola. We’ll work through how spoken input, meeting notes and connected agents can help us use more of the thinking we’re already doing.

I know software engineers who love writing code. They enjoy solving problems, of course. But they also enjoy the act of writing. Choosing how to represent something. Finding a simpler way to express an idea. Spending an afternoon making a messy piece of code clearer. There is pleasure in the work itself, including parts that someone watching from the outside might consider tedious.

When we tell these engineers that AI will free them to focus on the interesting work, we may be talking past them. They were already doing something they found interesting. They had also managed to find people willing to pay them to do it. That combination is easy to take for granted until it begins to come apart.

The same is true across film, music and other creative fields. A screenwriter may discover the story while rewriting a scene. An actor may find the character in rehearsal with another performer. A visual effects artist may love the painstaking work of making light and movement convincing. In his essay on AI and art, Ted Chiang argues that the small decisions made during execution matter as much as the large decisions about what to create. That resonates with me. Sometimes we only discover what we want to say through the act of making it.

I love building with AI. It has allowed me to attempt things I would previously have struggled to find the time or resources to build. I understand the excitement of watching an idea take shape in hours. But I am increasingly aware that what I am happy to delegate may be the very thing someone else loves doing. We can enter the same profession and want quite different things from our working day.

AI may separate the work someone loves from the livelihood that lets them spend their life doing it.

That possibility has stayed with me while reading the recent debate about AI and mathematics. On 11 September, Terence Tao published a declaration initially signed by 25 Fields Medallists. It argues that producing mathematical results can become disconnected from the understanding and human development that give those results their purpose. A problem is also something through which students learn, mathematicians develop ideas, and a community comes to understand more than it did before.

Timothy Gowers, in his explanation of why he did not sign, adds a distinction I find particularly useful. Mathematicians differ in what motivates them. Some put conceptual understanding first. Others are drawn to solving problems. There is room for both. We should be careful about telling someone what they must really have valued in the work they chose to do.

Imagine a mathematician who has spent decades thinking about a problem. Those years contain failed approaches, conversations, small discoveries and occasional moments when something finally makes sense. We readily recognize this as a creative life when we are talking about a novelist or a musician. Mathematics belongs in that conversation too. Now imagine an AI solves the problem overnight. Assume the solution is correct, elegant and understandable. The mathematician might celebrate the discovery and still feel a profound loss. Nobody is entitled to keep a problem unsolved (another human could have got there first). But if this happens across a field, it raises a larger question: will people still be supported in spending years doing this kind of work?

For the fortunate person who loves their profession, earning a living has made sustained attention possible. The programmer gets to spend the working week writing software. The musician gets to practice, compose, rehearse and perform. There are deadlines and frustrations and plenty of days that are no fun at all. Still, the activity they care about occupies a substantial part of their life. They do not have to find room for all of it after doing something else to pay the bills.

These livelihoods are often sustained by ordinary assignments: composing music for an advertisement, revising a screenplay, performing a supporting role or working on a film’s effects. Such jobs pay for years spent practicing a craft, alongside people who can help you improve. If AI reduces those commissions or turns them into reviewing generated material, both the income and the opportunities to practice can change.

This is why I find the reassurance that people can always continue as a hobby incomplete. Of course they can. A hobby can be deeply serious and satisfying. But telling a professional musician to make music after work quietly inserts another job into their day. That job needs time and energy. The freedom to keep playing remains, while the hours available to play may shrink dramatically. A livelihood may also have supplied collaborators, equipment and difficult assignments that helped the musician improve. Continuing alone in the evenings is a different arrangement.

Those years of paid practice also help develop the judgment we now expect people to bring to AI output. An experienced engineer can spot a fragile design or recognize that a plausible solution answers the wrong question because they have spent years building, debugging and living with the consequences of their decisions. A film editor learns to recognize why a scene drags by cutting scenes, watching them and trying again. Repetition, mistakes and feedback teach them what to look for. A task that feels routine to them may still be essential practice for someone starting out. If fewer people get to do that work, where will the next generation acquire the experience to assess what the machines produce and make it useful? We risk depending on expertise while making it harder for people to develop it.

Even keeping the job may not preserve what someone loved about it. An engineer could remain well paid, produce more software and spend most of the day directing agents. Some will enjoy that immensely. Others will miss writing code. In my essay on decision fatigue, I wrote about the strain of this new working day: long periods of intense effort interrupted by a stream of decisions. Here I am concerned with something that could remain even if the agents become completely dependable. Supervising excellent work can still feel different from doing the work yourself.

This is where I see the misalignment. An employer wants useful software delivered quickly. A customer wants a reliable product at a lower price. The engineer may want both of those things and also want to spend the day writing code. AI can meet the first two goals while making less room for the third. The efficiency the employer gains can come from taking away the part of the job the engineer most wanted to do. The people involved simply value different parts of the same activity, and the person buying the work usually has more say in how it gets done.

I don’t have a neat resolution to this. Making useful things cheaper and more accessible matters. So does opening creation to people who could not previously participate. But I would like the people doing the work to have a voice in deciding what they hand over. I would like employers to consider what makes a working day worth returning to, alongside how much it produces. And I worry about a future in which spending your days on a practice you love increasingly requires money earned somewhere else.

I keep returning to the engineer who enjoyed writing code. They had found something they wanted to get better at, and a way to support themselves while doing it. That is a lovely thing to have found. As we celebrate everything AI makes possible, I want us to take that person’s loss seriously too. The work we have made unnecessary may have been the work they wanted to spend their life doing.

I often describe AI as a very capable intern. It is knowledgeable, resourceful and willing to do a great deal of work. But it has just walked in. It doesn’t know how your team makes decisions, which source you trust or what you consider a useful recommendation. Giving it the role of “expert product manager” does not give it your experience of this particular product, company or way of working.

Much of that experience appears in the corrections we make. “This was a proposal, not a decision.” “That number needs a different denominator.” “There isn’t enough evidence to make this recommendation.” We explain, the agent tries again and eventually the output becomes useful. Then we start another session and repeat parts of the explanation. Somewhere inside these conversations is a working method that we have not yet made explicit.

An agent skill is a way to preserve that method. As Anthropic explains in its original Agent Skills guide, it is a folder with a file called SKILL.md, containing instructions and a description of when to use them. It can include examples, templates and scripts. A compatible agent loads the relevant instructions when needed. The format is simple. The harder work is deciding what we need to teach it. That is the focus of my Agents and Agent Skills Workshop (next cohort on 8th October).

A useful starting point is a task you have already worked through with an agent. Look at the steps that helped and the corrections that changed the output. Another is material you already use: a checklist, a runbook or examples of good work. You can also adapt a skill someone else has built, provided you examine its assumptions. Asking an agent to create a skill from a task name alone gives it very little of the knowledge you are trying to preserve.

Consider a meeting follow-up. The agent already understands what a summary is. What it may need to learn is that volunteering to investigate a question is different from committing to deliver a feature. Or that an owner should remain unspecified when nobody agreed to take responsibility. These details belong in the method, along with what to do when the information is missing. In my workshops, I call these “gotchas”: mistakes worth documenting so that we don’t have to keep discovering them. A vague instruction to be accurate is much less useful than explaining the error we want to avoid.

But writing the instructions is only part of the work. In an earlier workshop, we built a launch-copywriting skill that worked from project material and produced drafts for email, LinkedIn and X. We compared the output with and without the skill. The comparison showed where the skill helped, where the agent was already doing well and the extra effort involved. At one point, the agent gave its own work a perfect score. That was a useful reminder to inspect the output ourselves.

A skill should earn its place in the workflow. Run it on a few representative examples, including something different from the material used to build it. Does it prevent the mistakes you care about? Does it reduce the correction required? When a recurring failure appears, revise the instructions and check again. A correction made in conversation does not necessarily become a correction in the skill file.

For a team, this turns part of its experience into something colleagues can inspect, challenge and improve. The method still needs an owner, and it will change as the work changes. But the knowledge is now available beyond the person who originally developed it. I think this is one of the more useful ways to amplify expertise: understand the judgement inside your work, explain it clearly and test whether someone - or an agent - can use it.

In the Agents and Agent Skills Workshop (next cohort on 8th October), we’ll build, install and evaluate a skill around a real workflow. You can also watch my free lightning lesson on agents and agent skills for a walkthrough of how to turn a working method into a skill an agent can use.

I have been thinking about a strange mismatch in the way AI is changing work. Individuals are becoming much faster. A product manager can turn rough thinking into a clear first draft. An engineer can understand an unfamiliar codebase and begin building in hours instead of days. A designer can explore many more possibilities before settling on one. But teams are not always seeing gains of the same magnitude. Giving every person an AI tool does not, by itself, make the group work better together.

The usual response is to standardize the tools. Choose a model, pick an agent and teach everyone how to use it. This is useful, but it cannot be the foundation of team efficiency because the tools change too quickly. The model that feels indispensable today may be replaced next month. The teams making the most progress are often the ones that understand the strengths of different models and can move between them without much friction. The durable layer is not the tool. It is the team’s way of working.

A way of working is the set of agreements that allows work to move from one person to another. What do we write down before we begin? Who needs to review it? Which decisions must be recorded? When is a piece of work ready for someone else to depend on? Who owns the final output? These questions may sound procedural, but they form the shared infrastructure of a team. This can also include shared AI skills: reusable instructions and procedures that encode how the team investigates a problem, writes a design or checks its work. AI makes this infrastructure more important because it allows each person to generate a large amount of plausible work very quickly.

A simple example is the agreement that we do not begin coding without a written engineering design. The document itself can be created with the help of an AI agent, but it must still be discussed, challenged and approved by the team. Product needs its own version of this artifact: perhaps a short product document or a shared note containing what we know about the problem, the user and the important decisions already made. The names of these documents do not matter much. What matters is that the thinking becomes visible before the volume of generated work begins to grow.

This only works when each person takes responsibility for their agent’s output. If I pass a product document, a design or a piece of code to a colleague, they should be able to assume that I have read it, tested it and stand behind it. A final code review or approval step cannot compensate for careless work upstream. If I send unvalidated output to the next person, my apparent efficiency becomes their problem. They have to find the gaps, reconstruct the reasoning and make the decisions I skipped. Trust in AI-assisted work is not attached to the tool. It is built through the way the work was produced.

Once that trust exists, the traditional sequence of product development can begin to change. Product can establish the intent and the important decisions in a short document. Engineering can build the complete feature flow using existing design components. Design can then refine new components, layouts and visual details while the feature is already taking shape. The work no longer needs to wait at every boundary. This is not an argument for lowering the quality bar. It is a change in the order of operations, made possible because the people involved trust the artifacts and decisions moving between them.

Some work will still be thrown away. A component may need to be rebuilt. A product decision may change after the feature becomes tangible. Teams need enough psychological safety to accept this without treating every discarded draft as a failure. The cost stays manageable when projects are divided into features that can be completed in a day or two. Small units allow the team to learn, adjust and still show meaningful progress each week. Individual AI efficiency comes from producing work faster. Team AI efficiency comes from establishing a shared way of working that turns that speed into work other people can trust.

I have long been a fan of Paul Graham’s essay, “Maker’s Schedule, Manager’s Schedule”. Graham describes two different clocks. A maker needs long, uninterrupted stretches to write, design or code. A manager divides the day into smaller units and moves from one decision to another. Cal Newport’s work on deep work gave me another way to understand the maker’s side of this divide: difficult work requires sustained attention without distraction. For years, this distinction felt complete to me. Then I started building with AI.

Working with AI feels like occupying both schedules at once. I might spend many intense hours building a product, which looks and feels like deep work. But I am no longer following one problem down a long tunnel. I am managing agents. Every few minutes, one of them returns with code, a design, a document or a question. I have to read, judge, correct and redirect. Is this the right approach? Has it understood the user problem? What has it missed? The work is deep, but the attention is not singular. It has the duration and cognitive demand of a maker’s day, with the constant switching and decision-making of a manager’s day.

At first, this feels like extraordinary productivity. Work that once took weeks now takes hours. But the decisions inside that work have not disappeared. Why should we build this? What should the experience feel like? Which compromise is acceptable? What happens when it fails? A senior product leader might once have made one or two consequential decisions over the course of a week. While building with AI, similar decisions can arrive every few minutes. The machine has shortened the time between a question and a possible answer. It has not reduced the care required to choose the answer. This is where decision fatigue begins: not with the number of tasks, but with the unbroken stream of judgment they demand.

There is an easy trap here, especially for people who are still learning their craft. It is tempting to believe that the agent is responsible for what it produces. It is not. If my agent writes code, drafts a product requirement, proposes a design or recommends a technical direction, I remain responsible for every part of that output. The agent can produce options at great speed, but I still have to decide whether those options are thoughtful, safe and right for the product. AI has not reduced the need for judgment. It has dramatically increased the rate at which judgment is demanded.

The deeper problem is that these systems have not yet earned the kind of trust we place in a highly capable colleague. Over time, you learn which people can take a problem, make good decisions and return with work that does not require inspection at every step. We are not there with AI agents. Their output can be excellent, but it is not consistently dependable enough to accept without review. So I remain responsible not only for the instruction, but for the reasoning and the final result. Perhaps better models and better agent systems will eventually reduce this burden. For now, building with AI still involves micromanagement at extraordinary speed.

I used to run five or six agent sessions at the same time. I now stop at two. Switching between six windows every few minutes did not merely make me tired. It made my decisions worse. A weak decision creates poor output. Poor output creates rework. Rework requires more instructions, more review and more decisions. The natural response is to work longer, which further reduces the quality of judgment. This is the feedback loop at the heart of decision fatigue. It is not simply exhaustion from long hours. It is the depletion caused by making consequential choices continuously, without enough time for reflection or recovery. Sustained for long enough, it becomes burnout.

This is not only a problem for individuals to solve with better habits. Organizations will see the extraordinary increase in visible output and may begin planning around it. More projects. More parallel work. Shorter timelines. But machine output and human judgment do not scale at the same rate. If every artifact still needs a person to review it and take responsibility for it, then judgment becomes the scarce resource. Decision fatigue is therefore not a personal failure. It is an operating risk. Teams that ignore this will get more work in the short term, followed by weaker decisions, growing rework and exhausted people. We will need organizational limits on concurrent work, clearer ownership of AI output and real time for recovery. Machines can produce at machine speed. People cannot be asked to decide at that speed indefinitely.

In 1989, my dad rented a Nintendo console to distract me from a bout of chickenpox. I was seven. My mother and I played Mario and Contra, and I spent an unreasonable amount of time being defeated by the first Goomba. There was a whole world beyond that creature. I just had to figure out how to get there.

I returned to that memory when I wrote a personal AI manifesto in April 2025. Generative AI had brought back something familiar: the pleasure of being a beginner, the frustration of getting stuck, and the conviction that working through the frustration would be worth it. I gave myself a few rules. Suspend the ego. Build things. Persist beyond the delightful first demo. Allow myself to learn faster than I thought possible.

Since then, through my own experiments, the courses I teach on Maven, and my work with teams and executives, I’ve been exploring where those rules lead. The tools keep changing. The question that interests me has become more expansive: what happens when people can bring much more of their expertise and imagination into the things they build?

That is the territory I want to explore with Super IC.

IC stands for individual contributor. If you manage people, stay with me. I wrote in 2023 about how becoming a manager doesn’t absolve you of the responsibility to practise your craft. The maker-versus-manager tussle has occupied a fair bit of my working life. As you grow in your career, your calendar fills up and the distance between you and the thing being built can grow with it. You get very good at talking about the work. Finding an uninterrupted afternoon to do some of it becomes a minor logistical miracle.

AI has given me a way to close some of that distance. An idea can become a working prototype while I am still figuring out what I mean. I can explore a question, build something to test it, discover what I got wrong, and try again. There is enormous joy in that loop. Anyone who has spent years moving between documents, meetings and dependencies will understand why getting back into it feels liberating.

The expertise you bring to this matters. A product manager’s understanding of a customer, a designer’s eye for an interaction, an engineer’s instinct for where a system will break: these have taken years to develop. AI gives us new ways to apply them, including in parts of the work we previously depended entirely on someone else to attempt. Knowing what good looks like becomes more consequential when you can produce ten plausible versions of something before lunch.

Of course, one of those versions may be confidently, elaborately wrong. A functioning demo can conceal a remarkable number of problems. You still have to inspect the work, test your assumptions, and understand enough to know when you need help. That requires time and the willingness to feel incompetent again. A senior title doesn’t come with immunity from the learning curve. (I have checked.)

There is also a question of what happens to all this learning. In 2021, I described a playbook as something you could repeat, teach to someone else, and examine afterwards to see whether it had been used properly. I keep coming back to that idea as I work with AI agents. The instructions, examples and checks that help an agent do useful work are also a way of making our own expertise explicit. How do I make this decision? What do I always check? Which exceptions have I learnt to watch for?

Getting those things out of your head takes effort. Once you do, you can test them, improve them, and share them with your team. Some of the most valuable work in becoming a Super IC may be explaining something you have been doing almost unconsciously for years.

This is where the conversation has to expand beyond the individual.

A team can have several people getting dramatically faster at their own tasks and still take just as long to deliver anything useful. A prototype built in an afternoon can sit in a review queue for two weeks. More drafts can mean more work for the person who has to read them. The gains have to survive contact with the rest of the organization.

We need to look at the work between people: the handoffs, the missing context, the decisions nobody is quite sure they are allowed to make. As the boundaries between product, design and engineering become easier to cross, we will also have to get better at crossing them respectfully. I can bring a working interface to a designer and have a much richer conversation. I still need their expertise. The ability to attempt more of the work should make collaboration more interesting, while keeping responsibility for its quality clear.

For companies, this asks something of leadership too. Buying access to AI is a starting point. People need time to learn, useful problems to work on, and colleagues with whom they can compare notes. Leaders need to participate in that learning. It is difficult to build a culture of experimentation if everyone feels obliged to show up with a polished success story.

Then comes a choice I find particularly interesting: what do we do with the capacity we recover? Which neglected customer problem can we finally address? Which experiment was always too expensive to try? What could a small team now take on? Efficiency matters, but I want us to be at least as curious about the possibilities it creates. Otherwise, we risk using a remarkable expansion of capability to make our ambitions smaller.

And some of that recovered capacity belongs outside work. I’ve written about side quests because they have shaped so much of my life. Learning an instrument, reading fiction, following a strange question, spending an unhurried evening with family: these deserve room of their own. I would like becoming better at work to help make that room.

Super IC will be a field journal of this exploration. I’ll share things I’m building, workflows worth trying, experiments that fall apart, and lessons from teaching and working with teams. We’ll get into the details of prototypes, agents and evaluating their work. We’ll also look at how organizations learn, how expertise travels, and what happens to our careers when we can do more than our job descriptions suggest.

I expect to revise my views along the way. That was part of the original manifesto too.

For now, there is a lot of world beyond the first Goomba. I’d like to see more of it.

Welcome to Super IC.

What have you wanted to build, learn or try that has stayed on the “someday” list? Hit reply and tell me.