Working Notes

Category: AI

  • The friction is part of the work

    Learning is fundamentally full of friction. But what happens when instead of working through the friction, you decide to just let AI handle it? Maybe the work got done, but did you learn anything? Are you more in touch with your craft today than you were yesterday?

    These are some of the questions that haunt me these days. I use AI every day and I use it a lot. I regularly describe the ultimate outcome I want and then leave it alone for an hour or so and come back to a perfectly working solution. Sometimes the solution has even handled edge cases and scenarios I didn’t think of but encounter as I put the solution through its paces. It’s impressive and incredible.

    And I don’t think there’s anything inherently wrong with working that way. Sometimes I just need something done. Sometimes the implementation isn’t where I want to spend my time or energy. And sometimes letting AI handle the implementation means I can spend more time thinking about the bigger problem.

    But what happens when we start working this way by default? When the first instinct, upon encountering something difficult, is to hand it off rather than work through it ourselves?

    Some friction is the work

    That instinct is easy to follow with code, design, writing, and just about anything else. Writing is where I noticed it first.

    For a little while, my writing was being mistaken for AI. It frustrated me so much that I started writing my drafts and then running them through AI with the instruction to rewrite them at a grade 9 or 10 reading level, and then I’d share that. My natural style of writing was being seen as too dense or complicated.

    I found the whole experience frustrating, and not just because people were mistaking my writing for something AI had produced. But also because by having AI rewrite it in “plainer” language, so much of the nuance and contextual information was being left out. I was forced to make my writing only about the point at hand, rather than also giving the reader the tools and context to understand the lay of the land, which I felt was pretty vital in the larger picture.

    It made me wonder whether our relationship with difficulty is changing. Whether we’ve become so accustomed to things being made easier for us that we’re starting to treat the effort required to understand something as a problem with the work itself.

    Sometimes things are unnecessarily complicated. Sometimes writing is dense because the writer hasn’t done the work to make their ideas clear. I have certainly been guilty of that at times. Sometimes software is difficult to use because it’s badly designed. Making things accessible is important, and complexity for its own sake isn’t a virtue.

    But just because something is hard to understand or use initially doesn’t mean it’s badly made or not worth engaging with. Not everything can be simplified to a level that everyone can understand on their first attempt. Some things require us to learn new concepts, develop new mental models, or sit with an idea long enough for it to make sense.

    So are we getting worse at doing that?

    We’ve spent years in tech trying to remove friction. Better developer experiences, better abstractions, better tooling, better documentation, better UX. I’m a huge advocate for all of those things. Much of my own work revolves around making it easier for people to build and do things. That is fundamentally the role of technology in our lives: to make it easier to do the things we want to do, often better and faster too.

    But is every kind of friction a defect? Is every kind of friction worth reducing or eliminating?

    There’s friction that gets in the way of doing meaningful work. The tedious setup, the repetitive tasks, the confusing interfaces, the unnecessary complexity. Removing that friction gives us more time and energy for the things that matter.

    And then there’s the friction that comes from doing the meaningful work itself. The hours spent debugging a problem that forces you to understand a system more deeply. The uncomfortable process of trying to articulate an idea you haven’t quite figured out yet. The effort of reading something complicated and slowly building up enough understanding to have an opinion about it. That’s where learning happens.

    And AI is pretty great at removing both kinds of friction.

    Thinking happens in the making

    Everyone will tell you that you should leave the implementation to AI and spend more of your time thinking about the architecture, the systems, and the bigger questions that you need to grapple with in your work. We can use AI to speed up the writing so we can spend more time thinking and developing the ideas rather than worrying about how to express them.

    That advice assumes the message and the medium are decoupled. Often they aren’t. Sometimes we don’t know what we mean until we have exercised the act of typing it or writing it down. That’s what happened when I flattened my drafts. The point survived, but the meaning around it didn’t. Sometimes we don’t know what the system could be until we’ve tried to build it ourselves.

    Think about any project you’ve ever worked on. You can spend weeks planning it, breaking down the work, thinking through the architecture, and accounting for every scenario you can imagine. And then you start building, and you discover something that changes your understanding of the problem. Maybe a constraint you hadn’t considered changes the architecture. Maybe an abstraction that seemed perfectly reasonable on paper doesn’t actually work very well in practice. Maybe you realize halfway through that you’ve been solving the wrong problem entirely.

    You couldn’t have planned for all of that because you hadn’t encountered it yet. Some understanding only comes from doing the work.

    We don’t know what we don’t know. AI can sometimes surface those things for us, like the edge cases I mentioned earlier. But being handed the answer is a different experience from running into it yourself.

    The saved hours go back to production

    And when AI does free up our time, are we actually using it to think more deeply and develop our ideas more strongly, or are we just moving on to the next thing?

    Because those are two very different outcomes.

    And there’s another angle to this that I hadn’t really considered until I saw an Instagram reel the other day.

    It posed an interesting question about incentives in organizations. Imagine two employees, both working eight-hour days. One figures out how to use AI to get their work done in five hours instead of eight. The other continues working the way they always have.

    What happens to the first employee? Do they get three hours back to learn, explore, think, or simply take a break? Or do they get three more hours of work added to their plate?

    In many organizations, I’d bet it’s the latter.

    And if that’s the case, what incentive does that employee have to share how they’re using AI? They’ve become more productive, but the reward for that productivity is more work, more responsibility, and more pressure. For the same pay.

    We keep saying that AI will free us from implementation so we can spend more time on deeper thinking. But that assumes the time we save is ours to spend. It assumes that we, and the organizations we work in, will value the thinking as much as we value the output.

    And I’m not sure we’ve figured that part out yet.

    If every hour saved becomes another hour of production, we’re not necessarily creating more room for learning. We might actually be creating less.

    We’re removing the friction that helped us develop expertise, while simultaneously increasing the expectation that we produce more with the time we’ve gained.

    That’s a strange trade to make.

    Of course, organizations should benefit when their people become more productive. That’s part of why we invest in better tools in the first place. But there’s a difference between reinvesting that productivity into more valuable work and simply expecting more output.

    Choosing the friction

    When I hand something off to AI and come back to a working solution, I’ve accomplished what I set out to do. But depending on the task, I might not understand the solution nearly as well as I would have if I’d worked through it myself. I can review it, test it, and verify that it works. I can even ask AI to explain how it works. But that’s not the same experience as having built that understanding along the way.

    Not every implementation needs to be an educational experience. There’s plenty of work I am over the moon about never having to do manually ever again.

    Still, there is a difference between being able to produce something and being able to understand how to produce it.

    And understanding doesn’t necessarily mean having to do every part of the work yourself. Experienced engineers have always relied on other people to implement things, while still being responsible for understanding the systems they’re building and making good decisions about them. AI isn’t entirely different in that regard.

    But those experienced engineers developed their judgment somewhere. They had opportunities to make mistakes, discover constraints, wrestle with tradeoffs, and learn from the consequences. If we’re increasingly removing those experiences, what takes their place? And we’re all still developing that judgment. It’s a lifelong venture, after all.

    Doing everything manually isn’t the answer. I’m not interested in spending hours on something that could be done in minutes just to prove that I can. And I certainly don’t think we should measure someone’s expertise by how much suffering they’ve endured to develop it.

    But I do think we need to be more thoughtful about what we’re giving away.

    When we remove friction from our work, what are we making room for? Are we making space to explore, experiment, develop our judgment, and become better at what we do? Or are we simply making room for more work?

    And when we encounter something difficult, maybe it’s worth asking ourselves whether the difficulty is getting in the way of the work, or whether working through it is part of the work.

    I don’t know the answer to that question. I’m still figuring it out, and I suspect the answer will change as the technology does.

    But I know I don’t want to reach a point where I’m producing more than ever before while understanding less and less of what I’m producing.

    I want to be better at my craft tomorrow than I am today, and speed alone won’t get me there.

    And I think that means sometimes choosing to work through the friction instead of around it.

  • The bridge was never written down

    AI is a building block. That was the argument in my last post. AI already helps my team in the ways you would expect. It helps us write code, draft plans, move work forward. Where it keeps coming up short is narrower and harder to name. It does not do the thing an experienced teammate does almost without thinking: surface the decision that matters and connect the dots, so someone lands on the right call instead of a defensible wrong one. That is the workflow I do not have an AI-native version of yet, and I am still working out what it looks like for my team.

    I spent last week at a conference, a full week away from my team. While I was gone, the kind of gap I have been trying to close opened up. A question came up whose answer meant connecting a few things that lived in separate places and had only ever been connected in one person’s head, which this time happened to be mine. The team is more than capable, and they worked through it. It just took longer, and some of it stayed open, because the reasoning that would have connected those things quickly was not written down anywhere. What stayed with me afterward was structural. The reasoning had no home other than a person, so the moment that person was out of reach, so was the reasoning. It could just as easily have been anyone else on the team. And I spent that same week in room after room where vendors and sponsors were each trying to build some version of the thing that would have kept that from happening. The word they all reached for was context.

    It came up so many times, from so many angles, that I started to suspect we were all using it to point at something none of us had defined.

    So this is not a finished thought. It is the closest I have gotten after a week of listening and a longer stretch of chewing on it, and I am still not sure it is right. But it is the most any of this has clicked for me so far, so I want to try writing it down.

    The person was the bridge

    For a while I assumed the problem was that AI lacked context, and that the job was to go get it more. That holds right up until you ask when the context went missing, and there is no good answer, because it never did.

    The individual systems, while not simple, exist already. The hard part was the reconciliation between them. Someone experienced holds the state of the code and the thread from three weeks ago and the decision nobody wrote down, all at once, and produces a judgment. That reconciliation was always the expensive part, always done partially, and it almost never got written down, because a person could get away with holding it. There was no cost to leaving it implicit. The person was the bridge.

    None of this is new. It is a tale as old as teamwork. Teams have always tried to get this reasoning out of people’s heads and into something the rest of us can use, through documentation and curation and pruning and the constant updating that keeps any of it true. That work is slow and expensive, and most teams undervalue it right up until it is missing. Mine is no different. We pay that tax by hand, imperfectly, because functioning without it is worse.

    What has changed is the urgency, because teamwork now includes agents. AI did not remove the person who did the reconciling. It ended our ability to leave that work implicit. An agent cannot do the intuitive, partial reconciliation someone does in a hallway conversation, and it will not quietly cover the gap the way a person did. So a gap that was always there, always a liability, suddenly has a cost attached to it, and you feel it at the scale of a team.

    This is the bus-factor problem, at the scale of a whole team. Every one of us is holding reasoning that someone else would need. When anyone is out for a week, there is knowledge in their head, about the design system, or an infrastructure choice, or how the analytics are wired, that the rest of us would have to piece back together. The reasoning that connects our systems of record has been living in people, and it has always been one departure away from gone. That was easy to look past while someone was there to reconstruct it live, on demand, for free. It gets harder to look past as teams push more decisions onto more people and more agents, because for any of that to work the connective reasoning has to leave the heads it lives in.

    What I want is a pit of success, so the right call is the easy one to fall into no matter who is or is not in the room that day.

    Everyone was building a different house

    Not every talk was about this. But context kept surfacing, and a striking number of the vendors and sponsors were each, in their own way, trying to fix some version of the same problem. Watching them not quite agree is what made me start pulling on the thread.

    One team argued the answer is a single company-wide wiki, grown rather than built, where every entry carries a human’s name and an agent proposes changes a person accepts. Another argued you should not curate a store at all, because stores go stale, and you should generate context on the fly from a graph over your live sources. Another argued that flat files fall apart under many hands, and that you need a temporal graph that keeps the provenance of every derived fact through every merge and revision. Another argued the whole reason coding agents work and knowledge-work agents flail is that code has a repo, a history, tests, and an undo button, and knowledge work has none of them.

    They sound like competitors. What I started to see instead was people building different houses for the same missing thing, each trying to find a place to keep the reasoning that used to live in a head. They looked like they were competing over context. Underneath, they were competing over where the bridge should live.

    The bridge is a record

    Here is the piece that made the rest click, at least for now. What we are missing is a record of the bridges: the reasoning that says why the code looks the way it does, why this account gets handled differently, why we stopped doing the thing we used to do. A bridge connects two systems of record, and the reasoning for why it connects them the way it does is content in its own right.

    Which means the bridge is a system of record too.

    I keep sitting on that, because it reorganizes how I see the whole problem. It is tempting to treat a bridge as plumbing between the real records. I think the bridge is a record. It gets built, which means someone had a reason. It can be inspected, which means the reason can be read. And it can fall down, which means that when one of the things it connects changes, the bridge might no longer hold, and someone has to know it was there in order to go check.

    Any one of us, looked at this way, is a walking set of bridges. Take any engineer on the team. Somewhere in our components a value is hard-coded instead of pulled from the token, and the code gives no hint why. The reason is a call they made months ago, tied to an accessibility decision that lives in a doc almost nobody opens. The same thing shows up everywhere once you start looking. A cache holds for thirty seconds because of a commitment that lives in a contract and never made it into the code. A service runs in one region and not another because of a data residency rule no one wants to relearn. An analytics event carries a specific meaning, and the definition that makes the dashboards trustworthy lives in one person’s memory and nowhere else. In each case the bridge is the sentence connecting the two sides: this is done this way because of that, and if that changes this should be revisited. It exists in neither system. It exists in a person. When they are out, the bridge is out with them, unless somewhere along the way it became a record.

    Who builds the bridges

    If bridges are records, the next question is who writes them? And here the sharper instincts from the conference help. Nobody is going to hand-author the reasoning connecting their systems of record for the benefit of a future stranger. That has never happened and it will not start now. I am not going to either.

    But an agent can propose a bridge.

    It can look across the code and the thread and the ticket, derive a reasonable guess at why they connect, and put that guess in front of a person. The person ratifies it, corrects it, or throws it out. The correction gets captured, with a link back to where it came from, and it becomes a record the next developer and the next agent start from instead of rebuilding.

    I want to be careful here. The agent is not the verifier. It does not know whether the reasoning is right or the decision was sound. That judgment stays human. What an agent can do is derive, propose, and expose, so the reasoning stops dying in someone’s head or a closed session. The machine drafts the bridge. The person says whether it holds.

    It concentrates the hard problems, it does not solve them

    Here is the thing though. Making the bridge a record concentrates the hard problems rather than solving them, and it puts them somewhere I can point at. The bridge goes stale when either side changes. It needs provenance, or it turns into a confident claim with no way back to its justification. Someone has to verify that a proposed bridge holds, and that someone is a human, at a cadence I do not yet know how to scale. I am not going to pretend I have solved that here.

    Even so, locating the problem feels like progress. For as long as I called all of this context, the hard parts were smeared across a word that could mean almost anything, and I could not say where they lived. Naming the bridge as a record brings them into focus. Staleness bites on the bridge. Provenance is required on the bridge. Verification, the real kind, will have to happen on the bridge.

    Framing it this way also lets me stop treating retrieval and recency as separate problems. While the reasoning lives in a head, you cannot find it, you cannot tell whether it is current, and you cannot tell whether it is right. Those are symptoms of the same missing home. A record with an address and a version answers the first two almost by construction. What is left is keeping it honest, which is the expensive part, for the same reason verification is: someone has to judge.

    There is an obvious next question hiding in that ratify-and-correct loop, which is whether the system itself gets better at proposing bridges over time, instead of only accumulating better ones. That turns entirely on whether the correction signal can be trusted, which is harder than anything here, so I am leaving it alone for now. I raise it only so it is clear I can see it. The same goes for whether AI should be doing this reconciliation at all, and for how we ever confirm that ratified reasoning was sound. Those are their own questions.

    What I have, and what I don’t

    So this is where I am, for now. I think context was never the thing missing. It has been sitting in the records we already keep. The thing that lived only in people was the reasoning that bridges those records, and it was fine to leave it there right up until we asked something that was not a person to do the connecting.

    I think those bridges have to become records of their own, built by agents proposing and humans ratifying, so that when any one of us is out of reach, the reasoning is still there for the people and the agents who need it.

    I do have a hunch about where those records should live, and it points back to one of the houses I heard argued for. Of all of them, the wiki is the one I keep returning to, something richer than a pile of markdown files and still recognizably a wiki. I am not ready to make that case yet, so it is a piece for another day.

    What I do not have is what that workflow actually looks like. I have watched, up close and recently, what happens without it, and I know I do not want the fix to be a person quietly put back into the wrong part of the loop to do the reconciling by hand.. I know the outcome I want. I am still looking for the mechanism.

  • AI is not a tool

    Lately I have been paying attention to how people talk about working with AI. There is a phrase that keeps coming up, in conversations and on stages and in the updates companies send around. We are becoming an AI first team. We are going AI first. And whenever I hear it, I find myself wanting to ask the same follow up question. What does that actually look like on a Tuesday?

    The answer is usually some version of the same thing. Everyone has Claude in their editor now. We ship a little faster. Code review moves quicker. The boilerplate writes itself.

    All of that is real. Having AI in your editor genuinely makes you faster, and I am not interested in pretending otherwise. But the longer I sit with it, the more I think we are using one phrase to describe two very different things, and that the blur between them is holding us back.

    The line I keep looking for

    So I have been trying to find the line. What separates a team that has truly reorganized itself around AI from a team that has simply added AI to the way it already worked?

    Here is the question I keep coming back to, and it is almost embarrassingly simple.

    If you take the AI out of the workflow, does the workflow still make sense?

    When the answer is yes, you have an AI assisted workflow. The shape of the work is the same as it has always been. You are writing code the way you have always written code, and the AI is sitting next to you making each step smoother. Take it away and you are slower, maybe noticeably so, but nothing fundamental breaks. The recipe is unchanged. You just lost a fast pair of hands.

    When the answer is no, something more interesting is happening. The workflow does not have a slower version. Without the AI there is simply nothing there, because the AI was never sitting beside the work. It was holding part of it up.

    Where “tool” stops fitting

    That distinction took me a minute to see clearly, and once I did, I started to understand why so much of what gets called AI first is really AI assisted in nicer clothes. The cause, I think, lives in a word we use without examining it.

    We keep calling AI a tool.

    I understand the instinct. It arrives as software, you open it in a window, you type things into it. It feels like a tool. And the more I work with it, the less that word feels like the right mental model.

    I want to be careful here, because I do not mean this literally. A programming language is technically a tool too, if you want to be precise about it. But a language does not sit at the same layer as an IDE or a linter. You do not bring it to your work the way you bring an editor to your work. You build the work out of it. And that is the layer AI has started to occupy for me. Closer to a programming language than to an editor. A building block rather than a tool. It is one of the materials the work is made of, not one of the instruments I carry to work I have already designed. Tools get added to old workflows. Building blocks get built from.

    This is also why the subtraction question works the way it does. An AI assisted workflow degrades when you remove the AI, because the AI was an addition. An AI first workflow does something else. It reverts. It falls back to needing a person, because the thing the AI was doing was never a faster version of a human task. The capability had always existed before, but only through a person, only as a dependency on someone who already understood the system.

    A capability with no slower version

    This is easy to nod along with and hard to picture, so let’s talk through an example.

    Imagine someone on your team who cannot read the codebase. Maybe they work in marketing, or design, or operations. Maybe they do not even have access to the repository. They hit a question in the middle of their own work, the kind of question that has only ever had one answer: go find an engineer who knows, and wait. Now imagine they can ask that question directly, in plain language, and get an answer good enough to unblock them and keep moving.

    Sit with what happens to that workflow if you remove the AI. It does not get slower. It vanishes, and the old dependency slides back into its place. Go find an engineer. Wait. There was never a manual version of someone who cannot read code reading the code. The capability was made entirely of the model. That is what built from AI actually means.

    When intelligence stops being scarce

    When I first built something like that, I thought of it as a convenience. A way to spare engineers a few interruptions. But I have come to think the real change is sitting underneath the convenience, in something closer to economics.

    For as long as I have worked in software, one fact has shaped every workflow I have ever designed, usually without my noticing it was doing the shaping. Human attention is scarce and expensive. The person who understands the system is a bottleneck, so you build careful structures around protecting their time. You route questions to them. You queue work for them. You write documentation so people will interrupt them less. A surprising amount of what I once thought of as good process is, when I look at it honestly, a strategy for rationing a scarce supply of understanding.1

    What changes with AI is subtler than speed. A usable version of that understanding suddenly becomes abundant. Human attention is still scarce, still expensive, still the thing I would protect first. But synthetic attention, the kind that will answer a reasonable question about the codebase at two in the morning for the hundredth time without tiring or resenting it, is now cheap and plentiful. And once something that used to be scarce becomes abundant, every workflow you built to ration it is up for question.

    Holding the outcome, letting go of the path

    The part of this I am still learning to do well is what it asks of me as the person directing the work. When AI is a tool, I stay in charge of how. I decide the steps, and the tool carries them out. When AI is a building block, my job moves. I become responsible for holding the outcome and for being almost uncomfortably clear about what a good result actually is, and I hand off a great deal of the how.

    It is a little like the relationship between a tech lead and a developer on their team. You decide the goal, and you decide what done looks like. They work out the path to get there, and often they find a path you would not have chosen, and sometimes it is better. Your clarity about the destination ends up doing more work than your opinion about the route.

    I have been learning a version of this same lesson somewhere completely outside of AI. When you stop leading the work directly and start leading the people who lead the work, you run straight into it. You have to hold the outcome and let go of the path. Some days that letting go is the hardest thing in the world, and some days it is a quiet relief, and I have not fully made peace with which one it will be on any given morning. It turns out an AI first workflow asks for the same muscle. Define the outcome with real care. Release the route.

    I made a fairly large bet on all of this recently. I built something with my team that only makes sense if you believe AI is a building block, something that would be incoherent if I tried to explain it as a faster version of what we already did. I am going to write about that next, properly, as a case study, because it deserves more room than I can give it here.

    What the work was actually for

    For a while the question I asked was what this tool could do for me. Lately the question has gotten bigger, and a little less about me.

    I have stopped thinking of this as a question about technology. The question an AI first team is really answering turns out to be an organizational one. Which parts of how we work only ever existed because intelligence used to be scarce? Which approvals, which handoffs, which queues, which roles are load bearing, and which are scaffolding we put up to protect a resource that is no longer rare?

    The teams that get the most out of this will not be the ones who push AI into every corner of what they already do. They will be the ones willing to look at a process they have run for years and ask what it would become if the thing it was built to protect were suddenly cheap. That is a harder question than it sounds, because it means letting go of structures that have felt like good engineering for a long time. But I am fairly sure it is the actual work. The tool framing keeps us busy making the old thing faster. The building block framing lets us ask what the old thing was for in the first place.

    1. I’m not against process, I’m just examining the source of a lot of our current procsses ↩︎