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.