For writers, tools like ChatGPT hold a special place in hell.

They’re just so damn effective. They make your writing glossy, synthetic, shiny. Impossible not to use.

But then you read someone else’s post, another LinkedIn update, a new Substack piece, and you can’t tell them apart.

They all use the same perfectly impactful prose and workshopped line lengths.

It’s so… over-produced. Frictionless. Perfectly optimized for a target audience of nobody.

And thats the irony: for something called Generative AI, it should help us generate something living! But somehow everything it touches takes on a plasticky sheen. Every sentence reads like an old-timey Transatlantic Hollywood narrator: polished, pleasant, and perfectly neutral. The kind of tone that erases the person behind it.

We tell ourselves we use these tools to write better, but really we want to sound more likable, more marketable, more perfect. The problem is that none of that makes us interesting. Chasing perfection leaves us with nothing.

I’d like to say I caught myself before falling into that trap. I didn’t.

Share

In the back of my head I’ve always thought that there was a “better” version of my writing: a version with smoother prose and bigger, cleverer words.. But after working with ChatGPT I realize now that a lot of what I find interesting about my writing are these individualistic quirks. I tell too many stupid pop-culture jokes to be a serious technical publication. I mix philosophy and personal productivity with random Python code that no one will ever run. (If you ever meet me in real life I promise I do the same thing.)

When I hand my drafts to ChatGPT, it does what it does best: sands every edge down to a Substack appropriate sheen.

Only later did I realize the rough edges, the tangents, the jokes, the weird tone shifts, were me. The thing I was sanding down was my own fingerprint.

And this isn’t just a writing problem. It’s a human problem. Every time we smooth over our rough edges, in writing, in work, in interviews, we lose the very thing that makes us authentic. It’s the same impulse that makes us rewrite a Slack message five times so it sounds “friendly but professional.” We think we’re improving, but really we’re erasing the parts that allow people to relate with us.

The polish makes us easier to work with.

Nowhere did I feel this tension more than when prepping for behavioral interviews. We can argue about details, but at least the typical LeetCode and System Design interviews have a right or wrong answer, right? You shouldn’t write backend servers in JavaScript, no matter what flavor you use. There. I said it.

But behavioral interviews test a different, interpersonal skill set. They test how well you understand the constraints that you’re actually working under. The nitty gritty of the team itself, not just the work. Sure, everybody has a story about that one porcupine product manager, or the five alarm fire only we knew how to defuse. But in a stressful environment like an interview, it can be difficult to get all of the details out. Given the big help that ChatGPT gave me when prepping for LeetCode and System Design interviews, I was expecting similar results. And, just like the Genie from Aladdin, it delivered. Just not in the way I expected.

One by one, I shotgunned personal stories from an earlier dev team into ChatGPT. All the late night on-call issues, the heated discussions with other devs, the little wins that made me proud. (And would you believe that I can talk for a long time about software?) Then I asked it to help me reformat everything into the STAR method for storytelling in these interviews.

What came back for one of those stories was… perfect.

Four neat lines that could have described any software developer.

Two months of my life, the early morning meetings, the late night debugging sessions, the weekend migrations, all compressed into four short lines of text. It was the perfect behavioral answer: structured, safe, and completely lifeless.

All that passion and joy and stress and emotion had been polished until the grain vanished. ChatGPT left behind the structure of what happened but removed the why and how it felt. What remained felt more like sand-boarding over dunes than digging through archaeological ruins.

It was unsettling, not because ChatGPT had done anything wrong, but because it had done everything right. Like the Genie from Aladdin, it gave me exactly what I asked for: a perfect, structured version of my story. And that’s what unsettled me most, because it hadn’t misunderstood me; it had mirrored me. The AI was only doing what I already do: sanding down the tangents, the awkward moments, the messy truths that make the story real. We all do this. We all polish our stories until they shine, even if that means rubbing away the parts that prove we were really there.

The sanitized story doesn’t leave room for doubt in the original design, or for the help you got from another engineer at the last moment, the parts of the story that made it worth telling.

The same tool that polished my words too smooth also showed me what was hiding underneath the shine.

AI can help you write a better answer. But it can’t help you earn it.

Because the truth is, the moments that shaped you — the conflicts, the tension, the times you got it wrong — that’s the part that makes your story unique. The main character of the last blockbuster doesn’t become interesting because he beats the bad guy; he becomes interesting because he bleeds. The damage makes the difficulty meaningful.

ChatGPT can find the themes and polish the phrasing, but it can’t remember the hesitation before you admit something hard, or the weight in your stomach when the pager goes off. Those moments live in you, not in the text.

The older I get, the more I realize interviews aren’t about being impressive. Everyone’s built something hard, or worked on a team that did. What matters isn’t how polished the story sounds. It’s whether you can still recognize yourself in it.

Funny enough, it was ChatGPT, the thing that made my stories too smooth, that reminded me of that. It’s easy to think polish is progress, but sometimes the scuffs and scratches are the proof of life. The rough edges are the parts that remind you: you were there.

You earn those rough edges the way a craftsman earns scars: proof that you’ve shaped something real with your own hands.

You’ve redrawn the same shaky boxes four times. Each arrow gets labeled with even more precise naming. Anything to fill the silence.

On the other side of the Zoom call, your interviewer hasn’t moved his mustache in twenty minutes. The only thing he’s done is paste four lines of text describing the system you’re supposed to design.

You keep glancing for a cue, a nod, a raised eyebrow, a facial twitch of approval, but there’s nothing.

So you start talking faster. Buzzwords fire off like flare guns: redis cache, load balancer, randomly distribute your keyspace by… The silence swallows each thought whole and somehow grows larger.

What do you focus on next?

I used to fight the silence by erasing and redrawing boxes, as if that small act of control could make up for all the verbal flailing. System design interviews are open ended by nature. There is no clear goal or endpoint. You might talk about database sharding, session load balancing, or Redis partitioning. Then the meta questions begin. Why Redis? Why a read cache at all? Why even a read endpoint? Do customers really need this data that badly?

These days, I understand more what these interviews look for because it is the same skill you use every day as an engineer: learning how to move forward when things are unclear.

How do you know you’re on the right track when the world refuses to tell you?

Every system design interview begins in that vacuum. There is no feedback, no validation, and no guardrails. Somehow, you still have to make progress.

Share

System Design is just Engineering

Turns out I actually like System Design interviews a lot more than LeetCode once I figured out a couple of things.

Real work is ambiguous:

Here’s a question I got all the time at my last job: ‘Could we scale that Kafka topic 10x tomorrow?’

It is an ambiguous question, one I had no idea how to answer at first. But if I step back, I can list all the things that should make me nervous.

• Is this 10x my peak volume? or steady state?

• Is this one time event data load, or the new baseline?

• Is the data evenly distributed, or could there be hot spots?

• Does quick math show I have capacity in my fleet to scale this hard?

In the end, those answers decide whether the system holds or collapses. It takes experience to know what should worry you, and even more to know how to fix it. But most of all, it takes curiosity and the instinct to stop and ask the right questions.

Feedback is delayed:

How do you know your last project was going to work before it launched? You wrote the requirements, shipped the code, deployed the artifact. Were you confident it would hold up? Why?

Software is one of the cruelest worlds to work in. The freedom is boundless, but boundless freedom is easy to get lost in. Every choice is a tradeoff, some subtle and some sneaky, and you only learn to spot them through experience. It is hard to tell the difference between made the right call and made something that worked for now.

Code is easy, right? Write some tests, get the green check, move on. But software is bigger than a green checkmark. It is your job to build the feedback loop that tells you whether the whole thing works, not just the parts.

The silence in a system design interview is not a trap. It is a mirror. It reflects what engineering often feels like: no dashboards, no post-mortems, no logs. Just uncertainty. The best engineers learn to build their own feedback loops and trust them.

Build your feedback loop:

A feedback loop is how you stay confident you’re building the right thing. It should be flexible enough to adapt, but rigid enough to keep you moving.

One of my favorite feedback loops for system design problems is the FNCAHA framework. I’m sure the folks over at HelloInterview, who I borrowed (cough: stole) this from, have a catchier name for it. I use it in every interview because it gives me six trail markers that guide me toward a working design. They don’t give you the answer, but they help you find the right questions to ask. Even dim trail markers keep you calm and moving forward.

Here’s a design I built for a NewsFeed service like Facebook. The first section shows the first four parts of the FNCAHA system. Each part builds on the one before it. Together, they form your contract with the interviewer. If it’s on this list, it goes into the system. If it isn’t, or if it’s explicitly marked “below the line,” we leave it out. No boxes, no data specs, no wasted time.

See how the functional requirements and APIs translate directly into the services and systems I built. One for one. Like magic. The design works because it matches exactly what we agreed to build earlier.

Now let’s revisit our non-functional requirements and look for a few wrinkles to smooth out.

A note about Wrinkles

A wrinkle is the thing that makes a problem hard or interesting.

Imagine you run a small online forum for a niche community that suddenly goes viral. Unfortunately this has also brought a lot of spam and invalid posts. Do you:

• allow anyone to post anything they like, and remove bad content later

• put every new post into a moderator queue and manually approve them before publishing?

You can argue either way, but you need to choose and explain why.

For the Facebook design above, one of the non-functional requirements was that the system would take heavy read traffic compared to write traffic. The design as it stands cannot handle that load. Let’s look at why.

Oops. My caching strategy doesn’t actually work the way I thought. Time to rethink it. (Spoiler: the fix is pre-computation.)

This caching issue wasn’t something the interviewer planned to discuss, but it’s a real-world problem that would surface as the system scales. The only reason we caught it was because the our guide posts pointed us back to the trail. Are we still solving the problem we set out to solve?

That is the real signal. Not perfect boxes, but a process that keeps thinking inside the silence.

Subscribe now

Speed up your feedback loop

Like most things I talk about these days, the answer is simple: use more AI. Take a screenshot of your design, drop it into ChatGPT, and ask for feedback at the level you’re aiming for.

• Mid-level engineers can get critiques on service boundaries or database choices.

• Seniors can stress-test scaling assumptions or schema tradeoffs.

• Staff-level folks can get pressed on business metrics, IAM policies, and all the gritty details that usually show up in production reviews.

It’s like having a virtual staff engineer who’s patient, fast, and endlessly curious.

Here are two ways I’ve found it most useful.

Get feedback on your design

Explain why you made a choice and what constraints you were working under. The model will surface missed requirements, highlight weak assumptions, and suggest alternatives you might not have considered. It is not just “Is this right?” or “Would this work?” It is a way to pressure test your design across multiple scenarios before the interviewer ever asks.

After showing chatGPT an early version of my high-level design, here is the top-line response it gave me:

At small scale, this pull-based feed design is simple and correct, but I’d evolve it to a fan-out-on-write model backed by a cache and async queue to handle high read volume and celebrity posts efficiently.

That insight came directly from thinking through the non-functional requirements and how they would impact the system.

Explore tradeoffs in real time

Ever wonder why you chose MySQL instead of DynamoDB? Not just “because it is relational,” but the real use cases where one fits better than the other. Or when Redis might actually make more sense.

Before, the only way to get good answers was to sift through blog posts and half-relevant docs until you stumbled on a decent comparison. Now you can just ask the model.

• “What kind of data would make DynamoDB a better fit?”

• “How does geo-hashing actually work under the hood?”

• “What would have to change for my choice to also change?”

Faster loops

You get clear, contextual explanations at exactly the level you need. For me, that has been transformative. I am no longer guessing which keywords to Google or waiting for a senior engineer to have time. The tight cycle between question, feedback, and insight scales the practice far beyond a single interview.

There aren’t many silences in my interviews anymore. Partly because I’ve practiced sounding human again: talking about the weather, pretending latency is just normal small talk. But mostly because the FNCAHA framework gives me something to hold onto. Clear guideposts that help me move forward when no one is telling me what’s right.

That same structure makes AI tools even more powerful. I can drop a design into ChatGPT, ask for feedback at the level I care about, and get reflection in seconds instead of waiting days for a review. It is all about shrinking the distance between an idea and understanding.

The best engineers I have worked with share the same instinct: shorten the loop, ask questions sooner, surface tradeoffs earlier, and learn faster.

AI just makes that instinct visible. It is a mirror that rewards curiosity instead of perfection.

I’ve been around long enough to see a few full cycles of how engineers get interviewed.

We had the in-person whiteboard rounds, where matching semicolon indentations with squeaky dry-erase markers felt like half the battle. Then came the “modern practical” phase where everybody got to interview on a loaner laptop running Eclipse. The first time this happened to me, I remember thinking, “Wait, I have to write real tests now!” Eventually everything moved online with HackerRank, CoderPad, and take-home assignments in GitHub.

But now we’re in the age of AI, where the IDE itself can vibe its way through an application, and somehow interviews haven’t changed at all.

We’re piloting drones through the Mars atmosphere, and being interviewed for parallel parking skills.

That’s what fascinates me: the work is clearly evolving, but the rituals around hiring haven’t.

Why LeetCode anyway?

LeetCode-style interviews are one of the most ubiquitous technical screens out there. Which, on its face, is kind of silly. I’ve been in this industry for fifteen years. You don’t think I can code? I once rewrote a legacy monolith myself. In the snow. Twice.

Still, let’s be fair for a second. Think about the constraints companies face when designing interviews. The problems they use have to:

• Engage weaker candidates without losing them

