🤖 Building with AI · For developers rethinking how they build

This week’s challenge: take a recent AI output that disappointed you and refine the thinking behind it instead of the prompt.

My Slack was a context-switching tax I couldn’t stop paying. Direct messages from people waiting on answers. Public channels I should have been following. Threads I’d dropped into and lost the plot of. Every time I opened the app to reply to one thing, I had to reconstruct what that thing was about, who was involved, what had already been said. By the time I had the context back, half an hour was gone and the reply was two sentences. The cost was real: decisions delayed, things slipping through, the slow weight of knowing I wasn’t keeping up.

So I spent one week building a tool to fix it. A context retrieval agent that would scan my channels and surface what mattered. The spec was clean: related messages, link summaries, timeline. No synthesis. Synthesis was a separate concern, deliberately kept out of scope.

The AI executed exactly to spec. I ran the first real test on my actual inbox. The output was completely useless.

Reading it took about as long as reading the originals would have. The structure was clean, the format was clear, and I sat there looking at days of work, feeling the exact same weight as before. Same backlog. Same triage waiting. The tool had solved the problem on paper. The actual problem hadn’t moved.

The reflex, in that moment, is to fix the prompt. Add structure. Constrain the response. Most developers I watch do exactly this:

1. Output misses.

2. Prompt gets tweaked.

3. Retry.

The loop runs until the output looks acceptable, and they move on. They’ve built nothing except a slightly better prompt.

I almost did the same thing.

Then I made myself stop and read what the output was actually telling me. The spec was built on a principle I’d never tested: that separating retrieval from synthesis protected clarity. The output had just demonstrated the opposite. Synthesis was the work that made retrieval useful, and I had specified it out of scope. I rewrote the spec to fold the two together, ran it again, and the output became something I could act on.

The AI hadn’t failed. It had executed perfectly against thinking that was incomplete in a way I couldn’t see until I read the result.

That’s what AI does. It compiles your thinking and shows you what you actually thought.

The diagnostic loop

Before the diagnostic loop makes sense, you need to recognize the anti-pattern it replaces. Call it the prompt chase: tweaking the request until the AI produces something acceptable, then moving on. Alter, execute, evaluate. Alter, execute, evaluate. The chase ends when the output looks good enough, not when the thinking behind the request is right.

Each lap of the chase costs almost nothing. That’s the trap. Two hundred small alterations later, the developer has something usable and has learned nothing about how they think. The diagnosis was available in every output and went unread.

The diagnostic loop replaces the chase with a different movement. The trigger is the same, an output that missed, but the next five steps run one layer up from the prompt:

1. Stop. Don’t touch the prompt. Don’t try again. The pause is where the loop happens.

2. Name the gap. Write one sentence describing what the output delivered. Write another describing what you needed. The difference between the two is the diagnosis.

3. Locate the layer. The gap lives in one of three places: the spec (you asked for the wrong thing), the category (you used a word that carried an untested assumption), or the context (you knew something you never articulated).

4. Refine that layer. Write down what was implicit and is now explicit. The tested assumption. The corrected category. The missing context. This is the work. It takes longer than rewriting a prompt and produces something a prompt never will.

5. Rebuild the brief. Now the prompt comes back to the table, but informed by refined thinking instead of by guessing what phrasing might work better.

The opening was the easy version of this loop, with the gap sitting on the surface of a spec I could just reread. Most gaps don’t sit on the surface. They hide inside the words you used or in the things you knew so well you never said them out loud.

Categories that hide in plain sight

The retrieval example was a specification gap. The next gap I hit was deeper, and the diagnostic was harder to read.

After the tool was working, I started inventorying its reusable parts, with one eye on something bigger. The Outcoders program needed building blocks that other developers could pick up and run, not just code I wrote for myself. Six components inside the tool were generic enough to live independently of the Slack-specific orchestration: a context retriever, a voice processor, a deduplication pattern, a few others. The intuitive move, the one any developer would reach for, was to extract them into shared libraries. Reusable code, single source of truth, standard pattern.

I asked AI to help me think through the extraction. The output came back: clean library structure, clear interfaces, sensible naming. Exactly what I’d asked for.

I almost moved on. The output was good. It matched the request. Then something started bothering me, an intuition that something could go wrong. The kind of low-grade discomfort you get when you’re about to ship something that’s correct on the surface and going to hurt you in six months. I made myself sit with it long enough to find out what.

The diagnostic question that surfaced was unexpectedly mundane: if I extracted these as libraries, what would the next person who wanted to use one actually do? The answer was uncomfortable. They’d import the library. They’d inherit its dependencies. Any change would force a coordinated release across every project that imported it. I’d be handing every Outcoder a tight coupling I was supposed to be helping them avoid. The reuse I was optimizing for would create exactly the kind of drag that kills momentum in a small program.

The output was correct against the wrong category.

What I had treated as utilities were capabilities. A library shares code at build time; a capability is something you call at runtime. A library couples its consumers together; a capability stays independent. The word “library” had been carrying assumptions I hadn’t examined, and the AI had executed against those assumptions perfectly.

Refining the prompt would have produced a better-organized library, and I would have shipped the wrong foundation to a program I was just starting. Refining the category produced an entirely different architecture: independent agents, composed at runtime, no shared imports. The implementation work that followed took a week. The decision itself took an afternoon, once the category was correct.

This is the part of the diagnostic loop that’s easiest to miss. The gap isn’t always in what you specified. Sometimes it’s in the words you used to specify it. The output reveals the assumption inside the word, but only if you’re listening for it.

The context you didn’t articulate

The third gap is the one I see most often in other developers’ work, and it took me longest to recognize in my own.

Someone in Slack asked a question. I drafted a reply with AI. The response came back: technically accurate, well-structured, complete. I read it and almost sent it. Then I noticed it sounded condescending. Not by much. Just enough that the person reading it would feel slightly talked down to. The information was right. The tone was wrong in a way that would matter.

The first instinct, again, was to adjust the prompt. Tell the AI to be warmer, less formal, more collaborative. That instinct produces an output that’s better in a generic way and still wrong for the specific situation.

The diagnostic question that worked was different: what does the AI not know that’s making this miss? The answer became obvious as soon as I asked. The AI didn’t know the person was non-technical. It didn’t know we were in a public channel where other people would read the exchange. It didn’t know that the question, which sounded innocent, came from someone who lacked the vocabulary to ask for what they actually needed. None of that was in the brief, because none of that was articulated in my own thinking. I knew it implicitly. I hadn’t externalized it.

What needed refining was the model of what makes a reply work, not the prompt. Audience metadata. Channel context. The gap between the literal question and the underlying need. Once those were explicit pieces of the brief, the output stopped missing.

The AI made visible something I’d been holding implicitly for years: the work of replying well lives in modeling the situation correctly, long before any words get written. I’d been doing the modeling unconsciously, which meant I couldn’t teach it, couldn’t delegate it, and couldn’t improve it. The diagnostic loop forced the model out into the open, where it could be refined.

What the loop actually builds

The previous editions were about making thinking visible: first to other people, then to yourself. This edition extends that practice to the third audience most developers interact with every day but never think of as an audience. AI consumes the same externalized thinking your colleagues do, and it consumes it more literally. When your thinking is implicit, a human colleague fills in the gaps from shared context. AI doesn’t. It executes what’s there. That’s what makes it a diagnostic.

The diagnostic loop is the simplest version of that practice. It’s available every time you work with AI, which for most developers now means several times a day. Each output is a chance to read the diagnosis. Most developers skip it. The ones who don’t skip it are building a different kind of capability with every interaction, while everyone else is running the prompt chase.

Every cycle through the diagnostic loop leaves a residue: a tested assumption, a refined category, a piece of context you’d been carrying implicitly that’s now explicit. The residue accumulates. Over months, that accumulation is what people call structured thinking. It isn’t a thing you have before you start. It’s the by-product of a loop you ran enough times.

A better prompt has a short shelf life, because the ground underneath it keeps moving: models get retrained, interfaces shift, and the exact phrasing that worked yesterday needs adjustment tomorrow. Refined thinking sits on more stable ground. A category you understood correctly last month will still be correct next month, an assumption you tested last quarter doesn’t need testing again, and a model of what makes a reply actually work isn’t going to expire when the next version of the AI ships.

The developers running the diagnostic loop are quietly building an asset that never shows up in any output. The ones running the prompt chase are stuck producing deliverables and nothing else.

Try This

Pick one AI output from the last week that disappointed you. Not a catastrophic failure. A mild miss. Something that was technically fine but didn’t actually solve your problem.

Run the diagnostic loop on it. The five steps are above. No shortcuts, no skipping to step five. The value lives in step one, the pause, and in step three, naming which layer the gap lives in. Most people rush through those two and end up refining the wrong thing.

When you reach step five and rebuild the brief, use the new brief with the AI and compare the outputs. The interesting part isn’t whether the second output is better. The interesting part is what you had to articulate to get there. That articulation is the residue. Save it. Over enough loops, those pieces of articulated thinking are the structured thinking everyone says you should have.

The point of the exercise isn’t to fix one output. It’s to run the loop once with full attention, so the shape of it becomes yours. After that, you’ll start catching yourself running the prompt chase and have a choice you didn’t have before.

The Deeper Cut

The hardest part of the diagnostic loop is the pause itself. The chase runs at the speed of reflex, and the loop runs at the speed of attention. Bridging that gap reliably, every time, has been the real practice. So I’m building something to help.

Most AI tools aimed at developers do the opposite of what this edition argues for. They optimize the prompt. They suggest better phrasing, restructure the request, add missing constraints. They make the chase faster. The agent I’m building does the inverse: when an output disappoints, it walks me through the diagnostic loop instead of helping me write a better prompt. It asks where the gap lives. It pushes back when I try to skip step one. It makes the pause structural instead of optional.

It’s early. The first version is rough, useful enough for me, not yet ready for anyone else. But it’s the next building block in the program, and like every other artifact, paid subscribers will get access as it matures. The next few editions will follow the build: what the agent does, what I had to refine in my own thinking to make it work, where it surprised me, what it still gets wrong. The same diagnostic loop the edition describes, applied to building the thing that helps run it.

🧠 Mindset Shifts · For developers rethinking how they grow

This week’s challenge: take a recent technical decision and write one page explaining not what you built, but why.

Last month I spent two hours on a Slack conversation that changed the direction of a client’s product. The CTO wanted to rebuild their authentication system from scratch. The engineering team had already started estimating the work. They’d even diagnosed the technical problems: session handling was fragile, the token refresh had edge cases on mobile, the original implementation had accumulated years of patches. All of that was true. None of it was the point.

The team had asked “what’s the problem?” multiple times. But every time they asked it, they asked it inside the frame of the auth system itself. The diagnosis was technical, the solution was technical, and the scope grew from there. Nobody had stepped outside the frame to ask a different question: what’s the user actually experiencing, and does fixing that require rebuilding the whole system?

