I keep hearing the same worry: AI is going to make developers dumber, because it means they don't have to think as much. And honestly? If that matched my experience, I'd be sounding the alarm too. I have no interest in tools that atrophy my skills.

But here's what's actually happening: I'm thinking more intensely than ever before. The speedbumps are gone, but the thinking? That's cranked up to 11.

What I have always loved about programming is deep thinking about the problem at hand and the best way to solve it. If AI took away the part where I think, I'd hate it. But it's doing the opposite—and because of that, somehow I now have a way to love this work even more than I did before.

The Value of Thinking Before Coding

Every great programmer I've known shares one trait: they think deeply before they code. Not sometimes. Every time they're solving a new problem, working in unfamiliar territory, or doing something tricky.

I've tried explaining this value for years, usually to skeptical audiences. At Jane, we introduced RFCs to handle scaling teams. Some teams embraced it, tailored it, and now ship incredibly fast. Others still ask: "Why can't I just start hacking?"

Here's what I noticed about the teams where it clicked: they turned software design into a collaborative activity. They work through problems together—business needs, existing constraints, maintainability concerns. This takes time, sure, hours spread over days. But by the time they start coding, they're flying.

One engineer told me: "After implementation planning, writing the code feels like a formality."

That quote stuck with me. Because here's the thing: When I use AI, every coding session feels like I'm on a high-performing team.

Building On What We Know

I keep coming back to this principle when developing AI workflows: how do we solve this problem today with humans? AI changes the game significantly, but it doesn't rewrite the rules. We've spent decades learning these patterns—don't throw that knowledge away, adapt it.

When a good engineer picks up a new ticket, they start with discovery. They pull out a notebook, jot down initial thoughts and questions after reading the ticket. They poke around the codebase, ask questions. Take more notes, hunt for answers. It's messy but systematic.

Once satisfied with discovery, they create an implementation plan. Maybe formal checkboxes, maybe bullet points, maybe paragraphs—the format doesn't matter as much as the thinking.

During implementation, sometimes everything goes to plan. Great! But when it doesn't, here's where great engineers separate themselves: they immediately revisit their planning artifacts. They page everything back into their minds and adapt quickly to what they missed. Any time they may have lost from doing that upfront planning is massively made up here. When they have to roll with the punches, they do it quickly, easily, and well.

This is the pattern. Discovery → Planning → Implementation → Adaptation. And its important to understand, this is not going to feel faster at the start, it will feel faster at the end. The performance compounds, with quality going up.

Here's the thing: AI doesn't break this pattern—it amplifies every step. And the same compounding effect not only exists, it gets magnified.

AI Tools Change The Math

I've been advocating for planning for years. But with modern AI agents, planning gets easier and faster, while its compounding value goes up dramatically.

I've built and refined a set of prompts over months of practice. They're more sophisticated, they account for a lot more than what I'm sharing today, and I'm not ready to publish them quite yet. But through this blog, you'll learn the principles to build your own. My prompts are great, but just like an old greybeard vimmer with their .vimrc, your prompts should be tailored to you and precisely how you want to work.

Know When to Plan (And When Not To)

Before we dive in—not everything needs a formal plan. Fixing a typo? Just fix it. Tweaking button colors? Get it done. But when you're building features, refactoring systems, or touching anything that could break in interesting ways? I would never do those things without at least a simple plan up front.

The Opening Move

I always start the same way: "Here's what I'm trying to accomplish, here's how I want to work together. Sound good, or do you have suggestions?"

For planning, it goes something like:

"I'm building a plan for [feature]. I don't want you to write code. I want you to help me work through the plan—give suggestions, feedback, show what I'm missing, help validate ideas, and align with the project's goals and architecture. After I give context, we'll work through the implementation plan together. The final output will be a markdown file at current/PLAN.md with all details in a format an LLM agent can understand."

Setting the collaboration pattern upfront is crucial. AI doesn't know how you want to work—telling it explicitly is one of the most helpful things you can do. If you are not used to collaboration patterns with AI yet, it may even have some helpful suggestions to refine the process too.

The Power of PLAN.md

After planning, you have an artifact. Remember, AI is doing statistical pattern matching—clear, structured context is everything. Hierarchy matters. Examples matter even more. If you describe a pattern, show what exists now and what you want after.

This artifact becomes your reference book. Working with AI, you build it faster and often better than working alone. Now you can add it to any session context and instantly get your agent up to speed. Bad path? Git reset, adjust the plan, try again (drastic, but sometimes a clean slate beats untangling a mess). Because once you've done the thinking, getting the code down really is just a formality.

There's More