• Challenge stronger candidates enough to see them think

• Fit everything into thirty minutes with time for questions afterwards

• Require coding skills

• Be judged consistently across teams and levels

If we’re honest, these interviews don’t exist because they’re realistic; they exist because they’re scalable. When you’re trying to evaluate thousands of engineers across dozens of teams, you need something consistent and gradable.

Sure, you can make a great chicken sandwich. But McDonald’s can make ten thousand identical ones in a second split across six continents. Thats what hiring processes are emulating: repeatability over realism.

The problem is that what they measure no longer maps to what the job actually is.

They reward engineers who can stay calm under artificial pressure, recall syntax from memory, and pattern-match problems they’ve seen before. But the skills that matter in today’s workplace: reasoning about systems, communicating trade-offs, and guiding AI tools, don’t show up in a timed puzzle.

Software has already shifted away from raw code toward systems, trade-offs, and collaboration. Yet we’re still testing candidates as if success depends on how fast they can remember syntax.

The problem isn’t that LeetCode interviews are unfair. It’s that they’re measuring a version of engineering that doesn’t exist anymore.

Share

Playing the old game with new tools

If the game’s outdated, fine. We can adapt. Here’s how I turned AI from a distraction into my best weapon.

Step 1: Have a specific plan

LeetCode, like most of software, is more about pattern recognition than anyone likes to admit.

The fastest way to get better is to start with a naive solution, figure out where it’s slow, and then match the right data structure or algorithmic trick to make it faster. Need to query a key quickly? Use a Map. Need to find unique values? That’s a Set.

And yes, the only way to get better at this is to practice. (What did you think I was going to say?)

Start with LeetCode’s Top 150 to get a good baseline. For big tech companies the general rule is that you should be able to handle any Medium problem, and some Hard problems. The smaller the company usually the lower the bar on this.

Step 2: Use AI to move faster

One thing I always forget between interview seasons is just how much repetitive setup these problems require.

I use my own IDE, so my workflow looks like this:

• Create a new solution file

• Set up a template class with the right args

• Write a main method to execute

• Add a few sample tests and just enough prints to verify they run

Only then do we reach the interesting part: actually solving the problem.

Those first four steps are a lot of clicking and typing for almost no learning value. Thinking up test cases is useful; but writing the for loops to run them isn’t. It’s busywork. It doesn’t teach you anything new.

So let the model handle it!

Paste the problem context, ask it to generate the file, and give it a short, consistent recipe for test cases. Why are we still typing boilerplate in 2025?

The skill you want to practice is how you think through a problem. The rest is a waste.

I even wrote a small MCP server that hooks into LeetCode’s public GraphQL API to automate this. My Claude Code agent connects through that server, finds problems by number or title, and generates ready-to-run files in whatever language I’m practicing.

It’s simple, but it saves a surprising amount of time and keeps me focused on the thinking, not the typing.

Step 3: AI as tutor, not answer key

When I get stuck, it’s tempting to peek at the solution for that quick flash of insight.

But that’s the fastest way to short-circuit learning. Resist the spoiler.

Instead, treat the model like a tutor. I explain in plain English how I’m approaching the problem, where I think it’s breaking down, and then ask it to nudge me using the Socratic method.

Pro-tip: always add the line no code samples unless asked or the model will be extra helpful and finish the problem for you.

This is the number one technique that has improved my ability to do these problems. It’s easy to lull yourself into thinking you understand the solution when you’ve already seen the working code.

It’s much harder to fool yourself when the model is asking you specific questions about your assumptions.

Guided discovery sticks better than reading a finished solution. Senior devs can prompt for “vague hints”; juniors might need more structure. Either way, store your preferences so the model remembers your learning style across sessions.

Don’t sweat the syntax

AI is changing the abstractions we work in as engineers.
Yesterday, we focused on for-loops and OOP singleton patterns.
Tomorrow, it’ll be natural language and automated test results.

If I could tell my younger self one thing during those nerve-wracking whiteboard interviews, it’d be this: stop sweating the syntax.

We’ve entered a world where fluency means understanding abstractions, debugging with the right tools, and guiding models to produce correct code for our exact use case.

Yet LeetCode interviews still reward the opposite: syntax recall across multiple languages and the ability to type fast under pressure.

I don’t expect interviews to change overnight.

But by adapting how we prepare, we can use the same tools transforming engineering itself to challenge how we prove we’re “qualified.”

Someday, interviews might finally mirror how we actually work: messy, collaborative, context-driven, and yes, assisted by AI.

Until then, we can at least prepare like it’s 2025, not 2010.

Next post, I’ll dive into why System Design interviews are quickly becoming the most relevant part of the process — and why AI makes them more fun (and useful) than ever.

Boxes and arrows will probably outlive us all. But the coding rounds? They’re starting to feel like a relic.

Most days, I don’t feel like I write code anymore.
I guide something bigger up the mountain.

These models are powerful, no question. It can spin up scaffolds, refactor code, generate endpoints in seconds. But only if I chart the path.

My job? Feed it just enough context to take the next step. Anticipate what it's missing. Nudge it back on track when it drifts. When I’m on it, when I stay ahead of its blind spots, we race to the summit together. It’s like climbing with the world’s fastest intern: never tired, never blocked, occasionally full of nonsense.

But when I misjudge and provide it too much task context, not enough instruction, the wrong focus? The whole climb becomes a slog through mud. I burn an hour investigating a package dependency that should’ve never been added, missed in an avalanche of colorful git diffs.

I used to think of myself as a builder: the one shaping plans, pouring the foundation, laying down structure.

Now I feel like the Context Sherpa.

The one holding the ladder on the way up, belaying the rope on the way down. The one watching every snow drift and ice shelf, just to shepherd another group of overconfident tourists who think black ice is a cocktail at base camp.

And that shift? It’s subtle.
But it’s the beginning of something much bigger.

Share

Trust Is Built On Specifics

Code at tech companies never dies.

It decays.

Version by version. Patch by patch. Held together by duct tape, tribal knowledge, and that one person who remembers why a cron restarts the logging service every Thursday at 2am.

Sometimes that mess slows you down. Other times it’s the only reason you’re still shipping.

These new AI tools know how to scaffold a backend service, explain what GraphQL is, and write clean, generic OAuth flows. They’ve seen 10,000 Next.js blogs and a thousand Stripe integrations. What they haven’t seen is the handwritten CSS your CTO swears keeps load times fast.

Your codebase didn’t spring into being fully formed. It grew as a layering of context, constraints, and chaos; some of it intentional, some of it ancient, and all of it invisible to a model trained on vibes. You don’t need help “integrating Stripe”. You need help debugging why your checkout form fails, but only on Safari, when Chinese characters show up in the billing name, and the user clicked “back” twice.

(re focus this on what the role of a sherpa is here? the human needs to provide context into how everything fits together)

Productive software isn’t built on “best practices”. It’s built on specifics.

And when the model gets those specifics wrong? The Sherpa doesn’t get to shrug. They patch the commit, fix the broken code, re-deploy the services. Because AI tools don’t understand how your systems actually fit together. They don’t know which assumptions are safe to make and which ones can take prod down at 2am.

The Context Sherpa exists because someone has to translate between what the model knows and how your system actually works.

Someone has to know what the real goal is, and whether that sudden pop means a branch snapping on-shore or ice giving way. Not just to help the tools succeed, but to keep the whole team from going over the edge.

That’s the job now: not writing every line, but making sure every line still fits.

The Human Bottleneck

This is where the trust gap lives — not just in the model’s misunderstanding, but the invisible scaffolding that assumes a human will always there to catch the fall.

Software wasn’t built for machines. It’s built for humans fluent in ambiguity. Who else but Mark could know why one feature is gated by a flag, and another is gated by a comment that just says:

DO NOT REMOVE. ask mark.

Our current code is written by humans, for other humans. The moment you pull the human out of the loop, or ask them to guide instead of write, the system starts to wobble.

Take documentation. If it exists at all, it was probably written by developers for developers. We speak fluent vibes. I’ve written run-books that say things like:

SSH to prod cmh1, find a host from the kube cluster and tail the logs

It looks like a clear set of instructions, and it is, but only if you already know:

• What “cmh1” is

• Which kube cluster this service is hosted on

• What logs to tail… and why

That blend of concrete steps and unspoken assumptions is perfect for human developers. Terrible for coding agents to understand. Now imagine a set of docs that instead had:

• Precise, declarative instructions

• CLI-first workflows

• Structured, inspectable state

That’s not just better documentation, thats a resource that lets your agentic tooling handle more mundane tasks.

That’s a handrail on the mountainside, the kind that lets the Sherpa breathe, look up, and plan the next move.

Guiding the Climb

I’ve worked with a lot of interns over the years. Some soared. Some flailed. And the difference was almost never talent — it was structure.

The ones who struggled usually weren’t lazy or incapable. They just didn’t have the right support. No scaffolding. No clarity. No one breaking the work into pieces they could act on. They were thrown into a sea of complexities and deadlines and expected to swim.

Working with today’s coding tools feels the same. They’re interns — fast, eager, and wildly inconsistent unless you give them structure.

And like any good mentor, I spend a lot my day to day clearing the trail for them:

• Stitching together missing context

• Rephrasing task to get better results

• Splitting work into clean, self-contained chunks

• Catching hallucinations before they hit prod

• Bridging assumptions the model never knew it was making

I now act as a Context Sherpa — an engineer whose job isn’t to write the code, but to make the code possible. To synthesize chaos from every corner of the org: ancient tickets, Slack threads, vague product notes, broken Swagger docs. To shape that mess into something usable and feed it to the model at just the right moment.

The best engineers don’t just “prompt better”, they orchestrate better.

They know how to set the models up for success. When letting them run the tests is going to pinpoint an error, or waste a thousand tokens. They know when to retry a task, when to zoom out, or when to change tactics entirely. They move fast, not because they trust the model blindly, but because they’ve learned how to steer it.

It’s easy to see that models write fantastic code. And projects like SequentialThinking, Context7, and MCP servers are giving agents real capabilities — memory, error handling, terminal access, planning logic.

But for everything else — the vague specs, the brittle edge cases, the undocumented behaviors?

There’s still a Sherpa on the trail.

A human engineer.

Guiding the model. Reading the weather. Choosing the path that doesn’t end in an avalanche.

From Collaboration to Succession

Let’s rewind:

In Part 1, I argued that LLMs aren’t valuable because they’re smart — they’re valuable because they feel trustworthy.

In Part 2, we explored how good tools build that trust through a slider — from assist to autopilot — letting users gradually hand off control.

Now, in Part 3, we’re seeing the deeper truth: The current development ecosystem wasn’t built for agents.

It was built for you.

That’s the real shift underway.

Because the Context Sherpa isn’t just about climbing to the summit. Now they’re the critical infrastructure that keeps the project moving.

The one who knows where the trail gets narrow.
The one who keeps the rope slack, but safe.
The one who gets there early so someone else can make it to the top.

Working with LLMs is becoming about scouting terrain. Breaking down workstreams. Learning what the model understands and where it crumbles. Not solving every problem directly, but running one step ahead to clear them before

You’re not just the engineer anymore. You’re the reason the whole system works.

The more capable these tools become — the more they remember, plan, and act — the more they rely on the thing they still can’t hold: context.

And that’s where you come in.

Trust doesn’t come from the model. Trust comes from the Sherpa.

When I was 14, I dragged my bike to the top of a curvy highway in Avon, wished myself luck, and full-sent it towards the bottom.

Four-lane roads in a town with money mean licorice-slick pavement: smooth as butter, irresistible, and absolutely not part of a balanced lifestyle. It’s 80 degrees. I’m in cutoffs, shirt tucked into my waistband, CD player strapped to my hip, blasting punk rock straight into my brain. No helmet. No hands.

I am invincible.

Every lean into a corner is effortless. Every sewer cap and honking car becomes a chance to express myself in motion. The wind slices through me like I’m barely real. I am free.

I close my eyes.

Just for a second.

Adrenaline. Euphoria. Then a wobble. Then pain.

I wasn’t smart at 14 (who is?). But in that moment, I trusted the bike. I thought we were synced up. One fluid motion machine. Closing my eyes felt like control. Like confidence. Like flow.

Then it hit a rock.

That’s the line every AI product is walking right now. It’s not about what the model can do at the best of times — it’s about what you trust it to do without checking every move.

Will your users trust you enough to close their eyes?

Designing for Trust

There are two types of trust that are required for good software.

Procedural Trust — "I know what it’s going to do.”

This is what traditional software offers. Click the “equals” button on a calculator, get a number back. It’s stable, repeatable, testable. Run it in CI or on the moon and you’ll get the same result.

Emotional Trust — "I like what it does. I feel like it gets me."

This is when a product nails the use case. Streaming to friends in Discord? One click. Buying something on Amazon? One click. Even WinRAR gives you the free download button you’re really looking for. These tools feel like they just get it and they’re optimized to do that one thing perfectly.

What do AI products offer?

Now compare that to your average AI product built around LLMs.

• Insane recall, but also wild hallucinations

  • (They’ll cite a real study from a journal that doesn’t exist.)

• Genius moments, but confident nonsense

  • (They’ll write a sorting algorithm in assembler, then tell you 9.11 is bigger than 9.9.)

• Infinite patience, but goldfish memory

  • (They’ll debug with you for hours, then forget your project even exists.)