Forty minutes of conversation later, it was clear. The actual user problem was a session management bug that made mobile users log in twice. A fix that would take days, not months. The rebuild was a technically correct solution to a correctly diagnosed set of problems, and it was still the wrong decision, because the problems it solved weren’t the ones that mattered to the business.

I didn’t write a single line of code that day. The most valuable thing I did was a reframe: stepping outside the level where the team was thinking and asking the question from one level up. There’s no commit for that. No PR. No ticket that says “prevented three months of wasted work.” The output was a Slack thread that took two minutes to read. The thinking behind it took two hours, plus twenty years of watching teams solve the wrong problem because nobody stepped outside the frame long enough to check.

That thinking is invisible. And if you’re a developer, most of your best work probably is too.

The gap between what you do and what people see

Think about your last week of work. You shipped features, closed tickets, reviewed pull requests. Those are the visible artifacts: the things your manager sees, your performance review counts, your team tracks in standups.

Now think about everything else you did. The three approaches you evaluated in your head before picking one for that API design. The other two vanished the moment you started coding, along with the reasoning that eliminated them. The pattern you noticed across two unrelated bugs that pointed to a deeper problem in how the service handles retries, but you fixed the bugs individually, and the systemic insight never left your head. The moment in a planning meeting where you asked a question that shifted the entire scope of a feature, and everyone moved on as if the new direction had been obvious from the start.

Every developer I’ve worked with does this kind of thinking constantly. Evaluating trade-offs, noticing patterns, making judgment calls that shape the quality of everything they produce. It happens so naturally that most don’t even register it as work. But it is work. It’s the hardest part of the work, and it’s the part that differentiates a developer who delivers from a developer who delivers the right thing.

The problem is that none of it leaves a trace.

Developer culture has a deep bias toward visible output. Commits, contributions, shipped features, green GitHub profiles. Career advice reinforces it: build more projects, write more posts, contribute to open source. The message is clear: if people can’t see it, it didn’t happen.

So developers get evaluated, promoted, hired, and trusted based on the fraction of their work that’s visible. The reasoning, the judgment, the decisions behind the decisions, the part that actually determines whether the visible output was worth building in the first place, stays inside their heads. They give it away for free, every day, because nobody taught them to make it seen.

Why it stays hidden

Part of this is structural. The tools and rituals of software development are designed to capture outputs, not reasoning. Pull requests show diffs, not the decision process that shaped them. Standups ask what you did yesterday and what you’ll do today, not why you chose that approach over the alternatives. Sprint retrospectives look at what went wrong, not what was prevented by good judgment that nobody noticed.

There’s also a cultural dimension. Making your thinking visible can feel like showing off, like you’re claiming credit for something that should be implicit. Developers tend to let the code speak for itself, which sounds humble but is actually a form of self-sabotage. The code doesn’t speak for itself. The code shows what you built. It says nothing about what you considered and rejected, what risks you anticipated and mitigated, or why you chose the simpler approach when a more complex one was technically superior. All of that context evaporates the moment the PR is merged.

The result is a career built on a fraction of your actual contribution. Two developers who ship the same feature look identical from the outside: same PR, same outcome, same velocity metric. But one of them spent an hour thinking through edge cases, evaluating approaches, and choosing the design that would be easiest to extend in three months. The other copied a pattern from somewhere else and hoped it would hold. The difference between them is entirely invisible until something breaks, and by then, the developer who thought carefully has already moved on to the next project, with no record of the judgment that made the first one durable.

This invisibility compounds over time. Every year, you accumulate more judgment, more pattern recognition, more ability to see what others miss. And every year, that growing capability remains hidden behind the same visible output: code, tickets, deploys. Your most valuable asset appreciates in the dark, and the people making decisions about your career can only see the surface.

What changes when the thinking becomes visible

A developer once asked me a question that changed how I evaluated everyone after him. We were talking about coding practices, best approaches for structuring modules, the usual technical conversation. Then he said: “What should I do to make my colleagues’ job better?”

That question wasn’t about code quality. It was about how he thought. In one sentence, he told me that he didn’t see his code as a standalone product of his individual work. He saw it as something other people would have to live with, extend, debug at 2am, and build on top of for months after he’d moved to something else. That perspective is rare, and it’s invisible in a pull request. The code might look the same whether the developer was thinking about their colleagues or not. But the question gave me access to his mental model, and that access was worth more than any code review.

After that conversation, I could work with him differently. I could give him architectural responsibility, because I knew he was already thinking about the team’s experience, not just the feature. I could trust his judgment on trade-offs, because his frame extended beyond the immediate task. One question, one sentence of visible thinking, and my entire assessment of his trajectory shifted.

When I started managing teams, I carried that lesson forward. I looked for the developers who made their thinking legible, not just their output. And I started sharing that perspective with others: the developers who show you how they think unlock a kind of trust that no amount of shipped code can build.

This doesn’t require grand gestures. It means small, consistent acts of externalization. A PR description that includes one paragraph explaining what you considered and why you chose this approach. A Slack message that starts with the problem you’re solving before jumping to the solution. A standup answer that names the decision you’re facing, not just the task you’re working on. A brief comment before a code review that frames what the reviewer should pay attention to and why.

Each of these takes thirty seconds. Each one transforms how people perceive your work.

When a developer makes their reasoning visible, three things happen. First, other people start trusting their judgment, because judgment that’s visible can be evaluated and calibrated. The developer who asked about his colleagues’ experience earned architectural ownership from a single question. Second, they get pulled into higher-level conversations, because the people making decisions recognize someone who thinks about problems the way they do. Third, their own thinking sharpens, because the act of articulating a decision forces clarity that staying in your head never does.

That third effect is the one most developers underestimate. Writing down why you made a choice often reveals that your reasoning has gaps you didn’t notice. The decision that felt obvious when it lived in your head turns out to rest on an assumption you haven’t tested. The act of externalizing doesn’t just communicate your thinking: it improves it.

Edition #8 was about learning to read systems: seeing the business behind the code, the dynamics behind the team, the shifts behind the market. That skill is powerful, but only if someone else can see that you have it. Reading is perception. This is its complement: making your perception legible. Together they form the complete skill: the ability to see clearly and to be seen clearly.

The interview that proved the point

I’ve conducted hundreds of technical interviews over my career, including live coding sessions. The conventional understanding is that live coding tests whether the candidate can solve the problem. That’s wrong, or at least incomplete. An experienced technical manager already knows that most competent developers can solve most coding problems given enough time and a calm environment, neither of which exists in an interview.

What live coding actually tests is whether you can see how someone thinks. How they decompose a problem before writing anything. What questions they ask. How they respond when they’re stuck. Whether they can name what they don’t know and reason toward it out loud.

I’ve hired developers who didn’t solve the problem. They got hired because the way they thought about it told me more than the solution would have. They asked questions that revealed they understood the domain. They explained their approach before coding, so I could see the reasoning, not just the syntax. They said “I think this might fail here because...” and that sentence was worth more than a working function, because it showed judgment in real time.

I’ve also passed on developers who solved the problem quickly and silently. They produced the right output, but I learned nothing about how they got there. In a thirty-minute conversation, they gave me a diff and kept their thinking invisible. I had no way to evaluate the one thing I cared about most.

A company that only advances candidates who produce a correct solution in live coding doesn’t understand what the exercise is for. What the exercise actually reveals is the thinking, and a correct solution delivered in silence hides exactly what the interviewer needs to see.

The industry’s evaluation infrastructure is starting to formalize this. HackerRank, the platform that defined coding challenges for a generation, now evaluates what they call “AI fluency”: how developers collaborate with AI tools, the quality of their judgment when reviewing AI-generated code, the reasoning they apply when choosing between approaches. Their assessments increasingly measure thought process and problem-solving signals, because as AI handles more of the raw coding, the developer’s thinking becomes the primary differentiator, and evaluation is finally catching up to that reality.

The artifact library and what it’s been doing

Looking back at the exercises across these editions, I notice a pattern I didn’t plan. Every artifact I asked you to create was an exercise in making invisible thinking visible. Separating judgment from execution. Writing down how you make decisions. Capturing the reasoning behind a build before it fades into “that’s just how we do things.” Describing your vision precisely enough that someone (or something) else could act on it. Reading a system and writing down what you see.

None of those exercises asked you to write code. Every one of them asked you to externalize something that normally stays in your head. That’s what making thinking visible actually looks like in practice: not a single grand gesture, but a growing habit of giving your reasoning a shape it can survive in.

This week’s artifact makes that habit explicit.

Try This

Take a technical decision you made recently. An architecture choice, a tool selection, an approach to a bug, a feature you decided not to build, a refactoring you prioritized over new work. Something where your judgment shaped the outcome.

Write one page: not about what you built, but about why.

What problem were you solving? What was the context that made it a problem worth solving now? What approaches did you consider? What did you reject, and what was your reasoning? What trade-offs did you accept? What would change your mind about the choice you made?

When you’re done, show it to someone on your team. Not for approval, not for feedback on the decision itself. Show it for the experience of making your reasoning visible. Watch what happens. Notice what questions they ask: those questions tell you exactly what was invisible before. Notice whether the conversation that follows is different from the conversations you usually have about your work.

That difference is the gap this edition is about. The gap between what you do and what people see.

One page. One decision. The habit starts there.

The Deeper Cut

One of the hardest habits to build in developers is the practice of externalizing reasoning. In mentoring conversations, I see it constantly: developers who can evaluate code, design systems, and spot problems with real precision, and none of it reaches anyone else because they never developed the reflex to say it out loud. The thinking is sharp. The output is silent. The gap between those two is where careers stall without anyone, including the developer themselves, understanding why.

Paid subscribers get the thinking memo template: a structured format for documenting the reasoning behind technical decisions, designed to make invisible thinking legible without turning every choice into a formal document. It’s the same format I use in client work when a codebase assessment needs to convey not just what I found, but why it matters and what it means for the business.

🧭 Career Navigation · For developers rethinking how they grow

This week’s challenge: pick one system you work with daily (a codebase, a team, a product) and write a one-page assessment of what it tells you about the business. Not the technical state. The business implications.

I’ve been evaluating other companies’ codebases recently. A client sends me a repository, and I produce an assessment: what’s the real state of this technology, what are the risks, and what does it mean for their business.

The interesting part isn’t the technical analysis. Any experienced developer can look at a codebase and spot missing tests, hardcoded credentials, or a monolith that grew beyond control. The part that creates value is translating those findings into language a business owner can act on. “Your deploy pipeline has no automated tests” means nothing to a CEO. “Every time your team ships a feature, they’re gambling that it won’t break something in production, and you have no way of knowing until a customer calls” means everything.

I didn’t build that skill by studying assessment methodologies. I built it by spending twenty years inside systems where the technical problems were always symptoms of business problems that nobody had named yet.

That ability to look at a technical system and see the business underneath it is the single most valuable skill I’ve developed in my career. And almost no developer I’ve met, at any level, deliberately practices it.

