The builders who scale themselves will win. Here's how that starts
The code was the easy part. The decisions were the work.
🤖 Field Notes · For developers rethinking how they work.
This week’s challenge: map one daily task into what’s judgment and what’s execution.
A few weeks ago, someone asked me a question on Slack. Simple situation: a team member reported that the admin panel was loading slowly. Another person confirmed the same issue. Then a non-technical colleague asked me in the channel: “What can I do to help you investigate the delays?”
Innocent question. The kind that takes thirty seconds to read and thirty minutes to answer properly.
The first problem wasn’t the answer itself. It was everything before it. To respond properly, I needed to reconstruct what had actually happened. Find the original report from earlier that morning. Find the second person’s confirmation. Check if there were shared recordings or screenshots. Piece together the timeline. That meant scrolling through messages, jumping between threads, hunting for context scattered across the channel. Most of the time went there. Not thinking, just searching.
The second problem was the answer. The question came from a non-technical person, in a public channel where others were reading, about something deeply technical. I needed to turn a diagnosis involving logs, traces, and time windows into something useful for someone who has no access to any debugging tools. And I needed to do it without being condescending.
So I opened an AI assistant and gave it everything I’d gathered. The raw messages, my diagnosis, who was asking and why, the fact that this was a public channel.
The AI gave me three options at different tones. I picked the shortest one, pasted it into Slack, and moved on.
That’s what building with AI actually looks like. Code generation is just one piece. The real gain is saving time across the entire process. Retrieving context, structuring communication, making decisions faster. AI handles the parts that used to eat your hours, so you can focus on the parts that need you.
The workflow nobody talks about
Most content about “building with AI” shows you the glamorous version. Someone types a prompt, code appears, product ships. That’s like saying filmmaking is pointing a camera at something interesting.
Here’s what my actual day looks like.
I spend most of my time doing what I’ve always done: understanding problems, making decisions, communicating with people. The difference is that the execution layer, the part that used to take the most time, is increasingly handled by AI. It still needs supervision. It’s far from perfect. But it’s fast enough that the bottleneck has shifted.
The bottleneck used to be typing. Now it’s thinking.
If you did last week’s exercise, imagining five versions of yourself and mapping what you’d delegate, this is exactly what that looks like in practice. I looked at my day and found the bottleneck: not the decisions, not the communication strategy, not the judgment calls. The context retrieval. The mechanical act of hunting for information I already knew existed somewhere.
That’s the power of thinking before building. Without that map, I would have tried to automate the wrong thing. Maybe the answer drafting, maybe the triage. Instead, I saw that retrieval was the stage eating the most time with the least judgment involved. The exercise didn’t just identify a problem. It pointed directly at what to build.
So I built a tool to fix it.
What I actually built
I built an agent that monitors my Slack channels, identifies when something needs my attention, and gathers the relevant context before I even open the conversation. Think of it as a secretary. It watches, filters, and reports back, telling me what matters and why, not just a list of messages.
The technical stack doesn’t matter. It was built with whatever solved the problem fastest. No web app, no dashboard, no over-engineered architecture. A command-line tool, a bot with read access to channels, and an AI layer that processes messages into briefings. The simplest thing that works.
The hard part wasn’t the code. AI wrote most of it. The hard part was the decisions. Which channels should it monitor? What counts as “needs my attention”? A direct mention is obvious. But what about my team lead posting “looking into the deploy issue, might need help later”? No question, no mention, no explicit request. I’d want to know about that immediately, not because of what was said, but because of who said it. The AI missed this completely. It treated every sender equally. I had to teach it that some people’s ambient messages matter more than other people’s direct questions.
Every one of these decisions shaped the tool more than any line of code did.
The plan was the starting point. Reality shaped the rest.
Before building, I mapped out the process I was trying to automate. Five stages: triage, context retrieval, answer formulation, audience adaptation, and codebase lookup. Clean, logical, sequential.
The plan was to build them one at a time. Start with context retrieval, pulling related messages when a question comes in. Then add voice and standards to draft answers in my communication style. Then audience adaptation. Then the advanced stuff.
That plan lasted about two days.
Pure context retrieval without any intelligence layer wasn’t useful. Dumping twenty related messages on my screen didn’t save time. It just moved the problem from “find the messages” to “read all these messages.” The tool needed to process the context and tell me what mattered, not just fetch it.
So I compressed two steps into one. Context retrieval merged with summarization. The agent doesn’t just find related messages. It reads them, identifies the key points, and presents a briefing I can act on.
This is something every developer learns eventually but rarely from a tutorial: the spec is a starting hypothesis. The build is the experiment. What you ship is whatever survived contact with reality.
The challenges showed up during use, not during building
The tool worked on the first day. But using it daily revealed gaps that building it never would.
The biggest one: conversations that escalate. Someone posts a message. The agent evaluates it, decides it doesn’t need my attention, moves on. Hours later, someone replies in that thread asking for my input. The agent never sees it. It already dismissed the conversation. The most important discussions are the ones that grow over time, and those were exactly the ones it missed.
Another one: it treated every person the same way. A message from my closest collaborator got the same evaluation as a random message in a large channel. But in real work, there are people whose messages I cannot afford to miss, regardless of content. Not because of what they said, but because of who they are.
Each gap became clear only because I was using the tool every day, on real conversations, and noticing where it fell short. Then I’d adjust, use it again the next day, and see if the fix held. The build didn’t end when the tool started working. That’s when it actually started.
This is what building with AI actually looks like
It’s not typing a prompt and shipping the result. It’s a loop:
Build something. Use it for real. Notice where it fails. Understand why it fails, not technically, but functionally. What does “reliable” mean for your specific context? Fix the right thing. Use it again.
The code was the easiest part of the entire process. AI generated most of it. What AI couldn’t do was decide what to build, identify which failures mattered, or determine what “good enough to rely on” means for my daily work.
That’s the new skill. Not writing code, not even prompting AI — but knowing what to build, evaluating whether it actually works, and iterating based on real use rather than theoretical specs.
The developers who figure this out will build at a speed that would have been impossible five years ago. The speed comes from something deeper: the entire cycle from idea to working tool compresses when you stop treating code as the bottleneck and start treating decisions as the work.
Try This
If you did last week’s exercise, you have a list. Tasks you’d delegate to other versions of yourself. This week, pick one. The one that eats the most time.
Now zoom in. Break that task into stages, not technically, but cognitively. For each stage, ask one question:
Is this judgment or execution?
Judgment is when you’re making a decision that depends on experience, context, or taste. Understanding what someone is really asking. Deciding whether an approach is sound. Choosing what to prioritize.
Execution is when you already know what to do and you’re just doing it. Searching for information. Formatting a response. Looking up documentation.
Be specific. “Do research” is vague. “Search on ChatGPT to understand how the payment API handles refunds” is a stage you can actually evaluate.
You’ll notice something. The execution stages are where your time goes. The judgment stages are where your value lives. That gap is your building map. Every execution stage is a candidate for a tool. Every judgment stage is a reason you’re still in the room.
Last week you saw the big picture. This week you have a target.
The Deeper Cut
The biggest mistake I see developers make when they start building with AI isn’t technical. It’s scoping. They try to automate their entire workflow at once. Grand vision, massive spec, weeks of building before testing against reality.
My Slack tool started with one question: “Can it find the messages I would have found manually?” Just that. One specific, testable capability. When that worked, I expanded. When it didn’t, I knew exactly what to fix.
That tool, the one I described in this edition, is available to paid subscribers. The actual artifact, ready to use: the code, the instructions, the decisions behind it. You can use it, adapt it, learn from it. Every building block I create on this journey becomes an artifact that paid subscribers can pick up and make their own.