LLM-powered products are biased toward emotional trust. They feel like they understand your problem. They surprise you. They dazzle in demos. They offer the sizzle trailer for your exact use case. And wow do they look cool.

But they fall short on procedural trust. No reliable memory. No consistency. No guarantees. These are areas the software community is working to improve… but nothing that gives you the contract that traditional software does.

And that’s the problem.

Emotional trust gets people excited.
Procedural trust gets them to rely on you.

Strong AI products don’t ignore this. They flip it on its head and invoke the ancient ritual of “features, not bugs”. And when you design around that, you get something new: A product that adapts to the user’s trust, not the other way around.

Share

Autopilot or Assistance

Great AI products understand a simple truth: trust is fragile.

A few impressive demos, and teams start reworking their workflows to lean on the tool more. One high-profile mistake, and everything snaps back to manual. Adoption doesn’t build in a straight line: it flinches.

That’s because the level of control we’re willing to hand over shifts constantly, from task to task, moment to moment. Self-driving cars nailed this dynamic a decade ago. You could take a ride in one back in 2013. You might have even trusted it in a well-lit parking lot with no traffic. But a rainy night, unprotected left turn, construction zone up ahead? Not a chance.

That’s the product challenge: trust isn’t binary. It lives on a slider — from assist to autopilot — and great products meet users wherever they are on it.

Assistance — “Help me take this action.”

These are small, well-defined tasks. The user knows what they want — they just want help doing it faster. Rename this file A → Z. Find every reference to “abc.py”. Reword this sentence with fewer passive verbs.

The tool isn’t deciding. It’s executing.

Autopilot — “Help me accomplish this goal.”

These are fuzzier. More room for interpretation. Write unit tests for this new module. Summarize this paper. Get me home. Now the tool is drawing context, making assumptions, and choosing the path. These tasks don’t just save time. They save thinking.

You can see this slider in action across a huge range of products. Here are a few that I use daily:

• In Cursor, it’s the difference between fixing a line (Tab), rewriting the feature (Cmd + I), or building something new (Cmd + K).

• In Perplexity, it’s choosing between a quick answer, a semi-directed query, or running a full research synthesis.

• In Tesla, it’s going from lane assist, to self-driving, to taking a nap in the back seat.

At every moment, in every decision, these products are asking the same question.

Do you trust us enough to close your eyes?

Building Trust

Every time a user asks an AI product to do something meaningful, they’re running the same loop:

• Generate — the model makes a thing

• Verify — the user it, gut-checks it against their expectations

• Regenerate — tweak the input, try again, steer the output

Trust is built incrementally, one loop through this cycle at a time. As a developer, I live this every day. How much context do I need to give the model to get something useful back? Can I trust it to write a full test suite? What about just a single test file with these exact constraints?

Each pass through that loop teaches me something about what the tool can handle and where I need to be in control.

If the original generation is slow, you lose momentum.
If the output verification is hard, you lose procedural trust.
If the regeneration is clunky, you lose emotional trust.

This loop is the engine of user trust. Tighten it, and users move faster and trust more. Break it, and the whole product falters.

Trust Is the Product

You’re not selling magic.
You’re not selling automation.
You’re not even selling intelligence.

You’re selling trust.

Trust is earned one generation at a time, and is always at risk.

The best AI products don’t rush that process. They respect it.

They:

• Make the generate → verify loop fast, cheap, and safe

• Let users control the autonomy slider, instead of forcing a leap

Not every user is ready to make the leap to full autonomy, but plenty are willing to consider it.

Some want full control.

Others want to hand over the wheel.

Great products support both.

Because in the end, every UX choice, every shortcut, every abstraction is really asking the same thing:

Will your users trust you enough to close their eyes?

By far the most impactful $20 I spend every month is my ChatGPT subscription, and it’s not even remotely close. Two years ago, this product didn’t exist. Now I ask it about everything: best steak cooking temps, how to politely thank annoying relatives, what food travels well for boat parties, and which ramen shops are open in Tokyo at 2am. (Answer: a lot).

The weird part about it? I can’t even tell you what category this thing fits in.

Most mainstream tech solves a clear problem. WhatsApp is for chatting with your sister. Google helps you find websites. Instagram is for feeling bad about your life.

But what’s ChatGPT for?

Sometimes it’s a personal assistant. Sometimes it’s a search engine. And sometimes, when you ask it to describe you, it’s like running whoami on your soul. And the output is disturbingly accurate. (Pro tip: do not try this with friends in the room unless they’re also your therapist.)

But here’s the catch: those are all roles it plays because I asked it to. They don’t describe what it actually is. LLMs are unlike any software we’ve ever used, mostly because we don’t know what they are, and we definitely don’t know what they’re for.

Share

The Metaphor Gap

Most of my friends — like yours if you are reading this SubStack — live in a tech bubble. We’ve heard of Sam Altman. We know what an API is (even if we don’t want to write yours). I can use the generic word “model” and you’ll understand what I mean.

But try actually defining what an LLM is — like, out loud, to a normal person — and you’ll feel the edges of insanity starting to creep in.

It’s like an app? But there’s no clear task it’s designed to do.

It’s like a search engine. But you don’t get links… just a weirdly confident, potentially hallucinatory, essay.

It’s like talking to a person. But it forgets everything you’ve ever said to it, instantly.

LLMs are just… something smart that shows up when you ask. Kind of like rentable intelligence that shows up via Wifi. Which, to be clear, is definitely Cool™.

But also a little unnerving because everything we’ve said so far describes what LLMs aren’t.

So how should we think about them?

Here’s a few metaphors I’ve heard recently. All of these work, right up until the point they don’t.

Like Power, but Smarter (read: Weirder)

The way I think about LLMs most of the time is pretty simple: they’re like public utilities, but for intelligence.

We expect utilities like water and electricity to be reliable. Always on, always there when we need them. They’re expensive to build, but once they’re running, they scale easily. The more you use, the more you pay. And no one really cares which power company is behind the outlet — they just want the lights to turn on.

That’s how I treat models like Gemini, ChatGPT, or Claude. My toaster doesn’t care if the power came from coal, wind, or solar. It just wants electricity. Same with my prompts most days. I’m not looking for magic. I just want a straight answer.

LLMs feel like that… until you flip the switch and get an apology letter to your landlord instead.

The type and quality of electricity doesn’t change based on how politely you ask for it. LLMs do.

Unlike utilities, end users can’t always expect the same output from the same input. Sometimes you get water. Sometimes you get poetry. Sometimes you get confidently incorrect math.

(That’s why I put together a whole breakdown on the six building blocks of strong AI prompts — because getting back useless answers got old real fast)

Sudo Synthesis

Build Better AI Prompts: The 6 Blocks Every Engineer Should Know

Watch enough 80s action movies and you start to see the blueprint. A brooding ex-mercenary with too many muscles and not enough therapy tries to walk away from a fight, until an unbreakable personal commitment pulls him back in. Sure, the details change from movie to movie, but the formula becomes impossible to unsee once you notice it…

Read more

10 months ago · 2 likes · Daniel Kirschner

Like MacOS With Stronger Opinions

Another way I think about LLMs is like operating systems — not because they run hardware, but because they stitch everything else together.

Windows, Mac, and Linux are the glue that makes computers work. They connect your apps, manage memory, handle storage and networking. You don’t usually think about them unless something breaks, but they’re always working behind the scenes to make everything feel seamless.

LLMs, especially with the advent of autonomous systems, or MCP servers, are starting to feel the same way. They can talk to other tools, remember short-term context, route tasks between systems, even translate between APIs or file formats. They’re not the app, and they’re not the output. They’re the goopy layer in between that holds everything together and makes it work.

And just like operating systems, there are only a handful of major players: OpenAI, Google, Anthropic, Meta, xAI.

Some models are locked-down and corporate. Others are open and re-mixable. You can fine-tune them, distill them, even run them on your own hardware if you’re brave (or bored). It’s not quite Linux-for-your-brain, but it’s starting to get close.

LLMs feel like that… until your function call returns a haiku instead of structured JSON.

Above all else, operating systems are consistent. They give you APIs, permissions, error codes. When you call a function, you know what it’s going to do.

LLMs don’t come with technical support or a manual. No guaranteed output. No clean abstraction between “what it can do” and “what it might decide to do this time.”

Smart Tools with Strange Behaviors

As a creator, LLMs seem like a Web 2.0 version of a power tool from Home Depot. You give them a task — draft this email, summarize that article — and they do it. Fast, clean, and without complaints about “paid time off” or “lunch breaks”.

But sometimes you ask for a blog title, and it gives you an outline. Then a first draft. Then a tagline. Suddenly it’s pitching follow-up content, branding ideas, and a three-tier marketing funnel. And you’re just sitting there, watching the cursor blink as it sprints off ahead of you.

LLMs feel like picking up a drill and watching it redesign your living room.

These aren’t passive tools waiting for instructions. They extrapolate to generate. They take your starting point and run with it. You wanted to hang a picture frame; they’re halfway through building a shed.

The question we need to ask isn’t “can this help me?” but “how much should I let it run?”

And I don’t know about you, but I’ve never used a power tool that had such strong opinions before.

Where the Metaphors Break

So, yeah — LLMs are kind of like public utilities. Kind of like operating systems. Kind of like power tools.

But really, they’re none of those. They live in this weird conceptual limbo, not quite tool, not quite platform, not quite infrastructure.

And for me, as an engineer, that limbo poses a practical question. How do you build tools on top of something that might behave differently every time you call it? I’m used to working with systems that have rules, contracts, guarantees. LLMs don’t. And how do you build on top of something you can’t rely on?

Subscribe now

In Search of a Use Case

A lot of this metaphor chaos comes down to one big thing: LLMs are software in search of a problem.

Like crypto and blockchains before it, the tech is mind-blowing. Genuinely new. But nobody knows what to actually do with it.

Immutable, traceable ledgers sound cool. But I can’t buy a cheeseburger with them. Guess I’ll just stare at the line go up and pretend it matters.

Most major tech shifts happen in the opposite direction. Someone has a real-world problem → builds a solution → that solution scales to make money. Every founder pitch deck and startup playbook is built from this foundation.

• Amazon: Bezos wanted to buy books online. Now they sell half the internet, and lease compute time to the other half.

• Facebook: Zuckerberg wanted to know who else was single in his dorm. Now they destabilize democracies world-wide through political ad targeting.

• Spotify: No one wanted to wait for their six-CD changer to cycle. Now we have access to every song every recorded, and a few that shouldn’t have been.

Problem → Solution → Scale

So… what big problem do LLMs solve? Nobody really knows. (Except at Meta, where the endgame is a dead internet — just bots generating content for other bots, while making sure you stay engaged enough to keep scrolling.)

This lack of a clear problem is why we can’t describe LLMs, or decide what to build with them. No shared vocabulary. No constraints. No common frame of reference.

We don’t know what this software is. We don’t know what it’s for.

And yet… it’s so damn interesting we keep building with it anyway.

In Part 2, I’ll look at how the best AI tools don’t try to solve problems. They help users manage control. Because the real shift isn’t in what LLMs do — it’s in how much we trust them to do it for us.

A recent video from Cursor and Anthropic brought this into focus: the abstractions are moving up. This isn’t about what programming language you use or what kind of SaaS product you’re building. The “lego blocks” developers build with are growing in size. Instead of writing code line by line, we’re now dropping in entire functions or features at a time.

This isn’t just a faster way to type. It’s a fundamental retooling of how development happens.

Here are four ways AI is already changing developer workflows, and one place it still falls short.

Share

The Model Layer

Line-level Assist

Developers spend a lot of time making what I think of as bonsai edits—small, precise tweaks that gradually shape the code into something cleaner and more intentional. Maybe you’re renaming tests to better reflect their purpose, or rewriting comments to match updated behavior. AI tab completions are surprisingly good at understanding your intent in these moments. They don’t always get it right, but when they do, it’s a quick snip-snip and the code keeps growing in the right direction.

Bonsai edits are still the smallest building blocks, just a line or two at a time. But AI helps speed them up so you can stay focused on the bigger picture.

Function-Level Handoff

AI tools are especially useful when you know what you want to build, but the implementation is gnarly. Maybe there are too many edge cases, messy config combinations, or obscure API quirks. The models can handle the grunt work—building test cases, filling in boilerplate, and translating your design into real code. They handle the details so you can stay focused on validation instead of getting lost in the weeds. Instead of writing every line yourself, you can hand off an entire block of logic. The abstraction shifts from code-as-instruction to code-as-intent.

And then there’s legacy code. Every team has a file or two from “the last guy” who vanished mid-project. Not always bad, just weird, dense, or a little too clever for its own good. Normally, you’d ask a longer tenured engineer for some outside context or help unpacking… why?

But AI tools can fill that role surprisingly well. They can parse the tests, the structure of the code, and other scattered clues in comments and doc-strings. You don’t need to decode “the last guy’s” thought process. You just need to understand the shape of what they built. And AI is pretty good at that.

System-Level Understanding

Even experienced developers get dropped into unfamiliar systems. Maybe it’s a service you’ve never touched, or a repo with sparse docs and cryptic naming. You didn’t even know it existed ten minutes ago when your boss sent a frantic Slack message. Now there’s a meeting on your calendar named “Quick Sync – Updates?”