The invisible career ladder

Developer careers have a standard progression. Junior, mid, senior, staff, principal. Each rung is defined, implicitly or explicitly, by technical depth. You get promoted because you can handle harder technical problems, mentor other developers, make larger architectural decisions. Above senior, the expectation does shift: soft skills, stakeholder management, and business understanding gradually become part of the job description. The progression isn’t purely technical at every level, and anyone who’s reached staff or principal knows that.

But even where business understanding is expected, it’s treated as a complement to technical depth, not a skill in its own right. The career ladder still assumes technical execution as the foundation, and everything else as something you layer on top once you’ve proven yourself technically. That made sense when technical execution was the bottleneck. When writing the code was the hard part, the people who could write harder code were worth more. The career ladder tracked the scarcity.

That scarcity is dissolving. AI writes increasingly complex code. The technical execution gap between a mid-level developer and a senior developer shrinks every month. If your career growth depends entirely on being better at the thing AI is getting better at faster than you are, the math doesn’t work.

But there’s a parallel ladder that most developers never notice, because nobody names it and no job description lists it. I think of it as the perception ladder: what can you see that others can’t?

A junior developer looks at a codebase and sees files, functions, classes. Syntax. They’re reading the words.

A mid-level developer looks at the same codebase and sees patterns, architectural decisions, technical debt. They’re reading the sentences.

A senior developer looks at it and sees the team’s history: where they rushed, where they were careful, where they changed their minds. They’re reading the story.

The developer who builds a career that lasts looks at the same codebase and sees the business: where it’s headed, where it’s stuck, what the technology is enabling and what it’s preventing. They’re reading the implications.

Each level of perception changes what you can do, which changes what you’re worth. And the jump between them has almost nothing to do with writing better code.

Three systems you should learn to read

The codebase assessment work made me articulate something I’d been doing instinctively for years. Every career opportunity I’ve had came from reading a system (technical, human, or market) and seeing something that the people inside it had stopped noticing.

Reading codebases

When I evaluate a repository, I’m not looking for bugs. I’m looking for patterns of decision-making embedded in the code. A codebase with three different HTTP clients isn’t a technical problem. It’s a signal that the team has no technical leadership, or that leadership changed hands multiple times, or that nobody owns the standards. The real remediation starts with understanding why three coexist, which is a people question dressed up as a technical one.

Hardcoded credentials in a tracked file aren’t just a security issue. They tell you that the team is moving faster than their process can support, which means other corners are being cut too, which means the real risk isn’t the credentials; it’s everything else you haven’t found yet.

I look at test coverage and see hiring strategy. A codebase with zero tests tells me the team either has no one senior enough to enforce testing discipline, or they’re under pressure that makes anything beyond shipping feel like a luxury. Both of those are business problems that will compound.

The technical findings are inputs. The career skill is the interpretation.

Reading teams

The mentoring work I described in Edition #6 taught me the same lesson from the human side. Miguel wanted coding exercises. Alexandre wanted shortcuts. Both were telling me, through what they asked for, something important about where they were and what they needed. But what they asked for and what they needed were different things.

This happens in every team I’ve worked with. A developer who constantly asks for code reviews on trivial changes is usually looking for reassurance about their position on the team, not about the code itself. A team lead who micromanages pull requests has often been burned by a production incident they didn’t catch, and the control is their way of processing it.

Reading a team means looking past what people do and understanding why they do it. The developer who can do this becomes the person others trust, the person who gets called into rooms where decisions happen, the person whose influence extends beyond their technical scope. And none of that shows up on a GitHub profile.

Reading markets

In 2005, I could see that web development was shifting from server-rendered pages to richer client-side experiences. That wasn’t a prediction. The signs were visible to anyone paying attention: broadband adoption, browser capabilities improving, user expectations rising. I invested in learning JavaScript deeply at a time when most backend developers dismissed it as a toy language.

That bet shaped the next decade of my career. Reading the present clearly enough to see where the pressure was building turned out to be more useful than any prediction could have been.

The AI shift follows the same pattern. The developers who are positioning themselves well right now aren’t the ones making bold predictions about what AI will or won’t do. They’re the ones watching closely: which tasks are AI handling reliably today? Which ones require human judgment every time? Where is the boundary moving, and how fast? The answers to those questions change how you invest your learning time, which changes where you end up in two years.

Why this skill is invisible

Developer culture celebrates the visible: commits, contributions, conference talks, blog posts, open-source projects. Career advice for developers focuses almost entirely on building visible artifacts: ship more projects, write more posts, contribute to open source, make your GitHub green.

These things aren’t useless. But they optimize for a signal that’s becoming less scarce (the ability to produce output) while ignoring the one that’s becoming more valuable: the ability to understand context. The gap between those two things is where the real career leverage lives.

The developers I’ve seen grow fastest, the ones who jumped from mid-level to staff in three years instead of eight, had one thing in common: they could walk into a situation and see what was actually going on. The client who says they need a rewrite actually needs better deployment. The product manager who keeps changing requirements hasn’t figured out the business model. The team that’s “slow” isn’t lazy; their architecture forces them to coordinate on every change.

Seeing these things didn’t require exceptional technical talent. It required paying attention to the systems around the code, not just the code itself.

The reason this skill stays invisible is that it doesn’t look like a skill. It looks like intuition, or experience, or “just knowing.” But it’s a practice, and you can start building it deliberately.

How to practice

The perception ladder isn’t something you climb by accumulating years. You climb it by changing what you pay attention to.

Start with the system you know best: your own codebase. Tomorrow, before you write any code, spend fifteen minutes reading it as if you were an outsider. Not debugging, not implementing. Reading. What does the structure of this project tell you about the team that built it? What decisions were made under pressure? What patterns reveal a change in direction? Where is the complexity, and why is it there?

Then extend the same practice to the people around you. In your next meeting, instead of focusing on the content being discussed, watch the dynamics. Who speaks? Who defers? Who gets interrupted? Who gets silence after they talk, the kind of silence that means people are actually thinking about what was said? The answers to these questions tell you more about how decisions actually get made in your organization than any org chart.

Finally, apply it to the market. Every week, read one thing that isn’t about your technology stack. A company’s earnings call summary. A product teardown by someone outside engineering. An industry analysis. You’re not trying to become a business analyst. You’re training the muscle that connects technical reality to business context, which is the muscle that makes your technical judgment valuable beyond the codebase.

None of this will show up on your CV. All of it will show up in every conversation, every decision, every moment where someone needs a developer who understands the bigger picture. And those moments are the ones that move careers.

Try This

The previous editions built a growing library of artifacts: a delegation map, a judgment breakdown, a problem statement, a decision analysis, an evaluation document, a mentoring reflection, a creative project brief. Each one externalized a different kind of thinking.

This week’s artifact is a system reading. Pick one of the three systems from this edition (your codebase, your team, or your market) and write a one-page assessment.

If you choose the codebase: don’t list technical problems. Write down what the code tells you about the business. What does the test coverage suggest about the team’s priorities? What does the architecture reveal about the product’s growth trajectory? What would you tell the CEO if they asked you, honestly, what shape their technology is in?

If you choose the team: write down the three unspoken rules that govern how decisions actually get made. Not the official process. The real one. Who has influence? Where does information flow, and where does it get stuck? What does the team avoid talking about?

If you choose the market: write down what you see changing in the demand for your type of work. Not what the headlines say. What you’re observing firsthand: in job postings, in client conversations, in the projects you’re being asked to work on. Where is the pressure shifting?

One page. Observations, not solutions. The point isn’t to fix anything this week. The point is to practice seeing what’s there, clearly, before jumping to action. That practice, repeated consistently, is what builds the perception that separates developers who grow from developers who stall.

The Deeper Cut

The codebase assessments I’ve been doing revealed something I didn’t expect about my own career. When I look back at every significant move (the health tech company that grew to 80,000 users, the search engine that unlocked thousands of users overnight, the travel tech architecture that processed over a billion dollars) the pattern is the same. I walked into a technical environment and saw a business problem that hadn’t been named. The technical work followed from the naming, and the naming is what created the value.

I used to think this was just experience accumulating passively. What the assessment work showed me is that it can be practiced deliberately. Every codebase I evaluate now sharpens the same skill: translating between what the technology is doing and what the business needs it to do. That translation is the career skill with the highest ceiling and the lowest competition, because almost nobody thinks of it as a skill at all.

Paid subscribers get the system reading template: a structured format for producing the kind of assessment described in this edition, applicable to codebases, teams, or markets. It includes the specific questions I use in client assessments, adapted so you can practice the same analysis on your own work environment.

🤖 Building with AI · For developers rethinking how they work.

This week’s challenge: pick something you’ve always wanted to build outside your expertise. Spend 30 minutes describing it to AI. Not asking AI to build it, just describing what you want. Notice where your clarity runs out.

I wanted to prove something. Everything I’ve written in this newsletter argues that thinking matters more than coding, but I’d only ever tested that claim inside software, where I already know what I’m doing. Easy to believe you’re winning because of your thinking when you also happen to have the technical skill to execute.

So I removed the skill. Deliberately. I picked two domains where I have zero technical ability, music production and game development, and tried to ship real products using nothing but AI for execution and my own thinking for everything else.

There’s a musician on Spotify right now that I created. I also built a fully playable strategy game. I don’t play any instrument, I’ve never composed anything, I don’t know game engines, and I’d never built a game in my life. It worked anyway.

What made it work was what has always made software work: the thinking. I already believed this. Every edition of this newsletter argues it. The experiment wasn’t to discover it. It was to prove it, in domains where I couldn’t cheat.

Building music without knowing music

A friend asked me not long ago what music I listen to during focused work. Every developer has an answer to this. Lo-fi beats, ambient soundscapes, classical, electronic. I told him I don’t listen to music, and haven’t in decades. He didn’t believe me. But it was true. I like heavy metal, I enjoy a few bands, and somewhere along the way I stopped engaging with music entirely. I’m a quiet person who thinks constantly, processes ideas through reflection rather than noise. Music was never part of that process.

That gap made me curious. And curiosity plus AI turned out to be enough to build something I never could have built alone.

I created an artist. His name is Magnus Jow. He’s on Spotify, and every one of his songs explores the cosmos, the universe, and scientific concepts expressed through poetry. He’s the artist I would have listened to if I’d ever found music that matched the way I think.

Here’s what I don’t know how to do: play an instrument, compose a melody, write lyrics that scan properly, arrange instruments into a coherent track, mix audio, produce a finished song. Every technical step in the music production process was beyond my ability.

Here’s what I did know: what I wanted to express. The themes. Cosmic, scientific, reflective. The feeling I wanted a track to carry. The difference between lyrics that captured an idea precisely and lyrics that sounded nice but said nothing. I knew the what and the why. I had no access to the how.

AI handled the how. It generated lyrics, melodies, instrumentation, vocals. Every technical layer of music production that I couldn’t perform, AI could. In theory, this should have been simple: describe what you want, get music back.

