The question isn’t “is this worth building?” anymore. It’s just “would this be helpful?”

I keep wondering what happens when it’s not just developers asking that question - when the teacher, small business owner, the hobbyist with zero coding background gets there too.

I wanted that to be true and I still do. But wanting it raised a harder question: has anything like this ever actually worked?

The promise is the same but the packaging has changed. No-code was going to let everyone build software. YouTube was going to make everyone a handyman, a mechanic, a home chef. Now AI agents are going to democratize coding. Each time the assumption is the same: the barrier was access and now we’ve solved access.

But access was never the barrier.

No-code didn’t deliver not because the tools were bad but because most people don’t wake up wanting to build solutions. They wake up wanting problems to go away. Those are very different things. The itch to decompose a problem, deeply understand it, model it, and construct a fix is not a skill gap, it’s a disposition. You can’t instill a disposition with a better user experience.

YouTube proved this unintentionally. You can learn to do almost anything from your couch if you find the right channels. More people can now handle a leaky faucet or patch drywall but contractors remain booked out months ahead and the trades aren’t exactly struggling. While YouTube raised the floor slightly, the moment a fix reveals a bigger problem underneath, the video gets paused and the phone comes out. Access to information never moved the ceiling because information was never what was missing.

The parallel to AI coding is almost exact. I can imagine a world where AI handles the equivalent of “leaky faucet” software problems - simple automations, one-off tools, basic scripts. Maybe that happens. But real software problems, like real home repair problems, tend to be more complicated than they first appeared. And at that moment you need judgment, not a better tool.

This is the uncomfortable truth about automation - it doesn’t lower the skill requirement, it raises it. Autopilot didn’t make flying accessible to non-pilots. It made piloting more cognitively demanding because now you need enough mastery to know when the automation is wrong and how to take over when it fails. AI coding tools are likely the same. They’re a force multiplier for people who already think in systems. For everyone else, they’re autopilot controls with no pilot behind them.

So software engineering isn’t going anywhere. The job might look different - more directing, less typing - but the underlying skill of knowing what to build, why and how to tell when it’s broken is not getting automated away. It’s getting more important.

The people who will genuinely benefit from AI coding tools are probably the same people who were already a little bit in the direction of building things. The curious hobbyist who always bounced off the learning curve. The person with the itch but not the stamina or time for the old on-ramp. That’s a real population worth being excited about, it’s just not everyone. It was never going to be everyone.

Think about the woodworker who goes full time. They didn’t get there because YouTube lowered the barrier to entry. They got there because they already had the obsession, YouTube just helped them go deeper and faster. The tool served the itch, it didn’t create it.

The same is true for the developer who bootstraps a product using AI. AI didn’t give them the entrepreneurial drive or the systems thinking. It compressed the timeline between “I have an idea” and “I have a working thing.” The itch was already there.

So when the teacher or small business owner or the hobbyist with zero coding background does get there it won’t be because AI handed them a new capability. It’ll be because they already had an itch and AI gave them an on-ramp that didn’t dead-end on them.

That’s still worth being excited about, it’s just a smaller and more honest version of the dream.

Subscribe now

They’re a familiar type - not big enough to justify hiring someone. Not generic enough for an existing tool. Not quite small enough for me to get functional enough before I run out of time or motivation. Just this specific, frustrating little gap between “what software exists” and “what I actually need right now.” (with a dash of “what do I have time to accomplish” on top)

I used to file these away in a 10+ year-old, 20+ page long Google Doc called “Project List.” Now I just build them on my way out the door.

My sons both love doing math worksheets and puzzles like crosswords and wordsearches. I can’t explain it but I’m smart enough not to question it. I’d generate math problems for them by hand from time to time and we’d buy wordsearch books that they’d blast through in an afternoon. I got tired of those loops so I built a generator using Claude Code.

It’s a simple site: pick a grade level, pick a type (addition, decimal math, wordsearch, etc.), set how many problems you want and print. Every refresh randomizes the content. It cost me maybe an hour one afternoon and I’ve printed dozens of sheets from it.