Notice the `current` directory? There's a reason. PLAN.md isn't your only artifact, and honestly, good planning considers far more than we've covered today. But this is the start—and the plan is the heart of getting great results from these tools.

The Thinking Paradox

So here we are. The robots that were supposed to make us dumber are making me think harder than ever. The tools that were supposed to replace thinking have amplified it instead.

I spend more time planning now. Its not in a notebook that much anymore, its in discussion with a highly engaged, intelligent, and tireless collaborative partner. More time considering architecture tradeoffs. More time considering risk. More time asking "what if?" Because when implementation is cheap, thinking becomes the differentiator. When code generation is instant, planning becomes the bottleneck. When syntax is solved, problem-solving is all that's left.

And honestly? This is what I signed up for twenty years ago. Not to be a typist, but to be a thinker. Not to wrestle with syntax, but to solve problems. Not to fight my tools, but to build something meaningful.

AI didn't take away the part of programming I love. It gave me more of it.

This isn't everything. We havent talked about what happens after the plan—how to break down work so AI can help you fly through implementation while maintaining your standards. Because thinking more doesn't mean typing forever.

The future isn't about writing less code. It's about solving harder problems.

And that is something I can live with.

I've been in the industry for well over two decades. When AI coding tools first came out, I was skeptical. "This is neat, but only very situationally useful." Over the years that shifted to "basically a better Google." But when I saw blog posts and AI CEOs talking about one-shot prompts building entire applications? I wasn't buying it.

I tried the agents and was not impressed. I'd prompt for something, it would write a whole lot of nonsense that I then had to clean up. My experience didn't match the hype.

About 3 months ago, something shifted.

I asked Claude Code to handle a refactoring task—pretty wide in scope but conceptually simple. The kind of tedious work that eats a day and a half of mindless effort. You know the type.

It worked on it for about 30 minutes, then told me it was done.

I checked the code expecting to find garbage. But it was good. Really good. About as good as I could have done myself, maybe better in places. That's when I realized I'd been thinking about this all wrong.

Fast forward to now. Engineering productivity is notoriously hard to quantify, but I feel comfortable saying I'm writing code about 5x faster on average. That's probably conservative. But the speed isn't even the most interesting part.

What I didn't expect:

• My code has gotten cleaner and more maintainable

• I actually plan more now, but it takes less time and effort

• I can understand new codebases in days instead of weeks

• Despite thinking harder during work, I end the day with more energy

The thing that really gets me is that last point. I'm acquiring new technical skills faster than I have in years. It feels like being a junior again, but with senior judgment. It's honestly energizing.

The Three Camps

When I'm reading blogs or on Reddit, I see three camps forming around AI coding. Two of them are huge. One is small, but getting bigger. The goal of this blog is to accelerate that.

The first camp are the Skeptics. Most good programmers are still here, though I think their skepticism is starting to shake. The Skeptics never got past that first experience of generating absolute trash. Based on that, they see two possible futures: either this bubble bursts and it all goes away, or these tools get pushed on juniors who pump out mountains of garbage with stupid names and comments on every other line, never actually learning to code. I think the bubble bursting is hard to justify anytime soon. The dystopian future though? That's likely already happening at a lot of shops.

The second camp is the Vibe Coders. These are the people talking about the third app they just launched pulling in over 1k MRR and they don't know anything about programming. They share tips like "you should ask AI to break up files over 7000 lines, it'll help with token use" or "always maintain multiple backups throughout the day just in case AI goes crazy," while arguing with anyone who mentions version control. These people have clear success, but when viewed from a distance, they just reinforce the Skeptics' worst fears.

Finally there's the third camp: the Professional Developers. They're sharing the message I'm sharing—AI is not a code generator, it's a collaborator. Building out a workflow is a skill you need to work on, but the better you get, the more everything clicks. You can use agents to generate high quality code and maintain standards you could only dream of before, while achieving spectacular velocity.

The problem is it's just a few voices out there. Every once in a while I'll hear someone try to share these insights, and most people don't get it. Those posts usually aren't comprehensive either—they'll touch on a few important things, but it's not enough to set people up for success.

Where We Go From Here

This is why I started this blog. I think we're at an inflection point, and the conversations I'm seeing online aren't helping people make the leap from frustrated to productive.

I'll be writing about what I've learned—both the mindset shifts and the concrete practices that actually work. Because it turns out, changing how you think about AI is just as important as changing how you use it.

Some of this stuff seems obvious in retrospect. Some of it completely surprised me. But it's what made the difference between fighting with AI and actually enjoying this new way of working.

I don't have all the answers—nobody does yet. We're all figuring this out together. But I've found some things that work, and I've seen them work for others too.

The tools are good enough now. What matters is how we use them. And I'm excited to explore that with you