In practice, it demanded more from me than most software projects I’ve built.

The refinement was the real work

The first outputs weren’t right. They were competent, technically sound, sometimes even pleasant, but they didn’t match what I had in my head. The problem was never that AI couldn’t produce music. The problem was that I needed to figure out how to communicate what I wanted with enough precision for AI to get close, and then refine the gap between close and right.

Four dimensions needed to be solid before anything good came out:

The lyrics required cycles of generation, reading, filtering, injecting my own ideas, regenerating, reading again, cutting what felt wrong, sharpening what felt close. AI could write lyrics. I couldn’t. But I could read a verse and know immediately whether it carried the weight of the idea I was trying to express. That judgment, the ability to evaluate creative output against an internal standard I couldn’t articulate technically, was the entire contribution.

The music style needed definition that went beyond genre labels. Saying “ambient electronic” produced generic results. Describing the specific texture I wanted, the pace, the mood, how the sound should feel at different moments in the track, produced something closer. Every round of refinement taught me that the quality of the output depended entirely on the quality of my description.

The singer’s voice was a decision with consequences. The wrong voice made good lyrics feel hollow. The right voice made the same words land differently. This was a taste decision, not a technical one, and no amount of AI capability could substitute for knowing what I wanted to hear.

The album theme held everything together. Individual tracks needed to work on their own, but the album needed a coherent arc. That arc existed in my head before any music was produced. It was a product vision, the same kind of thinking I apply when designing a software system’s architecture, just expressed through sound instead of code.

Each of these dimensions went through multiple iterations before reaching a version I was willing to ship. The process looked exactly like the refinement loops I use in software development, except I couldn’t cheat by writing any of the implementation myself. Every version was produced by AI. My job was to evaluate, direct, and decide.

The pattern I recognized

Halfway through the album, I realized I’d seen this workflow before. The hardest software projects I’ve worked on were never the ones with the most complex code. They were the ones where the requirements were unclear, the stakeholder didn’t know what they wanted, and no one had taken the time to think through what the product actually needed to do.

When those pieces are solid, when the vision is clear, the requirements precise, the decisions made deliberately, the coding becomes the straightforward part. Difficult, sometimes. Creative, occasionally. But the execution follows from clarity. The thinking is where the real work lives.

I’d known this for years. But knowing it while you’re the one who can also write the code is different from knowing it when you can’t. Music stripped away the safety net. I couldn’t fix a bad track by jumping into the production layer, the way I might fix a bad feature by jumping into the code. All I had was my thinking: my vision, my taste, my ability to evaluate and direct.

And it was enough to ship an album.

Building a game without knowing game development

When I was a teenager, I played a Korean-made strategy game called Vital Device. Think StarCraft: you build bases, manage resources, command units in real time. This one had a biological sci-fi theme. Units that felt alive, organic structures, a world that was strange and specific enough to stick with me for decades.

I played the demo version because I couldn’t afford the full game. I spent countless hours in those limited missions, imagining what the rest of the game would be like. When I eventually had the money to buy it, the game had disappeared. Too old, too obscure, too hard to find.

I know StarCraft exists. I could buy it right now and play essentially the same genre. But I didn’t want the genre. I wanted that game. The specific one from my memory, with its particular aesthetic and the feeling it gave me as a teenager who couldn’t afford the full version.

So I rebuilt it. Using Claude, Gemini AI Studio, and a game engine I’d never opened before, I built a fully playable version of the game I’d been carrying in my head for over two decades.

Same pattern, different domain

I don’t know game engines. I don’t know game architecture. I don’t know how to build a strategy game from scratch. What I know is how to think about systems: what components need to exist, how they interact, what the user experience should feel like, where the complexity lives. Software architecture gave me a mental model for decomposing a game into buildable pieces, even though I’d never built a game before.

The same refinement cycle from the music project played out here. And the result was the same: the game is fully playable. Built by someone who had never made a game, using tools he’d never used, in an engine he’d never opened.

What building outside your domain reveals about building inside it

Here’s what I couldn’t see clearly until I left software: when you’re the person who can write the code, the execution and the thinking blur together. You move between them so fluidly that it’s hard to tell where the valuable work ends and the mechanical work begins. You might spend an hour on a problem and attribute the difficulty to the code, when the real difficulty was figuring out what the code needed to do.

The Portuguese word for this is desapego. Letting go. Letting go of the execution, of the identity tied to being the one who writes the code, of the comfort that comes from knowing you could always jump in and fix things at the implementation level.

When I removed that comfort, what remained was enough to ship. That’s the point.

Edition #4 covered the skills that don’t expire. This was the stress test. Every skill I used to ship music and a game was a skill I’d built through software, not through those domains. The domain-specific execution didn’t transfer, because it didn’t need to. AI handled that part.

The real lesson from Magnus Jow

There’s a personal dimension to this that goes beyond the professional argument.

I spent decades as someone who doesn’t engage with music. That was never a problem to solve. But creating Magnus Jow gave me access to something I didn’t know I was missing: a way to express ideas that don’t fit into technical writing, into newsletter essays, into the formats I’m comfortable with. The cosmic themes, the poetic framing of scientific concepts, that was a part of my thinking that had never found an outlet.

AI didn’t give me creativity I didn’t have. It gave me execution capability I didn’t have, which unlocked creativity that was already there. The ideas existed. The taste existed. The vision existed. What was missing was the craft, and for the first time in history, the craft can be delegated.

This is what I mean when I say developers need to rethink what they are. You are not your ability to write code. You are your ability to think about problems, envision solutions, evaluate results, and direct execution toward an outcome. The code was always just one medium. Now that AI can handle the medium, what’s left is you.

Try This

The exercises from previous editions built outward: a delegation map, a judgment breakdown, a problem statement, a decision analysis, an evaluation document, a mentoring reflection. This week, the exercise goes sideways.

Think of something you’ve always wanted to build that has nothing to do with your professional expertise. An illustrated book. A short film. A mobile app for a hobby you care about. A visual identity for a side project. Anything where you care about the outcome but you don’t have the technical skill to produce it.

Now spend 30 minutes describing that thing to an AI tool. Describe it in detail: what it should look like, how it should feel, what it needs to accomplish, who it’s for, what makes it different from existing versions. Write it as if you’re briefing someone who has every technical skill in the world but no understanding of your vision.

When you run out of things to say, look at what you wrote. The places where your description is precise are the areas where your thinking is clear. The places where you got vague, where you wrote something like “it should feel right” or “something cool,” are the areas where you haven’t done the thinking yet.

That gap between precision and vagueness is the same gap that exists in your software work. You’ve just never seen it this clearly because your technical ability fills in the blanks automatically. When you can’t fill them in, the gaps become visible.

Keep that description. If you want, use it. Start a project outside your expertise and see what transfers. Magnus Jow started as 30 minutes of description. He ended up on Spotify.

The Deeper Cut

The most counterintuitive discovery from these projects was that my taste improved as I created. I started with a vague sense of what I wanted and ended with a precise internal standard I didn’t know I was developing. Each round of evaluation, each moment of recognizing that an output wasn’t right, each decision to push further. All of it built a judgment muscle I couldn’t have trained by consuming music or playing games passively.

That’s the compound effect of building: you don’t just produce an output, you develop the ability to produce better outputs next time. This applies to software, to music, to games, and to every domain where the thinking matters more than the execution. The builders who start now, in any domain, will have a judgment advantage that passive consumers will never catch.

Paid subscribers get the creative project briefing template: a structured format for describing a non-technical project to AI, with specific prompts for vision, style, evaluation criteria, and refinement loops. It’s the same framework I used for both Magnus Jow and the game, adapted so you can apply it to whatever you’ve always wanted to build but never had the craft for.

🔧 Field Notes · 🧠 Mindset Shifts · From the field, no filters

This week’s challenge: find one moment this week where you followed instructions without questioning whether the instructions were right. Write down what question you should have asked instead.

This edition was the hardest to write.

I sat down, opened the doc, and tried to write about what I got wrong this month. That was the plan: a Field Notes edition about mistakes, vulnerability, the things I learned by getting it wrong. Honest and raw.

The problem is that nothing broke this month. The month was slow and incremental, without a single clear failure I could point to or a story with a satisfying turning point. The kind of progress that doesn’t make for a good opening paragraph.

I nearly forced it. Manufactured drama. Turned small things into big lessons so the edition would have the shape readers expect: conflict, insight, resolution.

Then I realized the forced shape was itself the thing worth writing about. Because the pressure I felt, the urge to package a month of quiet, grinding work into something clean and teachable, is the same pressure I’ve been fighting in a different context all month.

The pressure to turn thinking into steps.

Subscribe now

Two mentees, one pattern

I mentor several developers. Two of them taught me something important this month, the same lesson from completely different angles.

Miguel is entering the software development market. He’s early in the journey, building foundational skills, and I’m preparing him to work as a developer in the AI era. Not the era that’s coming. The one we’re already in.

Alexandre is an entrepreneur. Already running things, already dealing with real business pressure, trying to use AI to navigate situations that don’t have clean answers.

Different profiles, different goals, different stages. And both, in the same month, showed me the same thing: they wanted me to tell them exactly what to do.

Miguel’s version was subtle. I had a feeling he was expecting to practice the way every developer resource teaches: write code, solve coding challenges, follow a curriculum. He never said it directly, but the expectation was there, and it made sense, because that model is everywhere.

But that’s the model this whole newsletter argues against. So my job wasn’t to give him harder coding challenges. It was to create exercises where the code wasn’t the point, where he needed to think, question what the AI produced, identify what was missing, give context, connect documentation, push back. Exercises where the answer wasn’t in the syntax but in the judgment around it.

That took real energy to design. Any mentor can hand someone a list of coding challenges and move on. Building exercises that trained his mind instead of his muscle memory was a different kind of work

I found the way. It took more from me than I expected, but the exercises landed. Miguel started questioning AI output instead of accepting it. Started noticing gaps. That shift is worth more than a hundred solved algorithms.

Alexandre’s version was louder.

We entered into several deep discussions because I noticed a pattern: he was jumping steps. Consistently. He’d encounter a problem and reach for AI immediately, without sitting with the problem first. Without understanding it. Without refining what he was actually trying to solve.

The loop I kept pushing was: understand, question, refine, learn, then use AI. Build clarity before you build speed. Every time he skipped the understanding phase, the AI output looked useful but missed something fundamental, because he hadn’t given it (or himself) the context it needed.

He resisted this, and I needed real effort to understand why.

Why entrepreneurs skip the thinking

Alexandre wasn’t being lazy. He wasn’t ignoring the process because he didn’t care. He was ignoring it because of something deeper in how entrepreneurs operate.

I’ve worked with entrepreneurs before, across different industries and stages. There’s a pattern that shows up consistently: the idea is more motivating than the path. Entrepreneurs are energized by possibility. The vision of what could be, the optimism that this time it will work, the momentum of a new direction. That’s the fuel.