Before AI-assisted building, that would’ve been a weekend project - maybe longer if I got stuck trying to optimize the wordsearch generator. Now it’s the kind of thing I can prototype before lunch and polish after they go to bed.

This morning’s example was a bit more ambitious, but took no additional effort on my part: a planning app for IKEA hackers.

If you’ve spent any time in that community, you know the vibe - people turning flat-pack furniture and some trim into DIY built-in custom storage solutions, entertainment centers, etc. that looks like it cost ten times what it did. It’s genuinely clever but the planning process can be fidgety and IKEA’s room planner is pretty clearly not designed with this use case in mind.

So I used Claude Code to build a web app that knows the dimension of various cabinets, shelving units, countertops, etc. You set your room dimensions and it visualizes your space in 3D. Then you drag and drop IKEA pieces into it until you’ve got something you love. You can even customize the dimensions of countertops for a custom fit.

That’s it. That’s the whole app.

These two projects couldn’t be more different. One is for elementary school kids practicing basic math and doing puzzles. The other is for someone planning a built-in wall unit. But they came from exactly the same place: a specific, real need that no existing tool (or at least no existing tool that wasn’t an ad-burdened sloppy mess) was solving.

This is biggest thing I find genuinely exciting about AI-assisted building right now: the activation energy for solving a problem has collapsed.

The solutions I’m building aren’t works of art. They’re not scalable SaaS products. They’re not going to make anyone rich. They’re just useful. Specifically, narrowly, perfectly useful for one particular situation. One-offs that would’ve been impractical to build before but are totally reasonable to build now.

The question isn’t “is this worth building?” anymore. It’s just “would this be helpful?”

If the answer is yes, you can have it in minutes. I keep wondering what happens when it’s not just developers asking that question - when the teacher, small business owner, the hobbyist with zero coding background gets there too.

I don’t think this changes what software is, exactly. But it changes who gets to have it and for what. The long tail of problems that were previously too small to justify custom solutions is suddenly, quietly, becoming solvable.

Which means the worksheet your kid wants, or the IKEA hack you’ve been mulling for weeks? There’s an app for that now. You just have to ask for it.

What it doesn’t show (and has never shown) is the why. The approaches considered and rejected. The thing the author almost did before anticipating a roadblock. The question they never thought to ask.

That gap has always existed. In the AI-assisted development era, that gap becomes a lot more consequential.

Coding agents help engineers write code and other agents help review it, but there’s a third dynamic we’re not yet leveraging properly: the transcript of the session between the original engineer and the coding agent.

That transcript is the journey the engineer took to arrive at the destination (the PR) and almost none of it is visible to the code review process today.

Here’s what might change if an agent was able to review it.

For the author, the most immediate win is a PR description that’s more useful. Less “what changed” but “what I tried, what I rejected and why I landed here.” That’s context every reviewer wishes was available but almost never is. It’s tedious as a PR author to write out that narrative when you’re 5 feet from the finish line of your current task. With a coding agent transcript, that story has already been captured for you.

Even before the PR is created, a transcript-review agent could provide an early feedback pass before the PR lands in a human’s lap. “You implemented the happy path quite thoroughly, but haven’t addressed what happens if this external dependency gets flaky.” That’s a PR reviewer comment that didn’t need to get written.

For reviewers, the biggest win is attention calibration. Right now, reviewers reverse engineer intent based on diffs. A transcript-aware review brief flips that: here’s what the author was trying to do, here’s what they considered, here’s an area to focus. More importantly: here’s code that was edited but never discussed. “There was no record of reasoning about this inherently tricky section of code by either the author or their coding agent.”

There’s also a more subtle dynamic: trust. Was the code accepted wholesale from the agent, or did the author push back, ask questions and iterate? That’s not a visible quality of a PR today.

At the org level, the signal compounds. If a dozen engineers are having long, back-and-forth, confusing sessions with coding agents about particular modules or features that’s a crystal clear signal of which parts of your codebase are difficult to reason about and likely hurting your engineers’ productivity.