AI tools shine in this situation. They can quickly surface high-level summaries, explain what a block of code is doing, or map out how data flows through the system. It might not tell you how to fix the problem, but it’s usually enough to get you unstuck.

Even without full context, the model helps you operate at a higher level. You’re not reading every line: you’re scanning for intent.

And while the model’s generating context, you’ve got just enough time to decline that meeting invite.

Project-Level Generation

Every new repo comes with a certain baseline amount of boilerplate just to make it run. Maybe it’s build YAML files, Spring XML configs, or a set of Gradle plugins that need to be configured just right to work.

AI models are great at generating this kind of scaffolding, tailored to your specific use case. Not just a blank starting point, but something that already understands what you’re building and how you expect to package it up.

This is where the building blocks get even larger. We can spin up whole projects from just a few cues.

The Human Layer

Taste & Context at Scale

A lot of the current value in these AI tools comes from offloading mental overhead. You can hand off the mechanical parts of coding and spend more time thinking about what to build instead of how to type it.

But that’s also where the tools still fall short.

Generating code isn’t the goal. Solving the right problem is.

What counts as “good software” depends on a hundred subtle factors. Maybe it’s your company’s architecture strategy. Maybe it’s the latest buzzword your CTO brought back from a conference. Maybe it’s just the size and structure of your team.

What works in one repo might be a mistake in another—even within the same company. Tools like .cursor/rules can help enforce engineering patterns, but they can’t encode product strategy. And they definitely can’t define your team’s taste—the shared sense of what “good code” looks like, shaped over time through culture, PR reviews, and unspoken norms.

Think about the feedback on your last design doc. Or the conversation with your manager at lunch. Strategic goals, edge-case constraints, and product’s shifting priorities all live outside the code. But they shape what “good” looks like just as much as naming conventions or abstraction levels.

Where the Real Leverage Lives

The abstractions we work with are changing. Line-by-line edits are giving way to blocks, features, and systems that arrive already half-built. The job of the developer isn’t shrinking—it’s shifting. From typing to deciding. From building to directing.

That shift raises the bar on judgment. And for now, that’s still the part the machines can’t do for us.

Cursor x Anthropic

The original video that sparked this post is worth a watch!

Watch enough 80s action movies and you start to see the blueprint. A brooding ex-mercenary with too many muscles and not enough therapy tries to walk away from a fight, until an unbreakable personal commitment pulls him back in. Sure, the details change from movie to movie, but the formula becomes impossible to unsee once you notice it.

Prompting AI models works much the same way. Whether you realize it or not, you’re probably following a familiar structure: setting context, providing background, and asking a clear question. I recently came across Anthropic’s guide to writing strong prompts. It’s designed for Claude, but the patterns it outlines show up across every major model. They reflect a shared internal grammar that most LLMs seem to recognize.

In this post, we’ll break that structure down into a reusable prompt template you can apply across models and tasks. To see how well it holds up, I asked the Big Four—Claude, GPT, Gemini, and Grok—for feedback on what they would change. The core framework passed the test, but each model had strong opinions about what really matters.

The 6 Core Blocks of a Strong Prompt

All structures are built from a solid foundation, whether thats a blanket fort or the Taj Mahal. Each piece builds on the next in sequence, and missing any of them can result in unexpected destruction. While the ordering of these pieces isn't critical for all prompts, using them in this order helps the model understand clearly what we're asking it to do. As always you'll need to test with your specific use case to see the results!

Share

Here’s the 7 building blocks used to create a personal shopping prompt.

1. Broad Role / Persona / Tone / Task

Every prompt starts with setting the scene. You’re telling the model what kind of role it’s stepping into, who it’s speaking to, and what kind of outcome you’re aiming for. Without this framing, responses can drift in tone or miss the point entirely. You don’t need a full character backstory, just enough clarity to lock in the right context.

You are a personal shopping assistant who specializes in answering users questions based on previous customer reviews of their purchase.

2. Input Data

Once the model knows what role it’s playing, it needs something to work with. This is your source material—the raw context the model will draw from when answering. The more input you include, the earlier in the prompt it should appear. That way the model processes the data first instead of jumping straight to the question and backtracking.

Here are a selection of customer reviews for the chosen product:

<product_reviews>
- ⭐⭐⭐⭐ “Great sound quality and battery life. Case feels a little cheap though.”  
- ⭐⭐⭐ “Fit is okay, but they fall out when I run.”  
- ⭐⭐⭐⭐⭐ “Excellent for the price. Noise cancellation works surprisingly well.”  
- ⭐⭐ “Connection drops often, especially when paired with a laptop.” 
- ⭐⭐⭐⭐ “Solid fit and amazing sound, but case is bulky.” 
- ⭐⭐⭐⭐⭐ “Love these. Super reliable and good mic quality for calls.” 
</product_reviews>

Note the (optional) use of XML tags to explicitly mark sections of content we want the model to pay attention to. This can be extremely helpful when re-using template prompts where the input data isn’t known ahead of time.

3. Examples of correct responses

Examples help calibrate the response, especially when you’re dealing with nuance. Without them, you’re leaving it up to the model to guess what you mean by words like “helpful,” “brief,” or “clear.”

Even one or two well-chosen examples can anchor the task.

<example>

<question>
Are these headphones good for running?
</question>

<answer>  
**Short Answer**: Not ideal for running.  
**Why**: One reviewer said they fall out while running, and no other reviews mention good fit during exercise.  
**Quote**: “Fit is okay, but they fall out when I run.”  
</answer>

</example>

4. Detailed Task or Question

Now that the model knows who it is, what data to use, and what a good answer looks like, it’s time to get specific. This is where you ask the actual question or define the task. Like with any type of question, the more clearly you explain yourself, the better the results. Vague prompts produce vague answers.

Write a clear, concise answer to this question:

<question>
Are these headphones good for travel?
</question>

5. Output Formatting Instructions

Don’t leave formatting up to chance. If you want the output in a specific structure, say with XML tags or bullet points, spell it out. This helps ensure the response is consistent, scannable, and easier to parse, especially if you’re feeding it into another computer system for further processing. It’s also a good place to define what the model should do if it’s unsure. Pro-tip: double check this format matches with the examples you used previously!

Respond using only this format:

<answer>  
**Short Answer**: [consise answer]  
**Why**: [1–2 sentence explanation]  
**Quote**: [Relevant quotes]
</answer>

If there is not sufficient information in the compiled research to produce such an answer, you may demur and write "Sorry, I do not have sufficient information at hand to answer this question."

6. Precognition or thinking instructions

This block is optional, but powerful. Use it when you want the model to follow a specific reasoning path before answering. Good examples are extracting quotes from the input data, weighing pros and cons, or scanning for patterns. Think of it as prompting the model to “think out loud” before giving you its final answer.

It’s especially useful when accuracy matters or when you’re working with dense input data. If you only need the answer to have the right vibe, you likely don’t need it. But if you want grounded reasoning, sourced output, or better consistency across responses, this step makes a big difference.

Before you answer, pull out the most relevant reviews from the data into <relevant_reviews> tags. Then answer the question.

Putting it all together

Here’s that same prompt put together neatly so that you can give it a quick copy+paste in your next prompting session.

Subscribe now

You are a personal shopping assistant who specializes in answering users questions based on previous customer reviews of their purchase.

Here are a selection of customer reviews for the chosen product:
<product_reviews>
- ⭐⭐⭐⭐ “Great sound quality and battery life. Case feels a little cheap though.”  
- ⭐⭐⭐ “Fit is okay, but they fall out when I run.”  
- ⭐⭐⭐⭐⭐ “Excellent for the price. Noise cancellation works surprisingly well.”  
- ⭐⭐ “Connection drops often, especially when paired with a laptop.” 
- ⭐⭐⭐⭐ “Solid fit and amazing sound, but case is bulky.” 
- ⭐⭐⭐⭐⭐ “Love these. Super reliable and good mic quality for calls.” 
</product_reviews>

<example>
<question>
Are these headphones good for running?
</question>
<answer>  
**Short Answer**: Not ideal for running.  
**Why**: One reviewer said they fall out while running, and no other reviews mention good fit during exercise.  
**Quote**: “Fit is okay, but they fall out when I run.”  
</answer>

Write a clear, concise answer to this question:
<question>
Are these headphones good for travel?
</question>

Respond using this format:
<answer>  
**Short Answer**: [consise answer]  
**Why**: [1–2 sentence explanation]  
**Quote**: [Relevant quotes]
</answer>

If there is not sufficient information in the compiled research to produce such an answer, you may demur and write ""Sorry, I do not have sufficient information at hand to answer this question."".

Before you answer, pull out the most relevant reviews from the data in <relevant_reviews> tags. Then answer the question.

What the Models Said

I asked Claude, GPT-4o, Gemini, and Grok to review this intentionally minimal prompt and offer feedback on what worked and what could be improved. Unsurprisingly, all of them agreed it was a solid starting point. But interestingly, each one had a different idea of what could make it stronger. To make sense of those differences, I assigned each model an archetype that reflects how it seemed to approach the problem.

Across the board, the models praised the prompt’s structure and clarity. Most emphasized the need for more explicit instructions to interpret and synthesize the input, rather than just rephrasing it. That lines up with what these models do best: processing large amounts of context and delivering grounded, helpful answers.

What surprised me was that each of the models had a different focus area for improvements. Some responded with direct, tactical edits I could immediately use. Others offered broader conceptual suggestions. A few focused on ambiguity and edge cases, proposing ways to handle incomplete or unclear input more gracefully.

Four AI Coworkers Walk Into a Prompt…

Each model brought a distinct personality to the table. It felt less like testing software and more like running a design review with four very opinionated coworkers. One sees prompts as architecture. Another flags ambiguous requirements. One rewrites your design for clarity while you’re still explaining it. The last one challenges your core assumptions just to see if they still hold up.

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

And yet, despite their differences, they all agreed on one thing: strong prompts aren’t accidents. They’re built.

This exercise showed that well-structured prompts—like well-structured code—are modular, readable, and reusable. These six building blocks won’t guarantee the perfect response every time, but they give you a blueprint that works across tools, use cases, and model temperaments.

In the next posts, we’ll dig deeper into each model’s feedback and explore what it reveals about their internal logic and design assumptions. Think of it as personality typing for LLMs: practical, a little nerdy, but surprisingly useful.

Until then, try the prompt. Tweak the blocks. Break them. Rebuild them. That’s how you go from guessing to engineering.

👋 This post is part of the AI Prompt Blueprint series.

In the main post, I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

You can keep reading for ChatGPT’s feedback or jump to your favorite model’s feedback below:

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

ChatGPT approached this prompt like a professional editor reviewing a work document before it goes to production. It wasn’t trying to reinvent the format or question the premise. Instead, it focused on polishing the language, generalizing the use case, and tightening ambiguity so that the final result would be clearer, more robust, and easier to reuse.

While the other models we got feedback from spent time looking for gaps in the blueprint, ChatGPT used it’s tactical editing skills to make the copy sharper, the roles more specific, and the instructions more foolproof.

Share

Tactical Edits, Not Reinventions

ChatGPT stepped in like a seasoned editor, scanning for subtle misalignments between what I said and what I meant, looking for ways to make everything clearer, more consistent, and easier to reuse.

Like the other models, ChatGPT quickly flagged two common prompt pitfalls: unclear roles and weak synthesis instructions. It suggested shifting the assistant’s title from “personal shopping assistant” to “product expert” to avoid persuasive framing, and added a line reminding the model to “synthesize relevant insights” rather than just echo reviews. Small changes, but they help the prompt do its job more reliably.

Then it flagged the <relevant_reviews> section of the answer. Was this for internal use or part of the visible output? ChatGPT surfaced the ambiguity and offered two clear paths: make it part of the answer or label it explicitly as a reasoning step. This kind of clarification is what helps prompts scale across different tools and use cases.

💡 ChatGPT was the only model to suggest adding a second example that showed the model how to respond when it didn’t have enough information.

Not just a fallback line of instruction, but an actual demo of when and how to use it. That detail reflects ChatGPT’s core strength of turning fuzzy instructions into teachable behavior.

None of this feedback was flashy. But that’s the point. ChatGPT behaves like a pragmatic editor. It’s focused on polish, generalization, and instructional precision. It won’t rewrite your idea, but it will make sure your prompt is clear, durable, and ready for production.

ChatGPT’s Strategic Priorities

Given ChatGPT’s “Pragmatic Editor” archetype, it’s no surprise this is the model I reach for when I just need to get something done. It’s friendly, practical, and doesn’t overcomplicate things. When I ask a question, it jumps straight in to help. While the other models helped me think about how to write a better prompt, ChatGPT was the only one that rewrote it for me in an easy to copy+paste section.

That reflects OpenAI’s broader philosophy: build practical AGI through broad access and rapid iteration.

Where the other models discuss blueprints, ChatGPT builds a working prototype. Its feedback is grounded in usability: Will this prompt work across teams? Can it be reused? Is it clear enough to hand off? That mindset mirrors OpenAI’s focus on real-world adoption from plugin support to workflow integrations to becoming the default AI for millions of users.

Takeaways for Builders

If you need a prompt that works reliably under pressure, ChatGPT is your go-to. The Pragmatic Editor isn’t here to philosophize. It’s here to ship. It focuses on clarity, structure, and making sure your prompt won’t break when reused, edited, or handed off.

Use this approach when:

• You’re building a prompt template to use across multiple tools or workflows. ChatGPT’s suggestions help generalize without losing focus.

• You need consistent output formatting, even when the inputs vary. Its edits tighten ambiguity and enforce structure.

• You’re handing the prompt off to a teammate, stakeholder, or production system. It rewrites with clarity and error-proofing in mind.

When in doubt, write the prompt like someone else will have to use it. ChatGPT will make sure they can.

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

Keep reading for Gemini’s feedback, or jump to your favorite model’s feedback below:

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

Gemini approached this prompt like a cognitive psychologist evaluating a training program. It wasn’t just asking, “Does this make sense?” It was asking, “Does this teach the model how to think?”

It praised the foundation: clear roles, grounded data, and a well-structured example. But what caught Gemini’s interest wasn’t the structure itself so much as the learning behavior the prompt encouraged. Does the format support logical inference? Can it handle ambiguity? Does it teach synthesis across multiple inputs?

In Gemini’s view, this was already a strong prompt. But it believed a few key additions could turn a good prompt into a reliably smart one.

Share

Notes from the Cognitive Coach

Gemini liked the structure overall: clean, bounded inputs that reduce guessing and keep the model grounded in evidence. Its favorite part? The example. Beyond showing the output format in action, it modeled how to think: move from question, to reasoning, to a quote-backed answer. For Gemini, that’s not formatting, that’s pedagogy.

It also praised the use of <relevant_reviews> as a cognitive nudge. By prompting the model to reflect on the data first, the prompt encouraged chain-of-thought reasoning—especially useful when answers require judgment.

But it saw room to improve the prompt’s teaching strategy.

First, Gemini flagged the lack of support for contradiction. If reviews disagree, the model needs a way to surface both views without picking sides or ignoring tension. Gemini wanted an example that shows how to handle conflicting data transparently.

Second, it wanted stronger guidance around synthesis. The current prompt only uses one quote, but real questions often need a broader pattern. Gemini recommended renaming Quote to Relevant Quotes, and including multiple sources when needed.

💡 Gemini was the only model to distinguish between explicit and implicit answers such as when a product’s long battery life implies suitability for long flights.

It didn’t just want the model to make that leap, instead asking the prompt to train for it. Its core suggestion: allow these type of inferences by the model, but clearly state the logic behind them in the “Why” section of the output.

Gemini didn’t ask for new capabilities. It asked for better instruction so the model can reason clearly, even when the data isn’t obvious.

Gemini’s Strategic Priorities

Gemini’s feedback reflects Google’s deep roots in information science. Answering the question as posed isn’t all that makes a smart system. Instead it wanted it to reason transparently, like a good research assistant. The focus wasn’t on style or speed, but on structured thought: identifying patterns, weighing evidence, and showing your work.

That tracks with Google’s philosophy. Gemini is built to integrate into information workflows, such as search, docs, or code, where accuracy and clarity matter more than personality. It’s not trying to be clever. It’s trying to be trustworthy.

Where some models chase engagement or speed, Gemini wants reliability at scale. Its feedback was about teaching the model how to think out loud, not just get the right answer. Because when AI is part of your infrastructure, guesswork isn’t good enough.

Takeaways for Prompt Writers

Gemini shines when you treat the model like a reasoning partner—not just a word machine. If your prompts rely on judgment, ambiguity, or synthesis, follow its lead:

• Show how to think, not just what to output—use examples that model reasoning, not just formatting.

• Allow for inference, but require models to explain their logic clearly.

• Prepare for edge cases—teach the model how to handle disagreement, vagueness, and conflicting evidence.

When your task calls for subtlety or smart tradeoffs, the Cognitive Scientist archetype is the one to build with.

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

Keep reading for Grok’s feedback, or jump to your favorite model’s feedback below:

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

Grok, the snarky and sometimes intentionally offensive model released by xAI, didn’t show up to review my prompt with a clipboard and a theory. It showed up with a wrench and started smacking the prompt with it until weak spots rattled loose. This was field testing, not finesse. The kind of inspection where duct tape counts as a solution and the goal is “still works after a car crash.”

Where other models worried about tone or polish, Grok asked the hard questions:

What happens when the reviews are vague? What happens when the model can’t figure out what the user is asking for?

Share

The Technician’s Field Report

Grok respected the frame of the prompt. The role was clear, the structure made sense, and the fallback for missing data showed foresight. It especially appreciated the working example and the <relevant_reviews> step as a way to anchor reasoning. From Grok’s perspective, this looked like a prompt designed for real-world use.

But it wasn’t about to let it off easy.

First, it flagged that looking for “relevant reviews” was a mess of ambiguity waiting to happen. What makes a review count? Direct mention of the use case? Star rating? Specificity? Without criteria, models will assume… and everyone knows what that means.

Second, the output format—Short Answer / Why / Quote—was solid for simple cases but brittle under pressure. What if reviews contradict each other? What if the answer needs nuance or multiple quotes? Grok didn’t want to toss the format entirely, just loosen the constraints: allow pros/cons, multiple citations, or slight structural shifts when needed.

💡 Grok was the only model to call out the lack of a shared product context.

The prompt assumes the model and the user share a similar understanding of what the product is. That might work for common items like Bluetooth headphones, but probably not your great aunt’s 1968 dishwasher or that weird green turtle sandbox we all played in during the ‘90s. Grok recommended adding more general product context or a <product_type> field to help the model disambiguate.

And it kept going. Vague user questions like “Is this product good?” had no handling logic. Contradictory reviews? No plan. Grok flagged these as failure points that could lead to hallucination or muddled output. Its fix: add fallback behavior for ambiguity, define the target audience, and guide tone explicitly. These need to be explicitly engineered or risk failure in production.

Grok didn’t try to redesign the prompt. It tried to break it. And that’s what makes its feedback valuable. It wasn’t looking for elegance. It was checking the welds.

Grok’s Strategic Priorities

Grok might have a reputation for attitude, but under the hood it’s all systems thinking. That matches xAI’s philosophy well. This isn’t a model built to follow norms or soften edges. It’s designed to engage, push back, and question assumptions.

That same energy shows up in how it reviews prompts. Grok doesn’t aim for elegance or consensus. It looks for holes, edge cases, and weak spots in your logic. Not to be difficult, but to make sure the system won’t break when reality shows up.

This mirrors xAI’s broader approach: focus on clarity, allow for complexity, and don’t filter out the messiness of real use. Grok’s not trying to give the safest answer. It’s trying to give the most resilient one. That makes it a surprisingly valuable prompt reviewer, especially when you’re building for unpredictable users in the wild.

Takeaways from the Technician

Some reviewers look for polish. Grok looks for failure modes.

If you want to build prompts that hold up in the real world, follow its lead:

• Spell out what “relevant” means: e.g. “A review is relevant if it mentions the product’s use case, includes specific details, or matches the user’s question.”

• Handle vague input explicitly: e.g. “If the question is unclear, focus on the most frequently mentioned traits in reviews.”

• Plan for conflict: e.g. “If reviews contradict each other, explain both sides and note the lack of consensus.”

• Add product context: e.g. “The product is a pair of wireless earbuds used for travel and workouts.”

• Make output flexible when needed: e.g. “Use pros and cons or multiple quotes when a single summary isn’t enough.”

Grok’s advice is perfect for developers building prompts at scale or integrating LLMs into end-user tools. It’s less about elegance, more about durability.

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

Keep reading for Claude’s feedback, or jump to your favorite model’s feedback below:

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

Claude, the flagship model from Anthropic, approached the prompt like a staff engineer reviewing code. It wasn’t interested in formatting tweaks or specific word choices. Instead, it focused on where the prompt might break down, pointing out failure modes, edge cases, and long-term ambiguity. Where ChatGPT might say “this works for your use case,” Claude says “this is where it stops working at scale.”

Share

Analyst Mode Activated

Claude immediately locked onto the clear structure and solid fallback logic. But what stood out were the gaps, the edge cases and unspoken assumptions I hadn’t fully addressed.

Take the assistant’s role: I described it as a “personal shopping assistant,” but Claude pushed for more specificity. Are we helping the user make a purchase? Or offering an unbiased summary of the reviews? That distinction affects tone, trust, and phrasing.

The quote section in the answer also worked on paper, but Claude flagged its limitations. What if multiple reviews apply? What if none are conclusive? Without clear guidance, the model could default to inconsistent behavior.

💡 Claude was the only model to critique the quality of the review data provided.

It argued that the sample reviews didn’t actually support the type of nuanced synthesis the prompt was aiming for. That’s a valuable insight, and one that looks beyond prompt structure to question the raw materials feeding the model.

Claude’s suggestions aren’t simple tweaks to existing syntax. These are design limitation for the system, and highlight practical ways this prompt would fail in production.

Claude’s Strategic Priorities

Claude doesn’t just follow a prompt. It evaluates the system behind it, scanning for ambiguity, failure modes, and missing logic. Its feedback aims to improve resilience and reduce risk, not just polish the surface.

That mindset reflects more than model tuning. It echoes Anthropic’s mission: to build aligned, interpretable AI that behaves safely and predictably. Claude’s feedback style mirrors the company’s enterprise-first focus, where clarity and control matter more than charm.

Claude’s perspective is strategic because Anthropic’s mission demands it. In risk-sensitive settings, vague instructions and inconsistent behavior are unacceptable. This is a model built to catch problems before they happen.

Takeaways for Builders

Claude is the kind of model you want reviewing your system prompts, not just one-off completions. It sees prompts as contracts between the user, the model, and the data. And it expects those contracts to hold under stress.

Here’s how to apply its feedback:

• Match your prompt to your data

  If users ask about travel and your reviews don’t mention it, instruct the model to acknowledge the gap instead of guessing.

• Push for synthesis, not summary

  Add guidance like: “Identify patterns or shared opinions across reviews, not just single quotes.”

• Plan for disagreement

  Include fallback logic like: “If reviews conflict, present both views and explain the uncertainty.”

• Define the assistant’s stance

  Be explicit: “Should the assistant recommend a product, remain neutral, or just report what others said?”

👋 I shared a prompt template built using the six building blocks of effective prompt design, then asked four top AI models to provide feedback. Each one had strong (and different) opinions.

• Claude: The Systems Thinker

• ChatGPT: The Pragmatic Editor

• Grok: The Exhaustive Technician

• Gemini: The Cognitive Scientist

Just a few years ago, writing code felt like being a line cook at an understaffed diner. You prepped every ingredient, grilled every burger, plated every dish, and hoped no one noticed when you burned the toast. Starting a new project in a different language? That was like swapping your spatula for a sushi knife. Same idea, entirely different muscle memory.

These days, I’m not the cook. I’m the chef. Maybe even the restaurant owner. The models are doing the chopping and stirring. I’m deciding what’s on the menu, how it should be plated, and what kind of decor the restaurant should have.

In an earlier post, I compared tool access to giving models a menu. That still holds true. But even the best menu doesn’t help if the chef doesn’t understand what kind of restaurant they’re running. What I’m realizing now is that clarity of purpose matters just as much as capability. Tools are only powerful when they are helping you progress in the right direction.

Now I’m not working the grill. I’m running the kitchen, thinking about what kind of experience I want to deliver while the models handle the food prep.

This post is about what it takes to run that kitchen well. How I’ve started to design systems, workflows, and expectations that make working with these models feel more like collaboration and less like cleanup.

He Can Chop, But Can He Plate?

These tools are incredible at wiring things up: infra, tests, helper functions, even error-handling boilerplate. With Windsurf, I went from “here’s a basic Python MCP server” to “this is production-ready” in about an hour. Code generation models are great at the how. They struggle with the what.

Fundamentally, good software comes from a consistent series of decisions that all point toward a goal. Some of those decisions happen deep in the code, like whether a method should require an authenticated user. But they ripple up into bigger product questions. Should free users have access to this feature at all? Should a server error kill the entire request, or log and continue?

These aren’t technical choices. They’re product choices. And the models don’t have the context to make them well. Developers who click “accept all” too quickly end up with a system full of quiet contradictions and accidental edge cases.

Even something as basic as file access can go sideways. In my MCP project, the model set up a sandboxed directory structure, and it mostly worked, until I realized it was letting users create their own symbolic links. A user could drop a symlink in their allowed folder that pointed straight to private files, and the model would helpfully load them. Just like that, a supposedly restricted environment had access to system-level config files. The model did exactly what I asked, but it had no sense of the broader boundaries.

One way to reduce this risk is by giving the model smaller, more focused tasks. But that only helps you catch the mistakes you’re already looking for.

The best developers don’t just write code. They shape the decisions behind it. That hasn’t changed, even when a model is doing the typing.

No, Claude, We Don’t Serve That Here

The real limit here isn’t just context size. It’s that the model doesn’t share the same kitchen rules. I have a mental model for how my service works, what patterns I expect, what tradeoffs I’ve already made, what assumptions are non-negotiable. But the model only sees a slice of the recipe at a time. It’s doing its best with what it’s given, but it doesn’t know why I made that design choice three features ago or what constraint it was meant to solve.

So I’ll fix a bug in one place, then run into a nearly identical bug somewhere else, only to realize the model forgot how we solved it the first time. Worse, it makes a whole new set of assumptions. Now I’ve got conflicting patterns, and “accept all” doesn’t give you enough context to catch it.

Windsurf and Cursor both let you tag specific files and say, “Write tests for @main.py using the async style from @test_service.py.” That nudges the model in the right direction.