When you ask them to slow down, define the problem precisely, question their assumptions, refine their understanding before acting, that process feels like it’s killing the idea. The clarity they gain comes at the cost of the excitement that was driving them forward. And for someone like Alexandre, who has real financial pressure to accelerate, every hour spent on clarity feels like an hour not spent on results.

I get it. The pressure is real. But the Outcode Thinking program isn’t built for speed. Learning to think is a skill that takes time to absorb and develop. There are no shortcuts, because the shortcuts produce the exact problem the program is designed to solve: people who can follow instructions but can't figure out what to do when the instructions don't exist.

The conversation with Alexandre pushed me to articulate something I’d been feeling but hadn’t said clearly: the hardest part of this work is holding the line when the person you’re helping is uncomfortable. His discomfort wasn’t a sign that the process was wrong. It was a sign that the process was working, because it was forcing him into the part of thinking that he’d been skipping.

The tension that runs through everything

The thread connecting Miguel, Alexandre, and this edition is the same one that runs through the entire newsletter: the people who need to learn how to think are the same people who expect to be taught in steps.

This is the tension I underestimated when I started writing Outcode Thinking. Developer content has been tutorial-shaped for so long that the format itself carries expectations. A weekly newsletter from an experienced developer should give you frameworks, checklists, specific actions. Step one, step two, step three. Follow this and you’ll get there.

I feel that pull every week. The pressure to turn every edition into a tutorial. To give you five steps to evaluate AI output, three rules for better communication, a roadmap for career navigation. That format is comfortable. It’s familiar. It gets clicks and shares. And it completely misses the point, because the developers who follow those steps without understanding why they exist will be lost the moment they face a situation the steps don’t cover.

The irony is that this is exactly what I was fighting with Miguel and Alexandre. They wanted steps. I kept redirecting them toward thinking. And here I am, writing a newsletter, feeling the same pressure from the other side.

Every edition I’ve published has tried to balance this: enough structure that readers have something to apply, enough depth that the application requires their own judgment. Some editions landed that balance better than others. I’m still calibrating. This month made me realize that the calibration itself is the work, and there’s no final version where the tension disappears.

What the quiet month actually taught me

The month where nothing broke taught me more than a month full of dramatic failures would have. The lesson wasn’t in any single event. It was in the accumulation of small, difficult moments where the easy path was to give someone what they wanted instead of what they needed.

Every time Miguel wanted a coding exercise and I gave him a thinking exercise instead, I was choosing the harder thing. Every time Alexandre wanted to jump to AI and I pulled him back to the problem itself, I was choosing discomfort over speed. Every time I sat down to write this newsletter and resisted the urge to turn it into a listicle, I was making the same choice.

None of these moments felt like wins at the time. They felt like friction. The satisfying version of this month, the one where I could write a clean story about a mistake I made and a lesson I learned, didn’t happen. What happened instead was a month of holding positions that are easy to argue for in an essay and hard to hold in real life.

The developers who grow the most are the ones who can sit with the discomfort of not knowing what to do next and use that discomfort to think harder. I’ve written that sentence in different forms across five previous editions. This month, I had to practice it myself, not as a writer but as a mentor, over and over, with real people who were counting on me to help them.

The work of learning how to think is slow and uncomfortable and rarely produces a good story. That, maybe, is the most honest thing I’ve written in this newsletter so far.

Try This

The exercises from previous editions built external artifacts: a delegation map, a judgment breakdown, a learning target, a decision analysis, an evaluation document. This week, the exercise turns inward.

Think about the last time someone asked you for help. A colleague, a friend, someone you mentor. Think about what they asked for and what you gave them. Were those the same thing?

If you gave them exactly what they asked for, the answer, the solution, the step-by-step, ask yourself whether that was the right call. Sometimes it is. Sometimes people just need an answer. But sometimes the request for steps is a signal that the person hasn’t thought enough about the problem yet, and the most helpful thing you can do is redirect them toward the question they should be asking.

Write down one instance where you gave someone the answer when you should have helped them find it. And one instance where you held back the answer and helped them think instead. The comparison between those two moments will tell you something about your own defaults, whether you lean toward giving steps or building judgment.

If you’ve been collecting the artifacts from previous editions, this one connects directly to Edition #4 (the skills that don’t expire). The ability to teach thinking instead of giving answers is a skill that compounds, and it starts with noticing when you’re defaulting to the easier path.

The Deeper Cut

The moment I understood Alexandre’s resistance, something clicked about a broader pattern. The people who push back hardest against learning to think are often the ones who have the most to gain from it, because their instinct to move fast is strong, and the discipline to slow down and understand first would give them a leverage most of their competitors will never develop.

The entrepreneurs who learn to think before they act don’t move slower. They move fewer times in the wrong direction. And in a world where AI can execute faster than anyone, the quality of the thinking before the execution is the only real advantage left.

Paid subscribers get the mentoring reflection template: a format for reviewing your own teaching and mentoring interactions, designed to surface moments where you gave steps instead of building thinking. It’s the same practice I’m building into my own mentoring process after this month.

🤖 Building with AI · For developers rethinking how they work
This week’s challenge: take one piece of AI-generated output you accepted this week and find the assumption it made that you didn’t check.

Last month, my Slack agent had 269 passing tests. Every function worked. Every edge case I’d written a test for behaved correctly. The architecture was clean: dependency injection, separation of concerns, proper error handling. By every standard measure, the code was solid.

Then I used it for a week.

On the third day, I almost missed a critical conversation. A team member posted a question in a channel. The agent evaluated it, decided it didn’t need my attention, and moved on. Four hours later, three people had replied in that thread, one of them explicitly asking for my input. The agent never saw it. It had already dismissed the parent message, and it had no mechanism to re-evaluate a thread that grew after the initial assessment.

The code was correct. The tests passed. The tool still failed at its actual job: telling me what mattered.

That gap, between technically correct and functionally reliable, is where most developers stop paying attention. And it’s the gap where AI-generated work is most dangerous, because AI is exceptionally good at producing output that looks right.

Subscribe now

The confidence problem

When a junior developer writes bad code, you can usually tell. The naming is off. The structure feels uncertain. There are signs: hesitation marks in the logic, inconsistent patterns, the kind of roughness that signals someone is still learning.

AI doesn’t do this. AI-generated code arrives with the confidence of a senior developer and the context awareness of someone who just walked into the room. It uses the right design patterns, follows consistent naming conventions, handles error cases, and produces something that reads like it was written by someone who knew exactly what they were doing.

This is what makes evaluation hard. The surface quality is high enough to bypass the instinct that tells you to look more closely. You read it, it makes sense, the tests pass, and you move on. The failure modes are hiding underneath, in assumptions that were never stated because the AI doesn’t know they exist.

I’ve seen this play out the same way multiple times now. I asked AI to review a piece of my code, and it came back with an analysis I couldn’t fault technically. Bottlenecks identified with precision, race conditions flagged with clear explanations of why they were dangerous, each one accompanied by a solution I would have been impressed to see in a senior engineer’s review.

Then I asked a simple question: under what conditions would these bottlenecks actually occur? The answer, once I pressed, was almost never. The race condition required a concurrency pattern my application doesn’t use. The bottleneck would surface under loads I’ll never see.

If I had accepted the review at face value, my code would have become more complex, harder to maintain, and more difficult for the next developer (or AI) to read, all to prevent problems that had almost no chance of happening. Wtf!!?

That’s the pattern my Slack agent exposed too. The failure wasn’t in any function. It was in a model of reality the AI had no reason to doubt.

Three layers of evaluation

The developers who use AI well have learned to evaluate at three levels, and most stop at the first one.

Does it work?

This is where almost everyone starts and stops. Run it, test it, check the output. If it compiles and produces the expected result, move on.

This layer catches syntax errors, logic bugs, and obvious failures. It’s necessary and insufficient. My agent passed this layer completely. Every function did what it was supposed to do. The problem wasn’t in any individual function. It was in the architecture’s model of reality.

Does it fit?

This is the layer most developers skip. The question isn’t whether the code works in isolation but whether it works in the system it’s joining. Does it match the existing patterns? Does it make the same assumptions the rest of the codebase makes? Does it introduce a dependency that creates problems elsewhere?

AI-generated code frequently passes the first test and fails the second. It solves the problem you described while quietly ignoring the constraints you didn’t mention. You asked for a caching layer, and it built one with an in-memory store, which works perfectly until your application runs across multiple servers. You asked for input validation, and it added thorough checks that happen to duplicate validation already handled by the middleware. Nothing broke. Everything is subtly wrong.

The fix isn’t to prompt better. The fix is to evaluate differently. Before accepting any substantial piece of AI-generated code, ask: what does this assume about the context it’s operating in? Then check whether those assumptions hold.

Does it survive real use?

This is the layer that only shows up over time, and it’s the one where the most consequential failures hide. Real use introduces conditions that no spec anticipated because the people writing the spec didn’t know those conditions existed.

My keyword-based search is a good example. When the agent gathered context for a trigger message, it searched other channels by extracting the longest words from the topic summary and running text matches. This worked for obvious connections. If someone mentioned “deploy pipeline” in two channels, the keyword search found both. But when someone in the engineering channel said “the deploy pipeline is stuck” and someone in the incidents channel reported “CI/CD timeout affecting production,” the search missed the connection entirely. Same issue, different words. The most valuable cross-references, the ones that actually saved me time, were exactly the ones it couldn’t find.

No amount of testing would have caught this. It required using the tool on real conversations over real days and paying attention to what it wasn’t surfacing.

The evaluation habit

Developers I mentor complain about this constantly. Reading AI output is exhausting. Not the act of reading itself, but the mental effort of understanding what was generated, interpreting the decisions behind it, and thinking critically about whether it actually makes sense. It demands real cognitive energy, and they didn’t sign up for that. They wanted AI to make their work easier, not to add a new layer of intellectual labor on top of it.

I get it. But here’s the thing: in the past, we wrote the code ourselves. It took days, sometimes weeks. Now AI writes it in minutes and we just need to read and think about what we’re reading. The intellectual part is still ours. The choice is yours. Do you want to delegate everything to AI and do nothing, or do you want to be recognized for your intellectual work and be more productive than ever?

The first option sounds comfortable. Nobody will pay well for it. There’s no career path in being the person who clicks “accept” without reading. Your best option is to learn how to think and use AI. And that starts with how you evaluate.

So here’s what the practice actually looks like.

The first pass is immediate: does this output match what I asked for? Read it carefully, not to verify that it runs, but to understand what it’s actually doing. Look for the decisions the AI made that you didn’t ask for: the data structure it chose, the error handling strategy, the assumptions about inputs.

The second pass is contextual: does this belong here? You’re looking at a diff, in git, in a PR, in whatever tool you use to review what AI changed. The code difference is right there. But understanding whether that change makes sense requires context the diff doesn’t show: who is this feature for, what problem does it solve, what did the team decide three weeks ago that shaped how this part of the system works. The AI wrote code that addresses your prompt. Whether it addresses the actual need behind the prompt is a question only you can answer, and only if you understand the context well enough to ask it. This is the pass where experience matters most, and where junior developers need to be most deliberate.