The indirect effect is the one I find interesting. How does knowing your transcript is reviewable change how you co-create code with a coding agent? Do developers ask better questions, push back more, and explore more edge cases when they know their journey is going to be reviewed as well? Legibility might be a surprisingly quiet lever on agentic engineering craft.

That question immediately raises a harder one: is this just surveillance? Maybe. But there’s a meaningful difference between reviewing transcripts to evaluate engineers and reviewing them to evaluate code. Keep the output focused on quality and reviewer efficiency, not on grading how someone prompted, and the dynamic shifts considerably.

That framing doesn’t eliminate the tensions. Knowing your transcript is visible could still discourage “dumb” questions, compress exploration, or encourage a kind of prompt theater. Those are real risks and while none of them are fatal, they’re worth designing around deliberately.

The main takeaway is this: as AI continues to change how we build software, the artifacts that matter in development will change as well. The diff is still important, but the transcript behind it might be more important - and right now, we’re just throwing it away.

P.S. The same agents already helping developers write and review code are the natural candidates for transcript review. The infrastructure is already there. The question is whether engineering teams start treating the transcript as a first-class artifact - or keep discarding the most honest record of how the work actually got done.

This is an approximate replay of the chat with Gemini (Nano Banana).

NB: Gemini mistook a window relocation in the drawing for a double window. I didn’t bother correcting it at the time since we were focused on colors mostly. It also wasn’t sure whether the chimney existed or not.

Create a realistic 3d render of this front elevation. use white for the horizontal and vertical siding, dark grey for the roof, and a mix of brown river stone for the stone veneer

oh right, shutters.

make the shutters black and the front door a dark red

seeing the house in 3D makes it so much easier to think about design choices. and, we didn’t need to go back and forth with a designer or architect to iterate quickly on it

make the siding forest green

meh

try sage green instead

not bad… not sure we like that better than white. not sure about the stone

generate a grid of different stone options that would work with the sage green siding

I thought this was pretty clever - it understood the value in having a siding sample alongside stone veneer options. Would’ve been even more impressive if it weaved the siding in between each row and column of stone options…

recreate this stone comparison grid but have the herringbone color siding run in between each row and column of the stone grid

close enough… we’re now leaning back towards something close to white for the siding and probably a fieldstone for the veneer. let’s try some out

now go back to the house render, give me a grid of 6 different shades of white or near white colors for the siding. stick with the type of stone in this image for the stone veneer

pretty handy - we’re narrowing in on what type of white we like. still not sure about the stone

generate a bunch of stone veneer options that go with this white siding color

now we’re thinking about how much of this stone is going to be visible once we do landscaping…

add some landscaping

wow! it seemed to understand the placement of various heights of bushes. the shadows are a nice touch. bit odd that it decided our house should have a front walkway but can’t say we dislike the look. let’s get a closer view

generate a larger version of the top right render in the grid - no landscaping straight out from the front door

nice…

a dedicated block of time set aside for uninterrupted task-based work.

If you do knowledge work, you’re constantly reminded of the importance of focus time. Companies schedule recurring “focus days”, discouraging employees from scheduling meetings so everyone can maintain heads-down focused execution. YouTube is overflowing with productivity influencers offering 15 steps to improve your focus, pomodoro timer routines, distraction blocking apps and 4 hour instrumental tracks that improve your concentration. The Workspace version of Google Calendar even has a special event type called “focus time.”

If you’re struggling to get your day-to-day functional work done, investing in focus time is a good idea. Seriously. Go do it, I’ll wait.

Once you’re nailing the day to day, you might think “Focus time is really helping! Give me more!” Here’s where I think it’s easy to get tripped up. An over-investment in focus time could be preventing you from doing your best work.

Equally important is making space for noodling (a.k.a. incubation time).

to improvise, experiment, or think creatively.