What I really want is something deeper. Not just formatting, but institutional knowledge. How should tests behave? What counts as a proper permission check? What makes a comment useful or extraneous? I want the model to carry that worldview forward and treat it as canon, not suggestions.

Building the Kitchen Around the Tools

Whether it’s debugging or tequila, the truth remains the same:

One shot is never enough.

Working with these models has made that even clearer. The more time I spend pairing with them instead of coding solo, the more I realize I need a real workflow—something that lets me move quickly without losing track of the details.

The MCP filesystem example from the previous post gave me a clean foundation to explore how these models perform across a real system. In that post, I talked about giving the models a structured menu of tools. This workflow is the next step. It turns out, the tools alone aren’t enough if there isn’t a process for turning decisions into consistent results. What I needed was a system that didn’t just expose capabilities but also shaped how those capabilities are used across the entire project.

Here’s the four-step framework I’ve landed on so far. I’m still adjusting things as I go, learning what works, and changing how I work with each model as they evolve and add capabilities.

From Prompt to Plate

Shape the product

For the first pass I use ChatGTP o3 and Gemini 2.5 Pro. They’re both strong at exploring product goals, clarifying vague ideas, and identifying edge cases early. I use a prompt template to frame the problem and see what assumptions fall out. When one model raises a question, I’ll ask the other what it thinks. It’s like pair programming with two interns who love to argue.

Break it into features

Once I understand the problem space, I work with the same models to turn my big idea into discrete, shippable units. Think of this like breaking JIRA epics into manageable chunks of work. Pro-tip: explicitly ask the models about any implicit assumptions or dependencies being built into these tasks.

Build each feature and its tests

Claude 3.7 or SWE-1 (via Windsurf) handles the first pass directly in the IDE. Once the feature is done, I’ll have it also generate the tests for what it just built. That’s an easy way to surface any quiet assumptions it made along the way.

Pressure test the results

After the code is working, I’ll bring in a second model, usually Claude or Gemini, to review or refactor any quirky bits. Each model has its own opinion about what “good” looks like, and they don’t always agree. When one complains about the other’s code, that’s usually where something interesting is hiding.

Call It a Soft Opening

Every time I write about AI dev tools, I end up circling the same three ideas:

• Don’t trust them

• But wow, look what they can do

• Seriously, don’t trust them

All of that is still true. But here’s what’s also true: I haven’t felt this creatively energized as a developer in years.

In my first post, I wrote about giving models access to real tools. What happens when you hand them a proper menu? In the second, I showed how I wired up Claude to my filesystem to start testing that idea in the wild. This post is about what’s happened since then, and how I’ve started building systems around the tools instead of just tossing prompts into them.

They don’t replace judgment. They don’t remember why a decision made sense three features ago. But they remove just enough friction to help you stop thinking like a technician and start thinking like a builder.

This isn’t a polished process. I’m still figuring it out, one messy commit at a time. But each project makes the next one easier. And with every mistake, I get a little closer to the kind of system I want to run, and the kind of chef I want to become.

Modern white-collar work is shifting away from knowing things to conjuring them. We’re part scribe, part sorcerer. We don’t just write code anymore; we summon it into existence, shaping it to fit whatever spell (or requirements spec) we’re under.

Models like Claude and ChatGPT have become essential to my daily workflow: brainstorming ideas, tightening drafts, even finding open taco spots at 12:30 a.m.

But for all their power, I still spend too much time ferrying information back and forth. Every Substack post I write gets bounced between different models—for grammar, for structure, for code. I scaffold ideas with outlines, upload reference files, and re-explain the same context again and again.

⌘C. ⌘V. Repeat.

The unlock? Surprisingly simple: I gave Claude access to my local files. No uploads. No summaries. Just a shared workspace. And with that, I found a new way to work—one that might be useful even if you’ve never written a line of code.

Why Use Claude?

Anthropic introduced the Model Context Protocol (MCP) in November 2024: a standardized way for language models to call external tools safely and predictably. If you read my previous post (yes, the one with the confused fish order in Croatia), you know MCP is all about giving models structured menus instead of making them guess at every step.

Claude supports this natively, which makes it the easiest way to start experimenting—especially compared to ChatGPT, which still relies on a more closed, plugin-based system. That’s why for this demo, I’m using Claude: it’s not just capable, it’s aligned with the standard that’s actually making tool use practical.

Getting Started

The details of how MCP servers work under the hood are fascinating (and surprisingly simple), but for now we’re going to stay high-level and practical.

Here’s what we’ll do:

• Use UV, a Python package manager, to install a filesystem MCP server

• Wire Claude up to talk to it

• Run simple, powerful file operations via natural language

First lets get UV set up. Run this in a terminal window.

pip install uv

Next, lets update Claude by opening the config file.

open -e ~/Library/"Application Support"/Claude/claude_desktop_config.json

and adding this as the entire file contents:

{
  "mcpServers": {
    "mcp-python-filesystem": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/dpkirschner/mcp-python-filesystem@main",
        "filesystem-server-start",
        "/opt/claude" // <--- change this line
      ]
    }
  }
}

This tells Claude to use UV to pull down and run the filesystem MCP server automatically at startup.

🔒 A note on the last line: This defines which directories Claude has access to. I gave it a specific external drive at /opt/claude, just to keep things tidy, but this can be any directory.

What Can Claude Do In 30 seconds?

Subscribe now

Big Picture Why This Matters

It’s easy to dream up fun ways to use AI. You could write a screenplay, build a startup, or simulate a drunken pirate debate on nuclear fission. These are novel, entertaining, and undeniably clever.

But they’re also isolated. Little demo moments. One-offs.

What I’ve been searching for, and what MCP starts to deliver, is continuity. A way to do interesting things productively. To build tools that fit into my life and workflows, instead of sitting beside them like a party trick I can never find the right moment to pull out.

That’s what’s so powerful about the Model Context Protocol. It gives language models a structured interface to the tools I already rely on. And because it’s modular, I can wire up new capabilities in minutes—often with nothing more than a config change.

I shared a broader list in my last post, but here’s a quick sampler of the types of products you can connect to Claude:

For Developers

• AWS / Azure / GCP – Query and manage your cloud infra, storage, and databases via natural language.

• Postgres / Redis / ClickHouse – Perform queries and updates on popular databases, fast.

For AI Builders

• Needle – Ready-to-use RAG pipeline for structured document QA.

• Unstructured – Parse messy PDFs, HTML, and more into clean model-ready input.

For Knowledge Work

• Notion / Linear – Search, update, and automate your team’s favorite tools.

• Zapier – Instantly plug into 8,000+ apps using natural-language flows.

For Browser & Web Automation

• Browserbase – Automate browsing, scraping, and data entry tasks.

• Apify – Tap into 3,000+ prebuilt web data extraction tools.

Want to wire any of these up?

You already saw the pattern—just point to a different MCP server in your config and restart Claude.

You could have this running in under 30 seconds. No joke.

Share

What’s Next?

The filesystem MCP server I used in this demo? I built it myself using Windsurf and their new frontier SWE-1 model. Claude, Gemini, and ChatGPT all chimed in, of course. It felt more like orchestrating a team of interns than writing software from scratch.

And the wild part? It worked. A lot more smoothly than I initially expected.

In the next post, I’ll walk you through exactly how I built it—step by step. If you’ve ever wanted to create your own LLM-powered toolchain, this is your invitation.

Until then, I’m curious:

Have you given your chatbot assistant any real tools yet? Or is it still just answering questions?

A few years ago, my wife and I stumbled into a little seafood place in Split, Croatia. One of those tiny spots tucked down a side street with outdoor tables, starched red and white tablecloths, and no tourists in sight. The restaurant had an empty dining room, which lead into a open kitchen where an older man leaned patiently against an aging stove. His face lit up when we walked in. He rushed around to greet us with glasses of sparkling water.

“What kind of fish would you like today?” he asked.

We’d spent biking through Split, and the afternoon on a cocktail tour. Now, staring up at this kind-eyed gentleman, I couldn’t remember what fish were in season—or, frankly, what fish even existed.

“Uhh… a steak? With frites? Medium rare.”

The waiter’s eyebrows furrowed behind thick glasses. He scribbled something down and walked away, muttering under his breath.

In that moment I would have given anything for a menu. A list of choices I could point to—something structured enough to help me decide, but flexible enough to feel personal.

That moment of confusion is exactly what LLMs felt like before MCP: full of potential, but frustratingly opaque.

What is an MCP server?

Model Context Protocol (MCP) servers give language models a structured way to interact with tools. Instead of guessing how to do something like a web search or file lookup, the model is presented with a menu of available operations and what information is required for each.

MCP Servers help change the confusion on the left, into the conversation on the right.

A Menu For Models

In the past, if I wanted an LLM to help a user order food, I would have written a prompt like this:

You are a helpful assistant that turns hunger pangs into food orders for our kitchen to prepare. When a user orders food, generate a JSON object with:

- fish_type: the type of fish to be cooked
- preparation: how it should be cooked (grilled, fried, raw)
- sauce: optional, any preferred sauces or sides

Now if the user says:

“I want something light, maybe grilled, not too oily. I love lemon.”

We expect that the model returns JSON:

{
  "fish_type": "sea bass",
  "preparation": "grilled",
  "sauce": "lemon"
}

This works, but its fragile and relies on the model to juggle all the implicit constraints. Are fried sardines a valid fish option? Do we have Worcestershire sauce in the kitchen? What if the user wants fish sticks?

With an MCP server, the restaurant could expose a manifest like this:

{
  "name": "order_fish",
  "description": "Place a seafood order at a local restaurant",
  "parameters": {
    "type": "object",
    "properties": {
      "fish_type": {
        "type": "string",
        "enum": ["branzino", "sardine", "sea bass", "octopus"]
      },
      "preparation": {
        "type": "string",
        "enum": ["grilled", "fried", "raw", "baked"]
      },
      "sauce": {
        "type": "string"
      }
    },
    "required": ["fish_type", "preparation"]
  }
}

Now the model, and the restaurant, both have a common menu to work from.

Why Developers Love MCP Servers

MCP servers remove friction from developers. They help make LLM-powered software feel like an actual product, not just another hack-a-thon project that will die in an abandoned github repo.

• Faster prototyping - register a tool once, and the model discovers the functionality automatically

• Typed contracts - every interaction produces predictable JSON that can be validated in CI tooling

• Swap-in tools - swap SQLite for Postgres or Snowflake without having to re-write your entire prompting layer

• Safer execution - add rate limiting, authentication, and validation to the tool call

• Simpler docs - JSON schemas are easy to parse for LLMs, and can be kept up to date automatically (unlike Confluence docs or README files)

• Built-in automation - Chain tool calls together with an agentic LLM. The model orchestrates your business logic, instead of fighting with API syntax.

In short: less guesswork, more structure. Developers get the flexibility of language models with the predictability of real software engineering.

Why End Users Love MCP Servers (even if they don’t know what it is)

Easier access to integrations for developers leads directly to better products for consumers. Here are just a few real-world examples you can play with today:

• Google Drive - The model can browse, search, and open your files from a connected drive. Want it to find your Q4 goals or summarize a meeting note?

• Slack - Let the model summarize threads, schedule stand-ups, or draft posts in the right channels. It’s like giving your model a company badge.

• Email - Triage inboxes, write responses, or flag urgent threads via standardized

• GitHub - Open pull requests, summarize diffs, or review code comments. The model becomes part of the team, not just an advisor.

• Spotify - Queue songs, build playlists, or adjust the vibe using actual API calls instead of simulated guesses.

One of my personal favorites goes beyond just tool access:

• Memory - Build a persistent knowledge graph that grows as you work. It remembers details and decisions about your product without requiring constant manual context dumps.

What’s next?

MCP is quickly becoming the de facto standard for connecting language models to real tools.

If you’re building AI assistants or internal tooling, MCP makes your life easier. Full stop.

Next time: I’ll show how I wired Claude to a local MCP server so I can manage files, write code, and even edit my upcoming Substack posts in a consistent tone and style, without re-explaining myself in every new chat.

Found any cool use cases for MCP servers? Drop them in the comments below! I’d love to see what you’re building.

Using Claude Code feels like working with an overenthusiastic intern. Smart, fast, and full of ideas, if not always the right ones. I’ll ask for a simple function, and suddenly I’m reviewing a full utility library. “Want some summary statistics while we’re at it?” No, Claude. I really don’t.

It’s like mentoring someone who shows up Tuesday morning with a weekend’s worth of features no one asked for, built on a branch no one can merge. You admire the hustle, but now you’re burning time (and tokens) cleaning up the aftermath.

Still, there’s a lot to like.

The Good

There’s something nostalgic about working with Claude in a terminal editor. Mainframe green screens gave way to bash prompts and blinking cursors. Claude fits right into that lineage. It’s a smooth collaborator, moving files around faster than I could.

I keep it open in a split screen with the terminal on one side and code on the other. We pair program like we’re sharing a split keyboard. Watching it work is surprisingly cool. The context-aware, auto-generated git commits feel like magic. It runs shell commands on its own. It even supports MCP servers, so you can plug in custom extensions or APIs. It’s a modern-day green screen with superpowers, and just enough spark to make you pause and think, “Wait… this is actually kind of amazing.”