The third pass is temporal: does this hold up in the real world? Most developers never do this one, because most developers stop thinking about their code the moment it’s merged. What happens in production is someone else’s problem. That mindset was already limiting before AI. Now it’s dangerous, because the volume of code you ship with AI is higher than ever, and each piece carries assumptions you may not have examined.

This pass requires a product mindset. You’re no longer asking whether the code works. You’re asking whether it solves the problem for the person using it, under the conditions they actually face. And that means doing something most developers never do: go back and check.

A week after you ship, look at how the feature is being used. Talk to the people using it. Read the support tickets. Check whether the assumptions you accepted during the code review actually held up in production. If you built a search feature, are people finding what they need? If you built a notification system, are the notifications reaching the right people at the right time, or are they creating noise?

Most developers do the first pass automatically. The second is where the real skill lives. The third is the one that turns a developer into someone who builds products, not just features.

What this means for your career

The developers who will be most valuable in the coming years are the ones who can evaluate AI output at all three layers. The code generation is becoming commodity. The ability to determine whether that code actually solves the right problem, in the right context, under real conditions. That’s a judgment skill, and it compounds with every project you apply it to.

This connects directly to what we covered in Edition #4: the skills that don’t expire are the ones AI can’t perform for you. Evaluation is one of them. AI can generate the code. AI can even generate tests for the code. But AI cannot determine whether the code’s model of reality matches your reality. That requires understanding the domain, the users, the constraints, and the history. In other words, it requires everything you accumulate by paying attention to your work over time.

The irony is that AI makes this skill both more important and harder to practice. When the output arrives looking polished and professional, the temptation to accept it without deep evaluation is strong. Every time you resist that temptation and look harder, you’re training the judgment that makes you irreplaceable.

Try This