Noodling, in this context, is deliberate wandering of the mind. You don’t have a specific task you’re trying to complete or a specific tactical decision you’re trying to make. You’re letting your mind wander from one topic to the next, while potentially injecting new ideas through reading or listening. (I find encountering new ideas helpful but I’m not convinced it is necessary for effective noodling.)

Think of noodling as reflective daydreaming. Take yourself out of focused, heads-down execution and let your mind play with ideas loosely. You’re reframing problems, making odd connections and discovering simpler solutions you’d miss in focus mode.

Noodling reduces your inertia towards the first solution available and boosts originality by inviting more inputs and weak signals. You’ll discover ideas you can’t brute-force, clarify priorities and create cleaner designs - small investments that compound into better impact.

During these moments, it helps to incorporate undemanding, low-stakes activities such as walking, simple chores or, my favorite, cutting the grass. It also helps to separate from digital distractions - step away from your phone and computer.

My most reliable noodling time is cutting the grass for an hour or two each week while listening to podcasts or audiobooks tangentially related to the problems swirling in my head. The grass requires just enough of my attention while leaving plenty of bandwidth for listening & mind wandering. I seek out content that’s likely to introduce me to new ideas or new ways of thinking about things. (Night Science is one of my recent favorites.) I let my mind freely bounce between paying attention to what I’m hearing and getting lost in thought while the audio plays in the background.

Noodling matters because truly creative breakthroughs rarely happen intentionally. I make the most meaningful progress on the complex, sticky or strategic challenges when I revisit them during one or more noodling sessions.

Functionally, my noodling results in a few quickly captured notes, just enough to capture the spark of an idea along any potential shortcomings I’ve identified early. I’ll then dedicate an upcoming focus time block to dig in and see if the idea has legs.

As with anything, success is about finding the right balance - in this case, a balance in how you spend your time. Don’t crowd out all of your creative potential by over-investing in the focused & tactical. Go for a walk, cut your grass, fold the laundry, encounter a few new ideas and see what you come up with.

P.S. You can greatly increase the quality of your noodling by learning and practicing a few critical thinking techniques. They’ll help you gain a deeper and broader understanding of challenges and evaluate new ideas. (Ask your neighborhood LLM to help you learn and practice creative thinking techniques.)

Itai, Martin and Uri discussed the concept of Pareto efficiency and how Uri recommends scientists use the Pareto front principle of optimization theory to help them decide which problems to focus on. Uri thoroughly describes the approach in this paper, but I’ll try to give a concise overview here and suggest how I think engineers might benefit from adoption.

In short, plot your potential projects along two axis - Potential Impact and Level of Effort / Complexity. Once you’ve finished plotting your options, eliminate any projects for which there are other projects with better ratings on both axis.

Next, consider the quadrants your projects inhabit:

• Time Fillers - Low Impact, Low Effort/Complexity

• Thankless Struggles - Low Impact, High Effort/Complexity

• Quick Wins - High Impact, Low Effort/Complexity

• Major Endeavors - High Impact, High Effort/Complexity

Depending on your situation (time constraints, growth goals, workload, etc.), you might choose to focus on a specific quadrant (likely something other than Low Impact, High Effort/Complexity unless you’re a glutton for struggle).

If you don’t have much time to dedicate to the project and want results soon, you’ll focus on Low Effort/Complexity with the Highest Impact possible. On the other hand, if you’re longing for a meaty challenge that’ll generate headlines if successful, you’d focus on High Impact, High Effort/Complexity.

This intuitive approach could be leveraged by Software Engineers (or teams of them) deciding how best to invest their time and attention. An engineer early in their career might focus on Low Effort/Complexity as they practice delivering solutions independently. A more senior engineer looking to build a track record for promotion might want to choose amongst a variety of High Impact, High Effort/Complexity projects.

To encourage folks to play with this approach I put together this rudimentary app (in less than 5 minutes using Claude Code). Enter your projects with their ratings and then click Analyze Projects to see your scatter plot, quadrant summaries and recommendations of Pareto Efficient choices.