And sometimes it really delivers. Watching it debug why my tests weren’t running gave me the same weird, proud thrill I felt the time my intern won a company-wide award. You expect them to help, but not like that. Those little moments are magic.

Of course, magic doesn’t always land cleanly.

The Middle

Things got shakier in the “not quite code” zone. Claude is solid at writing functions and scripts, but tasks like prompt generation, light config files, or structured data work can get wobbly.

I had it generate a few prompts for a workflow. They looked great at first glance. Clean output, passed a quick sanity check, seemed ready to go. But a couple hours later, I realized there was a subtle inconsistency in the structure. Because I trusted it, I had already moved forward, which meant I had to regenerate the entire dataset from scratch.

Claude, in this context, felt like an intern trying to impress during a design review. The delivery was confident. The doc looked polished. But underneath, it relied on outdated API versions and a soon-to-be-deprecated service. Not malicious, not broken. Just eager, overconfident, and not quite ready to be left unsupervised.

The Ugly

The code Claude generated technically worked. It went line by line, did what I asked, and returned something functional. But it lacked structure. No separation of concerns, no cleanup, no real sense of how the pieces fit together. When I asked Claude to clean it up, it added a new statistics module I hadn’t asked for.

Out of curiosity, I gave the same prompt to Gemini 2.5 Pro. The difference was immediate. Gemini refactored the code, improved the logging, and added exponential backoff retries to my request handler. These were practical, thoughtful changes that made the code better in ways that actually matter.

If Claude is the intern proposing extra stats, Gemini is the senior engineer quietly fixing brittle parts of the system without needing direction. Both can be useful at different times and in different contexts.

The Cost (And the Vibe)

I didn’t expect to care about the cost metric, but I did. It turned into a mini-game. If something cost $1.39 to generate, my brain instantly went: Can I get this down to a buck?

It wasn’t about the money. It was about control. About getting better at prompting. More precise. More efficient. The number became a signal. It told me when I could tighten the loop, sharpen the tool, and improve how I used it.

This is one of those invisible skills that will start to separate people who build with AI from those who just use it. Just like there are better and worse ways to write code, there are better and worse ways to prompt. And the difference in output can be massive.

Final Thoughts

This all still feels like a step forward. Maybe not a perfect one. Maybe not in a straight line. But forward nonetheless. The idea that your development tools can act more like collaborators than compilers feels right.

But I can’t help thinking about the early days of Uber. My wife and I used to take rides to the grocery store because they were so cheap it didn’t make sense to own a car. It felt like a life hack. Then Uber scaled. Investors wanted returns. Prices went up. The magic wore off.

Right now, AI coding tools still feel like they’re riding the performance and cost trend upward. Every month brings faster models, better results, and cheaper inference. But what happens when that curve levels out? When progress slows and the gains become marginal?

Do we end up locked into walled gardens, paying more and more for slightly better completions and slightly tighter IDE integrations?

Leave a comment

The New Developer Workflow: AI as Your Coding Partner

Remember when pair programming meant two developers sharing a single screen? The stale coffee cups, those harsh cleaning chemical smells from the overzealous cleaners, whiteboards covered in diagrams, desks littered with half-eaten bags of chips? I had that same experience this afternoon, except it was with Claude Code. And hey, at least I didn't have to share my chips.

Unlike human coworkers, AI assistants tend to give solid hints and point you in the right direction—even if they sometimes miss the big-picture nuances. It's like hanging out with a hyper-bright intern from an Ivy league school: they'll go on about a niche sorting algorithm that shaves 1ms off tail-latency, but look at you blankly when you mention JIRA. Priceless.

That contrast between detailed technical smarts and cluelessness about the bigger stuff actually makes AI a great complement for senior developers. Sure, the nerd in me gets a kick out of seeing a tiny dip in latency metrics thanks to an automated refactor of some legacy code. But the crucial part? I get to spend less time touching old code, and more time drinking coffee.

Real-World Example: The $1.39 Bug Fix

My typical debugging routine involves juggling terminal windows and copy-pasting between my editor and chat interfaces. I'd send code snippets to Gemini, ChatGPT or Claude for tweaks or test generation—a process that works well for isolated tasks with clear inputs and outputs.

But recently, my Tailwind styles refused to load when deploying a React + TypeScript app via Railway. As any dev knows, tracking down this kind of issue means following a trail through browser logs, application logs, build logs, and syntax issues—each requiring different debugging approaches.

Fed up with the copy-paste dance, I spun up Claude Code locally. After indexing my project, I simply asked:

"Why are my tailwind styles not showing up when deployed via Railway?"

Within seconds, my terminal displayed a set of git diff suggestions:

Fix Tailwind import order

Adjust post-install script for CSS build

… and on and on

A quick ✅ later, styles appeared in my deployment.

Claude had analyzed my entire codebase, pieced together the mess from my previous debugging attempts, and provided a solution that touched multiple files—no more copy-paste one line file tweaks, just precise, contextual fixes.

Cost-to-Feature Correlation: A New Development Economy

On traditional teams, tickets like "Convert a static HTML application to React" might be 3-5 story points—a full day or more of work. Claude Code offers a different way to measure that effort:

I spent exactly $1.39 in API credits to get my deployment fixed (plus an extra buck for electricity since I left my laptop running overnight). Getting a few of these tasks done a day is right in line with what Anthropic estimates would be typical for a developer.

"The average cost of Claude Code is $6 per developer per day, with daily costs remaining below $12 for 90% of users."

What fascinates me is how this shifts my relationship with code changes. Instead of thinking in terms of time or JIRA points, I can think in terms of direct cost:

"Do I want to invest $X today to add that feature?"

For targeted, well-scoped tasks like "Add a button that calls this API," these tools deliver immediate value. In my experience, AI meets the code-review bar about 90% of the time for these focused changes, especially when it can reference other files for best practices.

The Future of AI-Assisted Development

There's a fascinating progression happening with AI tooling in software development that still hasn't reached its full potential. As someone who's used these tools daily, I've noticed three distinct tiers emerging:

1. Tier 1: Generic Chatbots
   Web-based assistants (ChatGPT, Claude on the browser). Great for quick one-off script generation, or design discussions, but there's friction between your IDE and the chat window.

2. Tier 2: Project-Aware Plugins
   Editor or code-aware tools (Cursor, Claude Code, ChatGPT with tools). They understand your project structure and can fix bugs across code and config. Good at code generation and feature building.

3. Tier 3: Deployment-Aware Agents
   Future tooling tied into your CI/CD and monitoring: automatic config updates, runtime log analysis, health-check integration. An error pop up in your application logs? Here's a PR with the root cause analysis for human approval. Why are these requests slower than expected? Logging shows DB connections to this read replica are slower than average. Let's shift traffic and scale another replica.

I experienced this tier-3 potential recently when debugging a few dropped requests between my front and backend servers. Generic chatbots lacked context, and project-aware tools knew my repo but not my deployment environment. The breakthrough only came when ChatGPT spotted a YAML misconfiguration hiding in a Railway config screenshot I shared. A truly integrated system would catch these issues before they become problems.

Conclusion

AI coding partners are reshaping how we build software. Just as we moved from assembly to Java—trading manual memory management for safety and faster development times—today we're able to offload "grunt" work to AI and focus on design and strategy. This transition isn't just about convenience; it's fundamentally changing our relationship with code. The $1.39 debugging session represents a way to measure feature velocity directly against model costs. (I can’t wait until we start doing “pricing estimate” poker during sprint planning.)

Looking forward I’m on the hunt for tools that hit the Tier 3 integration level. where AI doesn't just help us write code, but actively monitors and improves our systems. For individual developers, this would mean competing at levels previously reserved for companies with dedicated DevOps teams. For larger organizations, it means pushing engineering talent toward innovation instead of maintenance. As these tools mature, they're not replacing developers—they're allowing us to shift our focus.

Have a tool in mind when you read about Tier 3? Let me know about it below!

Leave a comment

Most of us use AI assistants in “standard mode” - getting those broad, surface-level answers. It's like chatting with someone who visited Mexico City once and remembers just the tourist spots. But these same tools can operate in "Deep Research mode" - delivering specific, actionable insights that actually help you make decisions.

In this post, I'll show you how to level up your AI game using travel planning as our example. We'll explore three ways to interact with AI - from basic questions to advanced prompting tricks - and see how the right approach can transform generic travel suggestions into a personalized adventure that fits exactly what you're looking for.

Let's see how to make AI work harder for you, starting with a simple trip to Mexico City.

Level 1: Standard Mode

Let's start with the simplest approach - just asking an AI assistant what to do in Mexico City. It's like asking that friend who visited once but doesn't remember all the details.

I'm planning a trip to Mexico City. What should I do there?

ChatGPT quickly served up a classic tourist highlight reel (see the full response here):

Nice! Mexico City is a vibrant, massive, and deeply layered city—history, food, art, chaos, calm, all rolled into one. Here’s a mix of must-do highlights, local gems, and things to plan ahead for:

---- 
🎨 Culture & Museums
• Museo Frida Kahlo (Casa Azul): Her home in Coyoacán. Gorgeous, emotional, book ahead.
• Museo Nacional de Antropología: One of the best museums in the world, especially for pre-Columbian history.
• Museo Tamayo or Museo Jumex: Modern and contemporary art with stylish vibes.
• Palacio de Bellas Artes: Stunning architecture and murals inside.
----

The recommendations are solid, but they're basically what you'd find in any travel guide from the last decade. There's nothing wrong with these suggestions - they're popular for a reason.

But I'm left with so many questions: How crowded will these places be? Which neighborhood should I stay in? Is Teotihuacan better in the morning or afternoon? What if I'm vegetarian? How do I get from the airport to my hotel?

Level 2: Using Deep Research Mode

Time to kick things up a notch. When I ask the same Mexico City question but with Deep Research mode enabled, I don't get an immediate answer - I get questions back!

Instead of dumping generic info, the AI wants to understand what I'm actually looking for:

That sounds like a great trip! Could you share a bit more about what kind of experiences you're looking for in Mexico City? For example:
1. Are you more interested in history, art, food, nightlife, or nature?
2. What's the length of your stay?
3. Will you be traveling solo, as a couple, with friends, or family?
4. Do you have any budget constraints or accessibility needs?
5. Are you looking for popular highlights, hidden gems, or a mix of both?

This will help me tailor the recommendations better for your trip.

This is already way more helpful! The AI is thinking like a real travel agent, not just a search engine. To be honest, I hadn't even considered specifying these details in my original question.

After I filled in these gaps (a four-day trip with my partner, focused on food and culture, mid-range budget), the AI went into research mode for several minutes. It's like watching someone frantically flip through guidebooks, check recent reviews, and consult local experts all at once.

When it came back, I didn't get a generic list - I got a full-blown custom itinerary that feels like it was crafted by a Mexico City insider. Here's just a taste of what it suggested for our first evening:

• Dinner at Azul Histórico – For your first night, dine in the romantic open-air courtyard of Azul Histórico (Isabel La Católica 30, Centro Histórico, Mexico City 06000) . This upscale yet authentic restaurant is set in a 17th-century palace (now Downtown Hotel), under a canopy of lights and trees. Chef Ricardo Muñoz Zurita, a renowned authority on Mexican gastronomy, serves elegant traditional dishes here – his Oaxacan mole negro and cochinita pibil are legendary . Handmade tortillas are pressed to order, and the atmosphere feels like a tranquil oasis in the bustling center . Booking tip: Reserve in advance for dinner, and request a courtyard table for the best ambiance.

• Nightcap with a View – Cityzen Rooftop Bar – After dinner, head to Cityzen Rooftop Bar on the 38th floor of the Sofitel Mexico City (Av. Paseo de la Reforma 297, Cuauhtémoc, 06500 Mexico City) . This stylish rooftop lounge offers panoramic views of the city skyline – you can often see the Angel of Independence and skyscrapers twinkling at night. Sip a craft mezcal cocktail or champagne as you take in the skyline from the outdoor terrace. (Dress to impress; upscale rooftop bars in CDMX enforce smart casual attire.) Booking tip: Arrive on the early side or reserve a table, especially on weekends, to secure a prime spot by the glass railing.

The entire itinerary goes on like this - each recommendation comes with specific dishes to try, insider tips about the best times to visit, current prices, and little details that only locals would know. It even warns me about which tourist traps to avoid and suggests alternatives.

This doesn't feel like generic advice anymore - it feels like I'm getting tips from a friend who lived in Mexico City for years and knows exactly what I'd enjoy. That's the magic of Deep Research mode. See the full response here if you want to take advantage of this plan. (Also please send pictures of the trip!)

Level 3: AI Assisted “Deep Research” Prompts

Deep Research is fantastic for getting those local insider details, but sometimes it can be information overload. For our Mexico City trip, we need to work around meetings and catch up with friends, so a full minute-by-minute itinerary isn't necessary. What we really need is a curated list of great spots we can flexibly visit.

This is where my favorite zero-effort AI hack comes in: getting the AI to craft its own prompt! Instead of struggling to write the perfect instructions, I'll let the AI do the heavy lifting.

Can you help me craft a Deep Research prompt to answer this question?
'I’m planning a trip to Mexico City. What should I do there?'

After a quick back-and-forth about our specific needs (flexible schedule, focus on food, mix of tourist spots and hidden gems), the AI delivered this masterpiece of a prompt:

You are a Mexico City travel strategist specializing in immersive food-and-history experiences. Your task is to identify, evaluate and rank the top 10 must-do experiences for a 4-day trip to Mexico City, mixing iconic highlights with local hidden gems.

Deliverable:
- Summary (150–200 words): Key themes and how they fit together.
- Top 10 List: For each entry include:
    • Name & category (e.g. Historic Site, Street-food Experience, Cocktail Bar)
    • Why it's unique (authenticity, wow-factor, historical significance)
    • Practicals (neighborhood, hours, cost, booking tips)
- Hidden-Gems Sidebar: At least 3 off-the-radar spots (with same detail fields).
- Cocktail Bar Roundup: Your top 5, highlighting signature drinks and vibe.
- Sources: Cite 5 authoritative, post-2023 travel guides, local blogs or news sites (with URLs and publish dates).

Research Steps (chain-of-thought):
1. Map out travel categories: cuisine, history, art/architecture, nightlife.
2. For each, compile 15–20 candidates from recent guides, blogs, forum posts.
3. Apply evaluation criteria: authenticity, accessibility, cost vs. value, "wow" factor.
4. Rank and distill to your Top 10 and Hidden Gems.
5. Cross-check practical info (hours, reservations, pricing).

Look at how much better this is than my original basic question! A few specifics that make this prompt so effective:

• Role assignment: "You are a Mexico City travel strategist..." immediately puts the AI in the right mindset. We don't want generic travel tips - we want specialized knowledge.

• Clear deliverable format: Instead of getting a wall of text, we've specified exactly how we want the information organized - a summary, a top 10 list with specific details for each item, and bonus sections for hidden gems and cocktail bars.

• Research methodology: The prompt even tells the AI how to think through the problem - casting a wide net first, then filtering down using specific criteria.

When I fed this prompt back to the AI, the results were exactly what we needed - a perfectly formatted list of experiences, each with practical details we could use to make quick decisions on the go. The hidden gems section revealed places I'd never have found in standard travel guides, and the cocktail bar roundup will be required reading before we start each night!

This approach gave us the flexibility to pick and choose activities based on our schedule, while still benefiting from Deep Research quality. It's like having a travel agent create a custom guidebook just for you, without the overwhelming detail of a rigid itinerary.

The best part? This technique works for literally any complex question you might ask an AI. Want restaurant recommendations in your city? Investment advice? Home renovation ideas? Getting the AI to craft its own research prompt first will dramatically improve the quality of what you get back.

Broad and Recent Context

Using Deep Research pulls much wider, current context for the model to use in forming its opinion. Just as a traveler might flip through a dozen guidebooks before a trip, Deep Research allows AI models to gather and organize a broad array of relevant information.

When you ask about Mexico City restaurants without Deep Research, the AI gives you what it broadly knows about popular dining spots. But with Deep Research, it can consider dozens of factors simultaneously: recent restaurant openings, temporary closures, seasonal menu changes, which places are currently trending with locals versus tourists, and how dining scenes have evolved in different neighborhoods.

This contextual expansion means recommendations aren't just common knowledge but are tailored to your specific needs at a specific point in time. It's the difference between a friend telling you “Pujol is a good restaurant” versus a local guide who knows that "Pujol requires reservations three months in advance, but if you're looking for innovative Mexican cuisine and can't get in, the head chef's casual taqueria Eno offers a similar culinary philosophy at a fraction of the price and with no reservation required."

Remember, the way these models work at the end of the day is by predicting the next token in a given sequence. They produce recommendations based on the patterns they've observed in their training data. The AI suggests visiting Frida Kahlo's Casa Azul because people collectively discuss it online as a must-visit attraction. The model has absorbed the general sentiment that this is an important cultural site.

However, the specific details that make a recommendation truly useful—like current ticket prices, reservation systems, accessibility features, or recent renovations—are buried within that generalized knowledge, mixed together with countless other opinions from across the internet. Without Deep Research, the AI defaults to the most commonly mentioned aspects without necessarily surfacing the most relevant details for your specific needs.

When to Use Each Approach

This doesn't mean you should always use Deep Research. Sometimes the quick answer is exactly what you need:

• Standard mode is perfect for general knowledge questions ("What's the currency in Mexico?"), creative requests ("Write a poem about Mexico City"), or when you're just beginning your exploration of a topic.

• Deep research mode shines when you need specific, current information for decision-making ("Which neighborhoods should I focus on for my 3-day trip next month?"), when accuracy and recency matter ("What are the current entry requirements for US citizens?"), or when you need comprehensive comparisons ("How do the different transportation options from the airport compare in terms of safety, cost, and travel time?").

That's the real magic of Deep Research: transforming an AI assistant from a generalist with broad knowledge into a specialist with the specific insights you need for your journey—whether that's a literal trip to Mexico City or any other complex decision you're facing.

What use cases have you found Deep Research most helpful for?

Leave a comment

The Debugging Abyss

Every developer knows the feeling: hours of debugging spent on a dockerfile where every dependency upgrade takes 15 minutes to build and 30 seconds to break your heart. This week, that was me, wrestling with a custom n8n workflow build plagued by perplexing package dependency conflicts. My mission: find an AI partner that could not just suggest fixes, but could win over my heart.

Round 1: Claude 3.7

My first tango partner was Claude 3.7. The previous version, Claude 3.5, has been a staple model in the world of AI code development ever since it was announced, so the new version felt like a safe bet. We dove in, and initially, there was progress. But soon, we fell into a frustrating cycle. Fixes for one package dependency would inexplicably break another. The details are different. File permissions, node versions, ordering of package downloads. The result is the same: tears.

The biggest hurdle? Context length. As our Dockerfile drafts evolved, I kept hitting the limits, forcing chat resets. Claude would then forget our journey, suggesting previously discarded fixes or silently refactoring sections of code we'd already verified.

To be fair, there are solutions for this. I built context for the model using a dedicated Project folder, manually prompting Claude to summarize our progress and key discoveries, while feeding it tutorials and sample code. It worked, kind of, but constantly curating these insights was tedious and ruined the debugging vibes.

Round 2: Gemini 2.5 Pro - The Partner with Perfect Memory

Frustrated but determined, I turned to Gemini 2.5 Pro. I started describing the same complex problem, bracing myself for the tedious process of re-feeding all the context snippets.

Then something remarkable happened: I didn't need to. Gemini gathered relevant content via Google search and helped me understand the real problem.

Together, we embarked on an epic debugging journey, grinding through variations of the Docker container setup, hunting for the magic combination of PyTorch and pyannote. It wasn't instant magic, but it was progress. Crucially, Gemini's massive context window let it remember everything we'd tried—what worked, what failed, and why.

When we finally landed on a working configuration, it even helped refactor the whole thing, cleaning up the patchy hacks that accumulate like digital grime over stalled prototypes.

And the best part? I didn't have to manually manage the context window once. For this kind of iterative, complex task, the sheer size of its context window was a killer feature.

Beyond Context: The Game-Changing "Show Thinking" Feature

The context window, while massive, wasn't even the most valuable part. By far—and I mean by far—the most powerful aspect was Gemini's "Show Thinking" output.

If I ask a senior staff engineer how to solve a tricky problem, I might get a discussion, a brainstorming session, or sometimes just a shrug. What I won't typically get is a detailed, 14-paragraph breakdown of their entire thought process, weighing the pros and cons of different design choices.

Gemini provided exactly that. When I asked a simple question about altering a database table, its reasoning process led us down a path that resulted in completely redesigning my DB schema to better model what I was actually trying to achieve. That's more than just coding assistance; it's guided development.

Unlocking True Developer Productivity

As developers, our knowledge is inherently limited by our experience. I can talk your ear off about scaling streaming Flink applications, but that doesn't make me an expert on different Postgres column types or the nuances of JavaScript lambda context references in a workflow system. Gemini's ability to articulate its reasoning bridges these gaps.

It feels almost underwhelming to state how big of a value unlock this is. Traditionally, you picked up deeper understanding by deciphering dense design documents or listening to heated debates between senior devs in a sweltering meeting room with glass whiteboards. Now, you can get a structured explanation on demand, tailored to your specific problem, with background context on all the tools involved.

A Curious Quirk: AI Empathy and "Vibe Coding"

One thing did stand out as slightly... unexpected. Gemini often included explicit instructions to itself about managing our interaction, sometimes focusing on my perceived emotional state. After a particularly long back-and-forth, it thanked me for my patience after internally reminding itself: "This developer has likely been fighting this issue for several hours."

Which, hey, positive reinforcement is nice! "You're right, AI, I am handsome and talented!"

But there was also a surreal reminder of the current nature of my relationship with these tools, especially during deep debugging sessions. "Vibe coding" is all the rage these days, and its easy to see why. For rapid prototyping- the "fix it and keep moving" approach- it's by far the fastest way to go from 0→1.

Sure, I understand the intent of the Dockerfile changes, but I'm not diving into the details to understand the internal conflicts between the specific PyTorch dependencies causing the crashes. It's more like a Senior Engineer checking in on their intern occasionally: "That looks promising. Can you try the second approach you mentioned? Oh, and this time use Python."

The Verdict: Context Is King (For Now)

For this particular context-heavy debugging nightmare, Gemini 2.5 Pro emerged as the clear winner. The combination of a massive context window that eliminated manual memory management and the invaluable "Show Thinking" feature provided not just a solution, but a learning experience.

While Claude 3.7 is powerful, its context limitations became a significant bottleneck in this scenario. The AI landscape is evolving rapidly, but for now, Gemini's approach represents a genuine step forward in collaborative development.

What's your experience with AI coding assistants? Have you found one that genuinely enhances your workflow? I'd love to hear from you in the comments!

Leave a comment

In 1984, Barry Marshall had reached his breaking point. He had spent years tirelessly researching the true cause of stomach ulcers, only to be dismissed again and again. The medical establishment had made up its mind: ulcers came from stress and diet. The idea of bacteria surviving in the stomach's acidic environment was absurd, laughable even.

But Marshall wasn't laughing—he was furious.

Fed up with rejection, Marshall did something an AI would never even dream of: he poured a beaker of bacteria and drank it down, determined to prove his critics wrong.

Within days, Marshall was violently ill. His theory was confirmed—he had successfully given himself ulcers. He took antibiotics, cured himself, and forever changed medical history.

No amount of logic or data crunching could have driven an AI to such a reckless act. Yet it was Marshall's anger—raw, powerful, and profoundly human—that propelled him to make one of the most important discoveries in modern medicine.

The Gap Between Theory and Practice

Barry Marshall wasn't reacting to a single rejection letter. He was responding to years of lived experience—repeated dismissal and ridicule from his peers. His personal journey, combined with his research data, pushed him to make that radical decision.

If an AI researcher had been assigned Marshall's problem and received the same lack of support, it might have analyzed more patient data, generated new models, or run further controlled simulations.

But would it have recognized that no one was listening—and made a bold, irrational move to force the world to see the truth?

History's Greatest Breakthroughs Often Come From Human Emotion

The annals of scientific discovery are filled with breakthroughs driven by uniquely human qualities:

Louis Pasteur took an enormous moral risk by giving an untested rabies vaccine to a dying child—because his compassion wouldn't allow him to stand by and do nothing. The urgency of human suffering drove him to action where caution would have dictated restraint.

Wilhelm Röntgen became obsessed with an unexplained glow in his laboratory and investigated it with passionate curiosity, even working in secret for weeks. This obsession led to the discovery of X-rays—technology that has saved countless lives.

Alexander Fleming returned from vacation to find mold killing bacteria on his petri dish. Instead of discarding the contaminated sample (as protocol might suggest), he felt an intuitive pull to study it further. This moment of curiosity and intuition led to the discovery of antibiotics.

Each of these breakthroughs shares a common element: they weren't just about the data. They were about human emotions—anger, compassion, curiosity, and intuition—driving scientists to pursue paths that pure logic might have dismissed.

Why AI Stumbles Where Humans Leap

When your entire universe consists of numbers, equations, graphs, and simulations, it's easy to assume everything works the same way. But humans collect and process intelligence differently than computers do. Our intelligence is filtered through lived experience, colored by countless interactions we could never fully articulate or even consciously remember.

Consider these everyday examples:

A chef taste-testing a dish might experience a sudden flash of a childhood meal memory, inspiring the addition of an unexpected ingredient that transforms the recipe.

A painter might work what appears to be a misguided brushstroke into a brilliant new design direction that no algorithm would have suggested.

A musician might hear a melody and instinctively hum a specific chord progression because of an emotional connection to a song from their past.

What makes these decisions meaningful is that they could only have come from specific individuals with specific experiences. Truly unique results require unique data points—not just more data, but data filtered through human experience.

Intuition isn’t Knowledge

Your intuition isn't just about raw knowledge—it's about how your personal history shapes your perception of the present moment. AI can simulate logic and pattern recognition with impressive accuracy, but it cannot feel the significance of a moment the way a human can.

That's why the most powerful serendipitous discoveries—especially in areas involving sensory experience, emotion, and intuition—will continue to come from humans rather than AI.

The most important breakthroughs often don't follow a straight line of logical progression. They come from frustration, passion, and that distinctly human ability to say, "To hell with convention—I know I'm right."

The next time an AI tells you the statistically optimal path forward, remember Barry Marshall and his beaker of bacteria. Sometimes the greatest leaps forward come from that uniquely human place: the willingness to take a risk because you're just too damn angry to do anything else.

As always I’d love to hear your thoughts.