If you’ve been following the previous editions, you’ve built a set of artifacts: a delegation map (Edition #1), a judgment-versus-execution breakdown (Edition #2), a problem statement and learning target (Edition #3), and a decision analysis (Edition #4). Each one built on the last.

This week, the exercise is different. Instead of building a new artifact, go back to something you built recently: a piece of code, a tool, a workflow where AI contributed substantially to the output.

Run it through the three layers from this edition.

Layer 1: Does it work? You probably already checked this. Confirm it anyway.

Layer 2: Does it fit? Look at the assumptions the AI made about the context. What conventions does your codebase follow that the AI didn’t know about? What constraints exist in your system that the AI wasn’t told about? Write down at least two assumptions the AI made that you never specified.

Layer 3: Does it survive real use? If the code has been running for a while, think about the edge cases you’ve encountered. If it hasn’t, imagine the real-world conditions it will face. What happens when the data isn’t clean? When the user behaves differently than expected? When the load changes? Write down one scenario the AI couldn’t have anticipated.

By the end, you should have a short document with two hidden assumptions and one untested scenario. That document is the beginning of an evaluation practice. Run this on every significant piece of AI output, and over time you’ll develop the instinct to spot these gaps before they become problems.

The exercises from previous editions gave you a map of your work, a target for automation, and a framework for decisions. This week adds the quality layer: the skill that determines whether what you build actually holds up when it matters.

The Deeper Cut

There’s a pattern I notice in every developer I mentor who starts building with AI seriously. At first, they evaluate too little: they accept output at face value because it looks professional. Then they overcorrect and evaluate too much, spending more time reviewing AI output than it would have taken to write it themselves. Both extremes miss the point.

The calibration happens through volume. The more AI output you evaluate critically, the faster your instinct develops for where the failures tend to hide. After enough reps, you stop reading every line with equal suspicion and start knowing where to look, which is usually in the assumptions, not the syntax.

Paid subscribers get the evaluation checklist: a structured tool for running the three-layer evaluation on any AI output, with specific prompts for each layer and a format for capturing what you find. It’s the same process I run on my own tools. It turns the thinking from this edition into a repeatable practice.

🧠 Career Navigation · For developers navigating the AI era.

This week’s challenge: pick one skill from this edition and notice once today where you used it on autopilot. That’s where the practice starts.

A few months ago, a junior developer sent me a message I’ve received in different forms at least a dozen times since.

“I’m learning X and Y and studying Z. Am I wasting my time? Will any of this matter in two years?”

I didn’t answer right away. I wanted to give him the right one, not the fast one.

The truth is, I’ve interviewed hundreds of developers over the years. The ones I remember, the ones I hired and kept, were almost never the ones with the most tools in their stack. They were the ones who, when I gave them a problem with no clear answer, could slow down, ask the right question, and find a direction.

That’s a skill. It doesn’t expire. It doesn’t get deprecated. And most developers are so busy learning the next framework that they never build it.

So here’s my answer, for him and for you.

Subscribe now

The skills that will matter in 2 years

If you ask me what made the most difference in my career across twenty years of building software, the honest answer tends to surprise people: communication.

Not the technical stack I mastered early. Not the architecture patterns I learned the hard way. Communication: the ability to express ideas clearly, understand what others actually mean, and move information between people without losing its meaning in transit.

The reason this surprises people is the same reason most developers spend years underestimating it: we assume we already have it. We’ve been communicating since we were children. We can write an email. We can explain what we’re working on in a standup. How hard can it be?

That assumption is expensive, and I held it myself for longer than I’d like to admit.

Communication is a practice, not a threshold you cross once. It degrades when you stop paying attention to it and compounds slowly when you do. Reading a book about it changes nothing unless you apply it consciously: in every message, every question, every meeting, every pull request comment. And it covers far more ground than speaking: it’s how you write a Slack message at 11pm when context is missing and someone needs to act on it, how you structure a document that people actually read instead of skim, how you ask a question that opens a conversation instead of shutting one down.

Most developers operate on autopilot across all of this. That’s where the gap lives, and where the biggest opportunity is hiding.

Two categories, two different futures

Everything a developer needs to grow falls into two categories with very different trajectories.

The first is technical skills: languages, frameworks, tools, platforms. These have always evolved, but AI is compressing the cycle dramatically. A specialization that would have stayed relevant for a decade now has a shorter shelf life. This doesn’t mean abandoning technical depth. It means being strategic about where you invest it. The durable bet in this category is foundations: system design, data structures, how distributed systems fail, how databases actually work under the hood. These don’t go out of fashion because every new tool is built on top of them. A developer who understands why a system degrades under load will adapt to any new infrastructure faster than someone who only knows how to configure the current one.

The second category is mental skills: the cognitive habits that make you better at any technical challenge, regardless of what the tools look like. Communication is one of them. The others are: how you make decisions, how you structure your thinking, how you protect your focus, how you ask questions, and how you think strategically. These don’t expire. They don’t get deprecated. Every year you invest in them, they compound. And with AI handling more of the execution layer, they become the primary differentiator between developers who thrive and those who plateau.

The rest of this edition is about those five.

How to make decisions

Making decisions seems straightforward until you realize what they actually cost. Every decision you make today removes options you could have had tomorrow. That invisible cost is what I call the marginal cost of decisions. Most developers never account for it.

Start by separating decisions by stakes. Some decisions have no real downside if you get them wrong: you can reverse them cheaply, learn quickly, and move on. For those, speed is the right optimization. But low and high-stakes decisions, the ones where you will lose something if you choose poorly, deserve a different kind of thinking.

For those, I use a structured approach: map the pros and cons explicitly, then spend time specifically on the cons. For each one, ask whether it can be diminished or removed through a different implementation, a phased rollout, a fallback mechanism, or a different sequencing of the work. The goal isn’t to eliminate cons, which is rarely possible, but to understand whether the pros genuinely outweigh them once you’ve accounted for the side effects.

This matters especially in product development, where decisions are rarely isolated. A feature decision affects architecture. An architecture decision affects hiring. A hiring decision affects what you can build next quarter. One choice can quietly close off an entire direction before you realize it’s gone. The developers who build lasting products aren’t the fastest decision-makers. They’re the ones who understand the downstream consequences before committing.

Without this kind of thinking, you’re not really deciding. You’re reacting. And the compounding costs of reactive decisions show up six months later as technical debt, misaligned product direction, and options you no longer have.

How to structure your thinking

A complex problem that stays in your head as a tangle of intuitions is still a complex problem. The act of structuring, deciding what’s the main point, what depends on what, what’s a cause and what’s a consequence, does something that pure mental effort can’t: it forces clarity.

The mechanism is simple but requires discipline. Before starting any non-trivial piece of work, write down three things: what problem this solves, what your approach is, and what could go wrong. Not as a formal document, but as a thinking exercise. The writing isn’t the deliverable. The clarity you arrive at before writing the first line of code is.

From there, practice hierarchy. Every idea has a level: there are top-level conclusions, the arguments that support them, and the evidence or examples that support those arguments. When your thinking feels tangled, ask yourself: am I confusing a conclusion with an argument? Am I treating an example as if it were a principle? Most mental confusion comes from mixing levels: treating a symptom as a cause, or a specific case as a general rule. Learning to separate them is a skill you build by doing it slowly and deliberately until it becomes instinctive.

This transfers everywhere: technical proposals, feature breakdowns, conversations where you need to bring someone else to your point of view. It also determines the quality of what you can build with AI. A developer who gives a well-structured brief will get dramatically better output, not because they’re better at prompting, but because they’ve already done the hard thinking before they typed a single word.

How to focus and go deep

The industry we’ve built rewards responsiveness. Slack notifications, standups, context switches, urgent messages. The average developer barely reaches genuine depth of focus before something pulls them back to the surface.

Deep work, the kind where you hold a complex problem in your head long enough to actually understand it, is becoming rarer exactly as it becomes more valuable. The shallow problems are being handled by automation. The ones worth solving require sustained attention.

The how starts with protection, not willpower. Block time in your calendar before the day fills with other people’s priorities. Communicate clearly when you’re unavailable. Treat a broken focus block the same way you’d treat a broken deployment: as something that needs a fix, not an inevitability.

But protection is only the first step. The deeper practice is building tolerance for the discomfort that comes at the start of deep work: the resistance, the urge to check something, the feeling that you should be responding somewhere. That discomfort is not a signal that something is wrong. It’s the threshold between surface-level thinking and the depth where real understanding lives. The practice is learning to recognize it as a threshold rather than an obstacle, and crossing it anyway. Repeatedly. Until crossing it becomes easier than avoiding it.

How to ask the right questions

A well-formed question is one of the most underrated skills in software development. But the goal isn’t to memorize a list of good questions, but to develop the capacity to generate the right question for any situation you haven’t seen before.

The mechanism behind a good question is always the same: you identify what’s being assumed and hasn’t been examined. Before asking anything, ask yourself: what does everyone in this conversation seem to take for granted? What would have to be false for this plan to fail? What are we not talking about that we should be? Those internal checks are the raw material. The question you ask out loud is just the output.

Years ago, I was in a meeting with an investor. He opened his notebook and showed me a single line he had written: “What haven’t we tried that we should try?”

That moment confused me at the time. I wasn’t prepared to understand what was happening. But what that investor was doing wasn’t asking a question. He was sharing a mental posture. A way of entering a situation with a deliberate blind spot detector. That question doesn’t ask for solutions. It asks for the shape of the unexplored space. It assumes that somewhere in the room there’s an untested path, and it creates the conditions for someone to name it.

That’s the quality a good question has. It doesn’t just request an answer. It shifts the frame of the conversation. And you can build that capacity by starting with one habit: before accepting any situation as fixed, ask what’s being treated as impossible that might not be.

How to think strategically

Most developers think at the level of the task. The best ones also think at the level of the system, the larger context in which the task exists, and the direction that context is moving.

The how is a practice of deliberate elevation. When you receive a task or face a decision, take thirty seconds to ask: why does this exist, and what does it move toward? Then go one level higher: what does the team or product need to be true in three months, and does this task contribute to that, or just to completion?

The second habit is consequence mapping. Before committing to any significant piece of work, ask: who else is affected by this decision that hasn’t been considered yet? What does this close off that we might want later? Strategic mistakes rarely feel like mistakes at the time. They feel like the obvious next step. The discipline is to pause long enough to look for what you can’t see from inside the immediate problem.

Over time, these two habits, elevating the question and mapping the consequences, become a mental reflex. You stop seeing tasks as isolated units and start seeing them as moves in a longer game. That shift is what separates developers who build things that matter from developers who build things that ship.

Where to start

These skills don’t come with completion certificates. There’s no course that teaches you to ask better questions. They develop through deliberate attention: noticing how you communicate, examining the decisions you make, protecting your focus, and treating every interaction as something worth doing consciously.

The reassuring part is that you already have the foundation. Every developer who has shipped real software, navigated team dynamics, and worked through real ambiguity has been exercising these skills, whether deliberately or not. The shift is simply to make the practice conscious.

That’s where the compounding begins.

Try This

If you’ve been following the previous editions and doing the exercises, you already have two artifacts: a map of tasks you’d delegate to five versions of yourself (Edition #1), and a breakdown of one of those tasks into judgment versus execution (Edition #2). Edition #3 asked you to identify one real problem in your work that no one is solving and write a single sentence describing it.

This week, take that problem and run it through the decision framework from this edition. Map the pros and cons of the most obvious solution. Spend twice as long on the cons as on the pros. For each con, ask whether it can be diminished, removed, or sequenced differently. Then ask: what am I assuming here that I haven’t examined?

These aren’t isolated exercises. Every artifact you’ve built across these editions is a compounding asset: a map of how you work, where your leverage is, and what you’re building toward. The goal was never practice for its own sake. It’s a system you’re assembling, one piece at a time, that will keep working for you long after you build it.

If this is your first edition, I’d encourage you to go back and do the Try This from editions #1, #2, and #3 before continuing. The exercises build on each other deliberately. Each one produces something you’ll use in the next. Starting here without that foundation means starting without the map. And the map is the point.

We’re scaling ourselves. That only compounds if the work accumulates.

The Deeper Cut

I’ve mentioned this before, but it’s worth saying clearly: I’m doing exactly what I’m asking you to do in the Try This sections. This is what walk the talk looks like.

From Edition #1, I analyzed my work week to understand where I could scale myself. The exercise produced a concrete list: over 3 hours a day reading and responding to messages from customers and colleagues, 2 hours on code review, 3 hours coding, 1 hour on architecture, and 2 hours creating content. Just writing it down made one thing obvious: the messaging block wasn’t just the biggest time sink. It was draining the energy I needed for everything else on the list.

From Edition #2, I picked that problem and broke it down into judgment versus execution. Most of the 3 hours was execution: retrieving context, piecing together what had already been said, figuring out who was asking and why. That breakdown made the target clear, and I built the Slack context retrieval agent directly from it.

From Edition #3, while working on the agent, I realized that identifying the gaps required recovering every decision and discussion that had shaped the build. Without that context, I couldn’t give AI a clear enough brief to help me think through the problems. That need produced the process log: a structured way to capture what was built, what was decided, and what actually happened. The process log then made the gaps visible, which led to the architecture decision: breaking the monolith into independent, composable agents.

Each edition produced an asset. Each asset made the next decision clearer.

The delegation map template, the format I used to produce the Edition #1 list, is available to all subscribers. Use it to map your own week. Run it regularly as your work changes.

Paid subscribers get the decision framework: the structured method for low and high-stakes decisions covered in this edition. The tool that turns the thinking in this edition into a practice you can apply to the next real decision you face.

The map shows you where your leverage is. The framework helps you move toward it without closing off the options you’ll need later.

🧠 Mindset Shifts · For developers rethinking how they grow This week’s challenge: separate what you learned from experience from what you learned from a checklist.

In 2005, becoming a developer was hard in ways that no longer exist, and easy in ways nobody remembers.

Hard because the resources weren’t there. Documentation was incomplete or outdated. There were no bootcamps, no polished YouTube channels walking you through every framework. Stack Overflow didn’t exist yet. If you got stuck, you read source code, asked on a mailing list, and waited. Learning was slow because the infrastructure for learning didn’t exist.

But it was easy too. The cognitive load was smaller. You didn’t need to learn twelve tools to get a job. The systems were simpler. The ecosystem was smaller. And most importantly, you had time. Time to absorb concepts gradually, build things, break them, understand why they broke. Time to develop intuition alongside knowledge.

Nobody called it a roadmap. You just built things and figured it out along the way.

Then the profession got popular.

Subscribe now

The hype wave changed who enters and how

Software development became one of the most talked-about career paths in the world. High salaries, remote work, the promise of building the future. It attracted millions. And for good reason. The demand was real.

But decades of accumulated knowledge can’t be compressed into a twelve-week bootcamp. The field needed developers faster than the field could train them. So the market adapted. Bootcamps, tutorials, roadmaps, certifications. Structured paths that promised: follow this, and you’ll get there.

And people followed. They completed the React roadmap. Checked off the JavaScript fundamentals playlist. Finished the full-stack bootcamp. Got the certificate.

Then they showed up to work.

What the roadmaps didn’t teach

The last few teams I trained revealed a pattern I keep seeing. Developers who could build a feature from a tutorial but froze when the problem didn’t match one. Developers who couldn’t resolve a merge conflict in Git — not because it’s difficult, but because no tutorial had walked them through what to do when things go wrong.

The worst version of this: developers who introduced massive complexity into simple problems. Not because the problem demanded it, but because the only approach they knew was the one they’d learned from a tool or framework. They had the vocabulary but not the understanding. They could use the abstraction but had no idea what was happening underneath.

The system shaped them this way. It optimized for output over understanding. The roadmap said “learn Docker,” so they learned Docker. It didn’t say “understand why Docker exists and when you shouldn’t use it.” So they didn’t.

The industry tolerated this

For years, the gap didn’t matter much. Demand was so high that companies hired anyone who could ship code, regardless of how deep their understanding went. Junior developers with surface-level skills found jobs because the market couldn’t afford to be selective. The shortage was real, and the business needed bodies.

That era is ending.

Companies didn’t raise the bar. AI did.

AI fills the gap and exposes it

Here’s the uncomfortable truth: every skill gap that tutorials created, AI can now cover. Can’t write a Docker config from scratch? AI can. Don’t understand what a merge conflict actually means? AI resolves it. Need boilerplate code for a new feature? AI generates it in seconds.

The developers who were trained to follow instructions now compete directly with a tool that follows instructions better than any human.

But the developers who learned to think — to understand systems, to question decisions, to see the problem behind the ticket — those developers aren’t competing with AI at all. They’re using it.

That’s the divide. And it was always there. The roadmaps just masked it.

The gap between learning and knowing

I’m not against structured learning. I’m against the illusion that structured learning is enough.

A developer who learned React from a roadmap knows how to create components, manage state, and call APIs. A developer who understands frontend development knows when React is the wrong choice. They can look at a project and say: “This doesn’t need a framework. A few pages of HTML and vanilla JavaScript will ship in half the time and be easier to maintain.”

That second developer earned it through building, mistakes, and judgment about what works.

A roadmap gives you vocabulary. Experience gives you fluency.

And fluency is what lets you see opportunities.

Opportunities come from problems, not from plans

Every meaningful career move I’ve made started the same way: I noticed a problem that nobody was solving, and I put myself in a position to solve it.

The health tech company from Edition #1 — the one that grew from 500 to 80,000 users and got acquired — didn’t happen because I followed a career roadmap. It happened because I looked at a struggling app and asked a question nobody else was asking: “Why isn’t this business growing?”

The Slack agent from Edition #2 didn’t come from a learning path about AI tools. It came from a daily frustration — wasting thirty minutes on context retrieval that should take thirty seconds — and the realization that I could build something to fix it.

Roadmaps tell you to learn Kubernetes. Opportunities show you that your team wastes four hours a week on manual deployment and maybe you should fix that. Kubernetes might or might not be the answer.

The difference is direction. Roadmaps point you toward skills. Opportunities point you toward outcomes. The best developers I’ve worked with always started with the outcome and worked backward to whatever skills they needed. They were always looking at the landscape. The developers who followed roadmaps were always looking at the checklist.

The skill that matters most now

The developers who will thrive aren’t the ones with the longest list of completed courses. They’re the ones who can look at an unfamiliar situation and figure out what to do.

That’s not a skill you can put on a roadmap. It’s a skill you develop by building, failing, questioning, and paying attention. By treating every project as a chance to understand something deeper, not just to add a bullet point to your resume.

AI makes this more urgent, not less. When AI can follow any set of instructions, the person who decides which instructions to follow becomes the most valuable one in the room.

The roadmap told you to learn. The opportunity is asking you to think.

Try This

If you didn’t do the exercises from the previous editions, go back and do them. Edition #1 asked you to list the tasks you’d delegate to five clones of yourself. Edition #2 asked you to pick one and break it into judgment versus execution. It sounds simple. Don’t underestimate it. Learning how to think is different from learning execution steps. This sequence is building that muscle.

If you did them, you have a list and a breakdown. This week, pick one execution task from that map — the kind where your time goes but your judgment doesn’t — and ask yourself:

What would I need to learn to build a tool that handles this for me?

Don’t look for a course. Don’t search for a roadmap. Look at the problem. What does it actually require? Maybe it’s an API you’ve never used. Maybe it’s a way to connect two tools you already have. Maybe it’s something simpler than you think.

Now notice: whatever you need to learn, it didn’t come from a syllabus. It came from a real problem that’s costing you real time.

By the end of this exercise, you should have one sentence written down: “I’m going to build [tool/automation] that solves [problem], and I need to learn [specific thing] to do it.”

And the solution isn’t just learning. It’s an asset. A tool, a workflow, an automation that keeps working after you build it.

This is how builders scale. They compound assets. Every solved problem becomes something that keeps working for them. Every problem you solve for yourself becomes something that works for you tomorrow, and the next day, and the next. The developers who figure this out early won’t just be faster. They’ll be operating at a different scale entirely.

Edition #1 gave you the map. Edition #2 gave you the target. This week, you start building toward it.

The Deeper Cut

The irony of roadmaps is that the people who create them usually didn’t follow one. They built things, noticed patterns, and wrote down what they learned. Then they published it as a sequence. And the sequence became a shortcut that strips out the most important part: the messy process of figuring it out yourself.

I use a tool for this. I call it a process log: a structured way to capture what I’m building, what decisions I’m making, and what I’m learning along the way. Not a journal. Not a retrospective. A living document that turns every build into a thinking artifact.

It’s how I wrote this edition. It’s how I built the Slack agent from Edition #2. Every building block I create starts as a process log before it becomes anything else.

I’m sharing the process log template as an artifact for all subscribers. Process Log Pattern.

Use it this week when you start working on your Try This exercise. Write down what you’re building, what you decided, and what surprised you. That document becomes proof that you’re thinking, not just executing.

Paid subscribers get the artifacts that go deeper — the actual tools, the AI agents, the decision frameworks, and the building blocks behind every edition. The process log shows you how to think through a build. The paid artifacts give you a head start on what to build.

🤖 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.

Subscribe now

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.

🧠 Mindset Shifts · For developers questioning their role in the AI era.
This week’s challenge: map out what five versions of you would do.

A few years ago, I was brought in to fix a search engine at a car-sharing startup. The problem was technical: performance issues that were costing the business real money. The kind of problem you’d find solutions for in any architecture book.

But books don’t ship software. The implementation demanded strategy, decisions, trade-offs. Two months of work, not writing clever code, but making hard choices about what to build, in what order, and what to leave alone.

Then the new version went live.

The next morning, the infrastructure team raised a red flag. Their monitoring dashboards showed a massive traffic spike, the kind that looks like an attack. They started incident response. Checked the logs. Checked the systems.

The system was fine. Responding faster than ever.

That traffic wasn’t an attack. It was thousands of real users who could finally use the search engine. They’d been there all along. The old system just couldn’t serve them.

No one on that team celebrated the architecture. No one mentioned the code. What mattered was that the thing worked, and a business could grow because of it.

That was the moment I stopped thinking of myself as someone who writes code. I was someone who builds things that make a difference. The code was just one tool in the process.

Subscribe now

You're not a coder anymore. You're a builder.

Ask a developer what they do and most of them will answer with a technology. “I write Python.” “I’m a React developer.” “I do backend in Go.”

Nobody outside of tech cares.

The business doesn’t care what language you write. The users don’t care about your architecture. The market doesn’t care how clean your code is. They care whether the thing works, whether it solves a real problem, and whether it can grow.

For decades, developers could ignore this. Code was a prerequisite to every business plan, good developers were hard to find, great ones even harder, and all of them were expensive. That scarcity gave developers leverage. The business needed you, even if you never understood what the business actually needed. You didn’t have to think about the product, the market, or the strategy. You just had to write the code. That was enough.

That era is ending. AI writes code now. It writes it fast, it writes it clean, and it doesn’t ask for a raise. If the only thing you bring to the table is the ability to translate requirements into functions, you’re competing with a tool that does it cheaper and faster every month.

So what’s left?

Building.

And building is a fundamentally different skill than coding.

The coder vs. the builder

A coder receives a ticket and writes the implementation. A builder asks why the ticket exists and whether it should exist at all.

A coder solves the technical problem in front of them. A builder solves the business problem behind it.

A coder measures success by whether the code works. A builder measures success by whether the outcome changed.

This isn’t about seniority or job titles. I’ve met junior developers who think like builders and staff engineers who’ve spent a decade thinking like coders. It’s a posture, not a promotion.

Own the problem, not just the implementation

Early in my career, I worked with a health tech company. Their mobile app helped people manage diabetes. Noble mission, genuine impact on people’s lives. But the business was struggling. Around 500 users. No investor wanted to come in.

The app had real problems. Technically, it was rough. The obvious move was to fix the bugs, improve performance, ship a better version of what already existed.

But that wasn’t the actual problem. The actual problem was that nobody had asked the right questions. What do these users really need? What does the market look like? Where does the money come from?

We spent a year rebuilding the application around those answers instead of around the technical debt. The company grew to 80,000 users, found a revenue model through the pharmaceutical industry, and three years later was acquired for $22 million.

The code mattered. But the decisions about what to build mattered more. A coder would have fixed the bugs. A builder asked why the business wasn’t growing.

Make the hard decisions

At a retail startup, I inherited a situation that looked familiar: the platform couldn’t scale, technical issues everywhere, business growing faster than the technology could support.

The previous CTO had attacked this the way most technical leaders do. He split the monolith into microservices. Some problems got solved. New ones appeared. Without a proper technical team, the complexity multiplied. The business kept expanding into new countries while the technology kept falling behind.

More code didn’t fix it. More architecture didn’t fix it. The fix started with something that had nothing to do with code: understanding every business need, building the right team under the right culture, creating a plan that aligned technology with where the company was actually going.

The hardest part of that job wasn’t any technical decision. It was convincing smart people that the solution to a technology problem doesn’t always start with technology.

Coders add more code. Builders step back and ask what the system actually needs, even when the answer isn’t technical.

Build for what the business actually needs

I designed the architecture for a billing and booking system at a travel tech startup. The system handled payments, reservations, the operational backbone of the business.

The temptation was to build it right. Elegant abstractions, clean separation of concerns, a beautiful system.

But “right” didn’t matter. What mattered was speed. The business needed to replicate in new countries fast and then scale to millions of users. The architecture had to make it trivially easy to add payment options and booking flows for different markets, not technically impressive, but operationally fast.

Today that system processes over a billion dollars in transactions. Not because the code was brilliant, but because the decisions behind the code matched what the business needed to do.

Two years later, a car-sharing startup recruited me to do something similar with their search engine. They didn’t hire me for my code. They hired me because I’d solved that kind of problem before and understood the decisions involved.

That’s the builder’s career path. You don’t get hired for what you can type. You get hired for what you can figure out.

Why this matters right now

Every story I just told happened before AI could write production-ready code. In every case, the code was already the easy part. The hard part was understanding the problem, making the right decisions, and building something that actually moved a business forward.

Now remove the code entirely. AI handles it. What’s left?

Everything that mattered.

The developers who will thrive aren’t the ones who can write the best code. They’re the ones who can look at a messy situation with no clear answer and build something that works. Own the problem. Make hard decisions. Understand what the business actually needs.

That’s a builder. And that’s what I’d challenge you to become.

Try This

Here’s a thought exercise for this week. No code, no tools. Just thinking.

Imagine you could clone yourself five times. Five versions of you, ready to work. What would you delegate? What tasks eat your time every day that another you could handle if you gave them the right instructions?

Write it down. Be specific. Not “help me code faster.” Think about it like you’re onboarding a real person: what would they need to know? What decisions can they make on their own? What needs your approval?

Now look at that list. That’s your map.

Every task you can describe clearly enough to delegate to a human, you can build a tool for. Every task that needs your judgment, your taste, your understanding of the problem: that’s where the builder lives.

You don’t need to build anything yet. Just the list. Just the thinking.

Next week, we start building.

The Deeper Cut

I’m doing this exercise myself. Right now.

I’m mapping out the tools I need so that at least five versions of me are working at the same time. Tools that research, that draft, that evaluate, that organize, that handle the parts of my work that don’t need my judgment every time.

Outcode Thinking isn’t just a newsletter I’m writing for you. It’s my journey too. Every tool I build, every artifact I create, every workflow I figure out along the way, I’m sharing with paid subscribers. Not theory. The actual tools, ready to use, ready to help you scale yourself the same way I’m scaling myself.

We’re entering the age where a single developer with the right tools can do the work of a team. The builders who figure this out first will have an unfair advantage. I intend to be one of them. Paid subscribers get to build that advantage with me.

The old model is dead. Here's what replaces it.

For decades, the developer's value was tied to a simple equation: you know how to write code, the business doesn't, so they need you. The scarcer the skill, the higher the pay. That's why companies invested millions trying to remove developers from the process, and why every attempt failed. The gap between "I have an idea" and "I have working software" was too wide for anyone but a developer to cross.

AI closed that gap overnight.

This isn't speculation. It's already happening. People with no programming background are shipping products. The code barrier, the thing that protected our careers for decades, is dissolving. And if your entire identity as a developer is "I write code," you have a problem.

But here's what I've learned after 20+ years of surviving industry shifts: every time a technical skill gets commoditized, the people who thrive are the ones who were never defined by that skill alone. They were defined by how they think.

What thinking actually means

I'm not talking about "computational thinking" or whatever CS courses sell you. I'm talking about the ability to look at a messy, ambiguous situation and make good decisions. To ask the right questions before writing a single line. To understand *why* something should be built before figuring out *how*.

Most developers never develop this muscle. They follow tutorials, complete roadmaps, memorize syntax, and wait for someone to hand them a ticket. That worked when writing code was the hard part. It doesn't work when AI can write the code for you.

The developers who will matter are the ones who can:

See the product, not just the feature. Understanding what you're building and why it matters to someone is no longer optional. When AI handles implementation, the person who understands the problem becomes more valuable than the person who understands the language.

Use AI as a power tool, not a magic trick. AI doesn't replace thinking. It amplifies it. The developers getting the best results aren't the ones writing the cleverest prompts. They're the ones who know what good output looks like, can spot what's wrong, and iterate with intention. That requires experience, taste, and judgment. Things you can't copy from a tutorial.

Navigate uncertainty instead of following roadmaps. The industry changes too fast for any roadmap to survive. The developers who stay relevant are the ones who read the landscape, spot opportunities, and adapt. Not the ones who follow a checklist someone else made three years ago.

Learn from what actually happens, not from what should happen. Theory is everywhere. What's rare is someone willing to share what they tried, what broke, and what they actually learned. The best developers I've worked with all share this trait: they treat every project as a feedback loop, not a finished product.

This is what Outcode Thinking is about.

It's a weekly newsletter built around one belief: the developers who will thrive in the AI era are the ones who learn to think, not just code.

Every week, I'll share one deep-dive across four pillars:

Mindset Shifts. How to think strategically, develop product vision, and make better decisions. The mental operating system of the modern developer.

Building with AI. How to actually build with AI as a core tool. Not prompt engineering tricks. Real workflows, real evaluation, real iteration.

Career Navigation. What's changing, what remains valuable, and how to position yourself for what's coming.

Field Notes. Real experiences from my own work. What I'm doing, what I'm learning, and what I'm getting wrong. No filters.

This is Edition #0.

If anything here resonated, you felt it for a reason. The shift is already happening, and the developers who move first will define what comes next.