I’ve noticed that since I started my journey into AI-driven software development, I’ve almost entirely stopped going for long walks for exercise. Some of this was the cold weather, but most of it was the dopamine.

“Just one more feature.”

I always wanted to stay close to my machine, because it would regularly ask me for permissions, or a clarifying question, and I didn’t want to waste the time it might wait for.

I’ve been telling myself for months that I should figure out how to configure my machine to allow remote access from my phone. That way, I could kick off new features from the couch, from the car, or even on a walk.

So I spent some time last weekend doing some research to see how others had approached this problem. And that’s when I discovered Claude’s “/remote-control” feature that had literally only been released 4 days earlier.

A video makes a much better illustration of how this works, click the image below to see it.

So if I can get a 2 or 3 mile walk in, while also making progress developing software? Game changed.

I’ve been vibe coding apps for the last 10 months almost daily, at least according to my GitHub activity.

But May 1 will be my first big test.

In addition to everything else, I also run a software development conference called Stir Trek here in Columbus, OH. This will be the 17th year for the event, and the first time we will have an app for attendees.

For a team of 10 volunteers, building a cross-platform app with all of the data and capabilities necessary to serve 1,600+ attendees was just too much to take on. Until now.

This weekend, I’ll be building a complete app, from start to finish, that provides the following capabilities:

• Full schedule view, with “build your schedule” capability.
• Speaker photos, names, and bios linked to their talks.
• Sponsor listings, with links to their websites.
• Dynamic polling throughout the event.
• Session review capabilities, for speaker feedback.
• Venue map (the event is held in a large movie theater)
• Emergency Reporting

I want to spend a little time talking about the emergency reporting feature, because I believe this is the most important one. There are some important issues, like audio/visual problems, that are useful to know about as they’re happening. You don’t want to wait for people to complain after a session, you want to fix it immediately.

But any time you gather a few thousand humans together, there’s the potential for bad behavior. Harrassment. Aggression. Frustration. We want a way for our attendees to feel safe, to feel heard, to feel like they have a team of people listening and ready to help if they’re uncomfortable.

This emergency reporting line is there for anyone, that needs anything during our event. Help. Guidance. Assistance. Safety. Medical Attention.

This has to work. It has to work reliably. It has to work reliably every single time.

May 1st is my first true test with vibe coding.

Last week, I talked about how quickly I was able to create a scoring app for a card game. I had a similar experience this week.

Next month in the United States, the college basketball tournament starts. The best 64 teams play 63 games to determine a champion.

The most fun part of this tournament for me is the first weekend of games. Thursday: 16 games. Friday: 16 games. Saturday: 8 games. Sunday: 8 games. This eliminates 75% of the teams from the tournament.

Each year, 25 of my friends rent a giant cabin, and spend the weekend watching those 48 weekend games. Lots of wagers and games take place as a result, and those games have all traditionally been entered and managed on paper.

It felt like this was an opportunity to use AI to build an app that would make all of these games much simpler to administer and score, but also a way to have everyone connect with each other before the tournament as well.

Here are some of the things that amazed me while building this app.

I didn’t have to explain the bracket concept at all.

With my simple prompt, it was able to establish that there are 4 regions, winning teams flow from one game to the next, and those regions meet in a final four.

I wanted chat features, with notifications and emoji.

Claude was able to build a really compelling chat that is pretty similar to iMessage. It was even able to add Giphy support.

Administration Tools were the most impressive

I asked for a set of administrative tools that would allow things like game score updates. Tools to manage the data the games needed. What I didn’t expect:

• Full user management, including marking payments for each contest.
• Trip cost management. I can mark, in several installments if necessary, how much a user has paid for their trip.
• The system automatically calculates payouts for contests, and gives me a place to mark that I’ve paid the winner.
• A tool to enter the weekend’s menu options for each meal. No more “what’s for dinner tonight?”
• Two powerful dev tools. The first is a time simulator, so that I can see what the app will look like at specific moments. For example, did the picks lock after the first game started? Did the default menu update when the day changed?
• The second dev tool is a user simulator. This allows me to use the site as any user of the system. If someone can’t or won’t use the site, I can still go in and enter their picks for them. I can see what they see in real time.

The tournament starts on March 19th. Can’t wait to see how this performs!

One of our favorite games to play is called Backalley. It’s a trick-taking card game played with a standard 52-card deck. It always involves 5 players, and it’s played in 20 rounds. The first round every player gets 10 cards, then 9, then 8, until you get down to 1. Then you repeat the entire process back up to 10. There are some important data points to record for each round as we play:

• How many tricks did each player think they would win this round (bids)?
• How many total bids were made?
• How many tricks did each player actually win?
• What was the trump suit?
• What is the user’s score?

Here’s what a standard scoring table (on paper) might look like:

I mentioned to the group that this seemed like something I could probably have Claude build for us in the time it took to play a game. So I did.

https://backalleyscore.com

Things I Learned

One of the most amazing things I discovered in this process was how good Claude was at interpreting that hand-written image above. We had already talked through some of the rules of the game, but it was able to identify all of the different components, and use that drawing as a template for what our digital scoresheet became. It makes me think I could be drawing pictures to describe my interfaces when words aren’t getting me where I want to be.

For most of my vibe coding adventures, I’ve leaned into a database, whether that is Supabase, or SQL Server. Claude’s initial instinct on this one was to use dexie.js, a client browser-based database. While this worked very well, it didn’t allow for aggregation of data across users and games. It wasn’t an option I had used before, and I can definitely see a place for it in future apps.

I’d also been using SMS-based authentication for most of my applications. Still using Supabase, I was able to easily build an email-based magic link auth system pretty quickly, including using my own custom domain for the emails.

The app also has an audible “announce standings” button that will read off everyone’s current rank and score. While I’ve done lots of things with text-to-speech in my career, I was surprised how easy this was.

If you want to find the entire project, you can always find these kinds of things in my GitHub repositories.

For a 31-day series, I had to write much of the content ahead of time. Most of it was completed in November or December 2025. The world of artificial intelligence is moving so quickly, it almost feels like the moment you post something, it’s out of date. This series still stands on its own. I tried not to lean too heavily on any specific agent or technology to keep the perspectives timeless.

Audio Versions of the Series

My friend Sean Kelly decided to do a little vibe coding of his own (a lot of vibe coding, actually), and created audio versions of this entire series. You can read about his experience figuring out how to create audio files from my articles here. I’ve also added a link to each audio file at the top of each article.

The 31 Days series taught you the fundamentals of AI-assisted development. Now this blog continues the conversation with fresh content every Friday.

What to Expect

Each week I’ll share:

• New techniques I’ve discovered
• Lessons from real production code
• Updates on the evolving AI tool landscape
• Answers to reader questions

The Series Continues

If you haven’t read the 31 Days series yet, start with Day 1: What Is Vibe Coding? to get the full foundation.

The series covers everything from basic prompting patterns to using AI as your security auditor, SRE, and architect. Each article includes real code and honest lessons about what doesn’t work.

Stay Connected

Subscribe to get new posts delivered every Friday. No spam. Just practical AI coding insights.

This Week’s Update

It’s been a busy week. I just got home from Dynatrace’s Perform conference in Las Vegas, and it was definitely a week I will never forget. Had the opportunity to talk about my journey in vibe coding, and how important observability has become as a result. (You can watch it here).

In addition to that, I’ve also created a new app. While this one is invitation only, I updated the README.md on GitHub to showcase its functionality.

• BroMadness.com – an app to run all of the contests for a friends trip to watch March Madness. (GitHub)

This was my first introduction into a few new technologies, including Vercel & Supabase. It was also my first time using Twilio Verify to provide SMS verification as a login mechanism. I’ve heard many developers state that using AI to write software makes you a worse developer, but I’m finding that I’m learning more, faster than I ever did before. I’d still be fighting with the Twilio integration and APIs, and instead, my app is already in production!

I also built another app that is for the Super Bowl game this Sunday. My sister and brother-in-law’s last name is Stuber, and they host the “Stuber Bowl” watch party every year. They have dozens of people participate in “prop bets” like “How long will the National Anthem take (in seconds)?” or “Will the first play from scrimmage ba a run or pass play?” It’s always been managed in a spreadsheet, but in just a few hours on Monday night, I was able to build them an app that has:

• Pick making directly in the app
• Live Chat with notification
• SMS verification for login
• Administrative tools to managing users and payment tracking, as well as the ability to enter results as they happen.
• Full leaderboard
• Profile management

I can’t even express how fun software development has become for me again. Until next week!

Some Light Reading

• I Miss Thinking Hard - jernesto.com
• A sane but extremely bull case on Clawdbot / OpenClaw - brandon.wang
• AI Didn’t Break Copyright Law, It Just Exposed How Broken It Already Was - jasonwillems.com
• Most People Can’t Vibe Code. Here’s How We Fix That. - a16z.news
• The AI Vibe Coding Paradox: Why Experience Matters More Than Ever - medium.com

Thirty-one days of tactics, prompts, and practices. That’s a lot. Too much to use all at once. Too much to remember without a system.

Today we build your personal playbook. Not everything from this series. Just what works for you. A reference you’ll actually use. A foundation you’ll build on.

What Goes in Your Playbook

Your playbook is personal. Mine has:

• CLAUDE.md - My agent configuration
• common-ai-mistakes.md - Patterns AI gets wrong in my projects
• prompts/ - Templates for common tasks
• checklists/ - Pre-commit, pre-deploy, review checklists
• runbooks/ - What to do when things break

Yours might be different. That’s the point. Take what works, leave what doesn’t.

Building Your CLAUDE.md

Your agent configuration is the foundation. Here’s a template:

# Project Configuration

## Tech Stack
- Language: [TypeScript/Python/etc.]
- Framework: [React/Express/Django/etc.]
- Database: [PostgreSQL/MongoDB/etc.]
- Testing: [Jest/Pytest/etc.]

## Code Standards
- [Your linting rules]
- [Your formatting preferences]
- [Your naming conventions]

## Patterns to Follow
- Error handling: [describe your pattern]
- Logging: [describe your telemetry approach]
- Testing: [describe your test structure]

## Patterns to Avoid
- [Don't use X, use Y instead]
- [Never do Z because...]

## Important Files
- [Key files AI should know about]

## Common Tasks
- To run tests: [command]
- To build: [command]
- To deploy: [command]

Customize this for your project. Update it as you learn what AI needs to know.

Your Prompt Library

Start with these categories:

Generation Prompts

• Feature implementation
• API endpoint
• Component
• Test suite

Review Prompts

• Security review
• Performance review
• Maintainability review

Debug Prompts

• Production issue
• Log analysis
• Stack trace analysis

Maintenance Prompts

• Refactoring
• Documentation
• Debt inventory

You don’t need dozens. Start with one prompt per category. Add more as you discover what you use repeatedly.

Your Mistakes File

Create common-ai-mistakes.md and add to it:

# Common AI Mistakes

## [Category]

### [Mistake Name]
AI tends to: [what AI does wrong]
Instead: [what you want]
Why: [brief explanation]

Start empty. Every time you correct AI twice for the same thing, add it.

Your Checklists

Pre-Commit Checklist

□ Tests pass
□ No linting errors
□ No console.logs or debug code
□ Sensitive data not exposed
□ Types are accurate
□ Error handling is complete

Pre-Deploy Checklist

□ All tests pass in CI
□ Migrations tested
□ Rollback plan documented
□ Monitoring in place
□ Stakeholders notified
□ On-call aware

Code Review Checklist

□ Security pass completed
□ Performance considered
□ Edge cases handled
□ Tests are meaningful
□ Patterns are consistent

Your Workflow

Document your AI workflow:

Feature Development

1. Write GitHub issue with full context
2. Review architecture with AI
3. Define contracts/interfaces
4. Generate implementation
5. Generate tests
6. Run multi-pass review
7. Refactor as needed
8. Deploy with checklist

Bug Fixing

1. Gather symptoms and logs
2. Hypothesis with AI
3. Add logging if needed
4. Test hypothesis
5. Fix and test
6. Add regression test

Debugging

1. Describe symptom to AI
2. Get list of likely causes
3. Check each systematically
4. Confirm root cause
5. Generate fix
6. Verify fix

Principles to Remember

From this series, the principles that matter most:

1. You’re the architect AI is your junior developer. You make the decisions. AI helps you implement them faster.

2. Observability is non-negotiable When shipping fast, you need to know when things break. Logs, metrics, traces. Always.

3. Context is everything Better prompts get better results. Include what AI needs to know. Structure your prompts.

4. Trust but verify AI makes mistakes. Review output. Run tests. Check edge cases. Don’t assume it’s right.

5. Small steps, frequent verification Break big features into phases. Verify each phase works before continuing.

6. Document what you learn Add to your mistakes file. Update your prompts. Evolve your configuration. Learning compounds.

The 30-Day Summary

What we covered:

Week 1: Foundation

• What vibe coding is (and isn’t)
• Using GitHub issues as context
• Component libraries for consistency
• Observability from the start
• The prompting pattern
• Breaking features into phases
• Context management

Week 2: Tactics

• When to restart vs. continue
• Git as your undo button
• Agent configuration
• Teaching AI your patterns
• The mistakes file
• Constraining AI changes
• Spotting hallucinations

Week 3: Expert Roles

• Context and tokens
• Security auditing
• Performance auditing
• Test generation
• Multi-pass code review
• Debugging with AI
• Architecture evaluation

Week 4: Production & Mastery

• Production debugging
• Edge case generation
• Deployment automation
• Refactoring AI code
• Multi-service coordination
• Prompt libraries
• Tool landscape
• Measuring effectiveness
• Managing technical debt
• This playbook

What’s Next

The series is over. Your journey continues.

Keep learning: AI tools evolve rapidly. What doesn’t work today might work next month. Stay curious.

Keep measuring: Track whether AI helps. Adjust based on evidence.

Keep sharing: When you find something that works, share it. The community benefits from collective learning.

Keep shipping: The point isn’t to use AI. The point is to build things that matter. AI is just a tool. Use it when it helps. Skip it when it doesn’t.

The Final Challenge

Build something.

Not a todo app. Not a tutorial project. Something real. Something you’ll use. Something you’ll show people.

Use what you’ve learned:

• Plan with AI
• Generate with AI
• Review with AI
• Test with AI
• Deploy with your checklists
• Monitor with observability

Ship it. Then tell me about it.

Thank You

If you’ve followed along for all 31 days, thank you. I hope you ship faster and with more confidence.

Vibe coding isn’t about AI doing your work. It’s about you doing better work with AI’s help. Stay in flow. Trust your judgment. Keep the AI as your assistant, not your replacement.

Now go build something.

Your Playbook Checklist

Before you close this series:

□ CLAUDE.md created and customized
□ common-ai-mistakes.md started (even if empty)
□ At least one prompt template saved
□ Pre-commit checklist documented
□ Workflow documented
□ First project identified to build

You don’t need everything. You need something. Start there. Add more as you go.

The best playbook is the one you’ll actually use.

AI had generated features at unprecedented speed. Two months in, I had a product. I also had a codebase that scared me. Inconsistent patterns. Functions doing too much. Tests that passed but didn’t actually test anything. Comments that lied about what the code did.

I’d traded velocity for debt. Now the debt was coming due.

This is the dark side of vibe coding. Speed is addictive. Debt accumulates silently. Then one day you try to add a simple feature and it takes three days because everything is tangled.

Managing debt isn’t about not having debt. It’s about having the right amount of debt and paying it down strategically.

Why AI Code Accumulates Debt Faster

AI code has specific debt patterns:

Inconsistency: Each generation might use slightly different patterns. Small inconsistencies compound into chaos.

Over-engineering: AI often generates more than you need. That extra code is debt you maintain forever.

Shallow testing: AI writes tests that pass, but don’t actually verify behavior. You think you have coverage. You don’t.

Missing context: AI doesn’t know why past decisions were made. It might undo intentional choices.

Copy-paste sprawl: It’s easy to generate similar code instead of abstracting. Duplication is debt.

The Debt Inventory Prompt

Start by knowing what you have:

Analyze this codebase for technical debt.

Categories:
1. Code duplication - similar code that should be abstracted
2. Inconsistent patterns - same thing done different ways
3. Missing tests - code without adequate coverage
4. Missing docs - complex code without explanation
5. Dead code - code that's never executed
6. Outdated dependencies - libraries that need updates
7. Performance debt - known slow paths not optimized
8. Security debt - known vulnerabilities not addressed

For each item:
- Location
- Severity (blocking / painful / annoying)
- Effort to fix (hours)
- Risk if not fixed

Prioritizing Debt

Not all debt is equal. Prioritize by:

Impact on velocity: Does this debt slow down every feature? Fix it.

Risk: Could this debt cause production issues? Fix it soon.

Compounding: Will this debt get worse over time? Address before it spreads.

Effort: How hard is it to fix? Sometimes quick wins are worth doing.

Priority = (Impact × Risk × Compounding) / Effort

High impact, high risk, compounding, low effort = fix immediately. Low impact, low risk, isolated, high effort = maybe never.

The 20% Rule

Reserve 20% of your time for debt reduction.

Every week, every sprint, every cycle: 20% goes to making the codebase better.

• 4 days on features, 1 day on debt
• 4 features, 1 cleanup task
• Every PR improves one thing beyond its scope

This isn’t optional. It’s investment. Skip it, and velocity drops over time.

AI-Assisted Debt Paydown

Use AI to fix what AI created:

Pattern Consolidation

I have the same pattern implemented multiple ways.

Example 1: [paste code]
Example 2: [paste code]
Example 3: [paste code]

Create a single abstraction that handles all these cases.
Then show me how to refactor each usage.

Test Improvement

These tests pass but I don't trust them.

Tests: [paste tests]
Code they test: [paste code]

Identify:
1. What behaviors aren't actually tested?
2. What edge cases are missed?
3. What assertions are too weak?

Generate improved tests that would catch real bugs.

Documentation Generation

This code is complex and undocumented.

Code: [paste code]

Generate:
1. High-level explanation of what this does
2. Inline comments for non-obvious parts
3. Examples of how to use it
4. Known limitations or gotchas

The Debt Log

Track debt explicitly:

# Technical Debt Log

## Critical (fix this sprint)
- [ ] User auth has no rate limiting (security risk)
- [ ] Card search uses N+1 queries (performance)

## High (fix this month)
- [ ] Three different error handling patterns
- [ ] Tests mock at wrong level, don't catch bugs

## Medium (fix this quarter)
- [ ] Duplicate validation logic in 5 places
- [ ] Old migration files never cleaned up

## Low (fix when convenient)
- [ ] Inconsistent naming in legacy module
- [ ] Console.logs left in non-critical paths

## Accepted (won't fix)
- [ ] Old admin panel uses deprecated patterns (replacing soon)

Review this log weekly. Move items up as they become urgent.

Prevention Strategies

Better to not create debt than to pay it down:

Pre-Generation Review

Before asking AI to generate significant code:

I'm about to generate code for [feature].

Before I do, tell me:
1. What existing patterns should this follow?
2. What abstractions already exist that I should use?
3. What could I generate that would create debt?
4. What should I specify to prevent mess?

Post-Generation Cleanup

After AI generates code, before committing:

Review this AI-generated code for debt indicators:

[paste code]

Check for:
- Duplicates what exists elsewhere?
- Inconsistent with established patterns?
- Over-engineered for the need?
- Missing tests for important paths?
- Hardcoded values that should be config?

What should be cleaned up before committing?

The PR Checklist

Before every merge:

□ Follows existing patterns (or intentionally changes them)
□ No new duplication
□ Tests cover actual behavior
□ No unnecessary complexity
□ No new warnings or linting issues
□ Documentation updated if needed
□ One thing improved beyond the feature

Debt Sprints

Sometimes you need focused cleanup:

Every quarter, schedule a debt sprint. One week focused entirely on debt reduction.

• No new features
• Only cleanup, consolidation, testing, documentation
• Measure: lines deleted, patterns consolidated, test coverage increased

One week of cleanup buys months of velocity.

The Strangler Pattern for Legacy AI Code

When you have AI-generated code that needs major improvement:

1. Don’t rewrite all at once
2. Build new code correctly alongside old
3. Route new features to new code
4. Gradually migrate old features
5. Delete old code when nothing uses it

AI can help:

I have legacy code that needs replacement.

Old code: [paste]
What it does: [describe]

Generate a new, cleaner implementation.
Show me how to run both in parallel during migration.

Signs You Have Too Much Debt

• Features take longer and longer
• Every change breaks something unrelated
• New developers can’t understand the code
• You avoid touching certain areas
• Tests pass but production breaks
• Simple bugs take hours to fix

When you see these signs, stop features and pay down debt.

Tomorrow

Final day. You’ve learned tactics for AI-assisted development. Tomorrow we’ll build your personal playbook: the practices you’ll keep, the workflow you’ll use, the principles that guide your vibe coding.

Try This Today

1. Pick one area of your codebase that scares you
2. Run the debt inventory prompt on it
3. Fix one thing. Just one.

Small, consistent debt payment beats occasional massive rewrites. Start today. Continue tomorrow. In a month, the scary area is manageable.

Debt is normal. Unmanaged debt is the problem.

Prompts flying. Code generating. Features shipping. The vibe was strong.

Then I looked at my actual output. Features shipped per week. Bugs in production. Time from issue to deployment. The numbers told a different story than my feelings.

I wasn’t faster. I was busier. More code was being written. But the important metrics were about the same.

That’s when I learned: feeling productive and being productive are different things. If you want to know whether AI is actually helping, you need to measure.

What Not to Measure

Some metrics are useless or misleading:

Lines of code: More code isn’t better. AI generates verbose code. You might ship more lines and less value.

Prompts per day: Using AI more doesn’t mean accomplishing more. You could be prompting in circles.

Features started: Starting is easy. Finishing is what matters.

Time in AI tools: Time spent doesn’t equal value produced.

These metrics make you feel productive without telling you if you’re productive.

What to Measure

Focus on outcomes, not activities:

Cycle Time

Time from starting a task to deploying it.

Cycle time = Deploy timestamp - Start timestamp

If AI is helping, cycle time should decrease. Track this per feature or per issue.

Throughput

Features or issues completed per week.

Throughput = Completed items / Time period

If AI is helping, throughput should increase while quality stays constant.

Quality Metrics

Bugs in AI-generated code vs. manually written code.

Track:

• Bugs reported per feature
• Time to find bugs (in testing vs. production)
• Severity of bugs
• Rework needed after initial implementation

If AI code has more bugs, you’re not actually saving time.

Time Distribution

Where does your time go?

Categories:

• Planning and design
• Writing prompts
• Reviewing AI output
• Fixing AI mistakes
• Manual implementation
• Testing
• Debugging
• Deployment

If you spend 2 hours prompting and reviewing to save 1 hour of coding, that’s a net loss.

Setting Up Tracking

You don’t need complex tooling. Start simple:

Option 1: GitHub Labels

Label issues with how they were built:

• ai-assisted
• manual
• ai-heavy

Compare metrics between labels.

Option 2: Time Tracking

Track time per task with notes on AI usage. At the end of each week, review:

• What took longest?
• Where did AI help?
• Where did AI hurt?

Option 3: Simple Spreadsheet

| Feature | Start | Deploy | AI? | Bugs | Rework? |
|---------|-------|--------|-----|------|---------|
| Wishlist | 1/15 | 1/17  | Yes | 1    | No      |
| Search   | 1/18 | 1/25  | Yes | 3    | Yes     |
| Profile  | 1/26 | 1/27  | No  | 0    | No      |

Patterns emerge quickly.

Honest Assessment Questions

Ask yourself weekly:

1. What did I ship this week? Not start. Ship.

2. What took longer than expected? Was AI a factor?

3. What bugs did I introduce? How many were in AI code?

4. What did I waste time on? Prompting in circles? Fixing AI mistakes?

5. What would I do differently? With hindsight, would AI have been the right choice?

The AI Overhead Trap

AI has overhead:

• Writing prompts takes time
• Reviewing output takes time
• Fixing mistakes takes time
• Context switching takes time

For simple tasks, this overhead can exceed the benefit.

AI benefit = Time saved - (Prompt time + Review time + Fix time)

If the benefit is negative, AI slowed you down.

Where AI Actually Helps

In my tracking, AI helps most with:

Boilerplate generation: Tests, CRUD endpoints, similar components. High repetition, low complexity.

Code review: Finding issues I’d miss. Consistent multi-pass review.

Exploration: “How would I approach this?” Planning before coding.

Edge cases: Thinking of scenarios I wouldn’t consider.

Documentation: Explaining code, writing docs, creating runbooks.

Where AI Hurts

AI hurts most with:

Novel problems: Unique architecture, unusual requirements. AI has no patterns to draw from.

Subtle bugs: AI confidently generates code with subtle issues. Review time exceeds benefit.

Over-engineering: AI adds complexity when simplicity would work. Then I maintain the complexity.

Context-heavy work: When you need to understand 20 files to make a small change. AI’s understanding is shallow.

The Comparison Test

Try this experiment:

1. Pick two similar features
2. Build one with heavy AI assistance
3. Build one with minimal AI
4. Compare: time, quality, bugs, rework

What you find might surprise you. Sometimes the manual approach is faster for your context.

Tracking Template

Weekly review template:

# Week of [date]

## Shipped
- [feature 1] - AI heavy/light/none - [time] - [bugs]
- [feature 2] - ...

## Time Distribution
- Planning: X hours
- Prompting: X hours
- Reviewing AI: X hours
- Fixing AI: X hours
- Manual coding: X hours
- Testing: X hours
- Other: X hours

## What Worked
- [what AI helped with]

## What Didn't Work
- [where AI hurt]

## Next Week
- [what to do differently]

The Honest Truth

AI doesn’t make everyone faster on everything.

It makes some people faster on some things. The only way to know if it’s helping you is to measure.

Track your outcomes. Be honest about what you find. Adjust your usage based on evidence, not vibes.

Tomorrow

Fast is good. Sustainable is better. Tomorrow I’ll cover managing technical debt when you’re shipping fast with AI. How to stay fast without drowning in accumulated mess.

Try This Today

1. Pick a feature you built with AI recently
2. Estimate the time breakdown: prompting, reviewing, fixing, manual work
3. Would it have been faster without AI?

Be honest. The answer might be yes. That’s useful information. It tells you where to use AI and where not to.

The goal isn’t to use AI. The goal is to ship good software. AI is one tool. Measure whether it’s actually helping.

Not because I can’t pick one. Because different tools are better at different things. Claude Code for codebase-wide changes. GitHub Copilot for inline completions. ChatGPT for exploring ideas. Cursor when I want AI deeply integrated in my editor.

The tool landscape is confusing. Marketing makes everything sound the same. In practice, they’re different in ways that matter.

Here’s my honest assessment of when to use what.

Claude Code

Best for: Codebase-wide operations, multi-file changes, complex reasoning

Claude Code operates across your entire repository. It can read multiple files, understand relationships, and make coordinated changes. When you need to refactor a pattern that appears in 20 files, Claude Code handles it.

Use it when:

• Changes span multiple files
• You need to understand how components relate
• Complex reasoning about architecture
• Large refactoring operations
• You want AI to read existing patterns and follow them

Skip it when:

• Quick inline completions
• You just need a one-liner
• Exploring ideas before you know what you want

Strengths: Deep codebase understanding, multi-file coordination, detailed reasoning, long context window

Weaknesses: Setup required, can be slower for quick tasks, costs more for heavy use

GitHub Copilot

Best for: Inline completions, quick suggestions while typing

Copilot lives in your editor. As you type, it suggests completions. It’s fast and low-friction. Write a function signature, Copilot suggests the body. Write a comment, Copilot suggests the code.

Use it when:

• Writing code line by line
• Boilerplate that follows patterns
• Test cases similar to existing ones
• Obvious implementations
• You know what you want, just need it typed faster

Skip it when:

• Complex multi-file changes
• You need to understand before generating
• Architecture decisions
• Code review

Strengths: Speed, low friction, IDE integration, learns your patterns

Weaknesses: No reasoning shown, limited to local context, sometimes suggests wrong patterns

ChatGPT / Claude Web

Best for: Exploration, planning, learning, one-off questions

The web interfaces are for thinking out loud. You don’t need file access. You want to explore an idea, understand a concept, plan an approach before committing.

Use it when:

• “How should I approach this?”
• “Explain this concept”
• “What are the tradeoffs between X and Y?”
• Planning before implementing
• Quick questions unrelated to specific code

Skip it when:

• You need to work with actual files
• Multi-file changes
• Generating production code

Strengths: Easy access, no setup, good for conversation, multiple models available

Weaknesses: Can’t see your code, copy-paste friction, context lost between sessions

Cursor

Best for: AI-native editing, tight editor integration

Cursor is an IDE built around AI. It has Claude and GPT built in, with deep integration for editing, chat, and code generation. If you want AI to be central to your editing experience, Cursor makes it seamless.

Use it when:

• You want AI always available in your editor
• Editing and generation in one flow
• You prefer IDE over CLI
• Your workflow is file-by-file with AI help

Skip it when:

• Large codebase-wide operations
• You’re happy with your current editor
• You want to keep AI separate from editing

Strengths: Seamless integration, fast iteration, good UX for AI-assisted editing

Weaknesses: Another IDE to learn, subscription cost, less control than CLI

Windsurf / Codeium

Best for: Free alternative, team environments

Codeium and Windsurf offer AI coding tools with generous free tiers. Good for teams that can’t justify per-seat costs or developers who want to try AI coding without commitment.

Use it when:

• Budget constraints
• Evaluating AI tools
• Team rollout with cost concerns

Strengths: Free tier, team features, good performance

Weaknesses: Less cutting-edge than premium options, smaller context windows

Aider

Best for: Terminal-native workflows, Git integration

Aider is a command-line tool that integrates AI with Git. Every AI change becomes a commit. It’s great if you live in the terminal and want version control built into AI interactions.

Use it when:

• You prefer terminal over IDE
• You want every AI change as a Git commit
• You’re working on specific files, not exploring

Skip it when:

• You want visual UI
• You’re exploring broad changes

Strengths: Git integration, terminal-native, supports multiple AI models

Weaknesses: Learning curve, less visual feedback

My Daily Workflow

Here’s how I actually use these tools:

Morning planning: ChatGPT or Claude web for thinking through what I’m building. “Here’s what I want to accomplish. What’s the approach?”

Implementation: Claude Code for features that touch multiple files. Copilot for inline completions while I type. Switch between them based on task size.

Quick fixes: Copilot for obvious one-liners. Claude Code if I need to find where the fix should go.

Code review: Claude Code for multi-pass reviews. It can read the whole codebase and spot inconsistencies.

Debugging: Claude Code for systematic debugging with code access. ChatGPT for quick “why might this happen?” questions.

Choosing Based on Task

The Integration Question

Some developers use one tool for everything. Others use multiple tools for different purposes.

Single tool advantages:

• Simpler workflow
• One subscription
• Consistent experience
• Context accumulates

Multiple tool advantages:

• Best tool for each job
• Redundancy if one is down
• Compare outputs
• Different strengths

I lean toward multiple tools because the differences matter for my work. But simpler is also valid.

Cost Considerations

AI tools range from free to expensive. I use ChatGPT Pro ($20), Claude Code Max ($100), and GitHub Copilot from my employer.

For professional use, the cost is usually justified by time saved. For learning or light use, free tiers work fine.

What to Try First

If you’re starting:

1. GitHub Copilot for inline completions (easiest start)
2. Claude or ChatGPT web for exploration and planning
3. Claude Code when you’re ready for codebase-wide AI

Add more tools as you discover specific needs they fill.

Tomorrow

You’re using AI tools. But how do you know they’re actually helping? Tomorrow I’ll cover measuring what matters: tracking whether AI is making you faster, or just making you feel faster.

Try This Today

1. Think about your last few AI interactions
2. Which tool did you use?
3. Was it the best tool for that task?

If you’re using one tool for everything, try another for the task it’s best at. You might find a combination that works better than any single tool.

Each time I needed to generate tests, I wrote a new prompt from scratch. Each time it was slightly different. Each time I forgot something the previous version had.

This is inefficient. When you find a prompt that works, save it. Categorize it. Reuse it. Stop reinventing prompts every time you need to do the same kind of task.

Your prompt library is an investment. Build it once, benefit forever.

What Goes in a Prompt Library

Prompts that:

• You use more than once
• Took time to get right
• Work consistently well
• Apply to common tasks

Don’t save:

• One-off prompts for unique situations
• Prompts that didn’t work
• Prompts that are just your project context

Get the Starter Kit

I’ve created a prompt library starter kit you can use right now:

Or browse the templates directly: examples/prompt-library

Library Structure

I organize by task type:

prompt-library/
├── generation/        # Creating new code
│   ├── feature.md
│   ├── api-endpoint.md
│   ├── component.md
│   └── test-suite.md
├── review/           # Auditing existing code
│   ├── security.md
│   ├── sre.md
│   ├── maintainability.md
│   └── edge-cases.md
├── debug/            # Finding and fixing problems
│   ├── investigate.md
│   ├── log-analysis.md
│   └── stack-trace.md
├── refactor/         # Improving existing code
│   ├── code-smells.md
│   ├── extract-function.md
│   └── naming.md
└── deploy/           # Shipping to production
    ├── migration.md
    ├── rollback.md
    └── checklist.md

Each file contains one prompt template with placeholders, an example, and variations.

Prompt Template Format

Each saved prompt should have:

# Generate API Endpoint

## When to Use
When you need to create a new REST API endpoint.

## Template

Generate a REST API endpoint.

Context:

• Framework: {framework}
• Database: {database}
• Auth: {auth_method}

Endpoint:

• Method: {method}
• Path: {path}
• Purpose: {purpose}

Request body: {request_schema}

Response: {response_schema}

Include:

• Input validation
• Error handling
• Telemetry
• Tests

Follow the patterns in {reference_file}.

## Example Usage
[Show a filled-in example]

## Variations
- For authenticated endpoints: add auth middleware
- For file uploads: add multipart handling
- For pagination: add cursor/offset parameters

Building Your Library Incrementally

Don’t create everything at once. Build as you go:

1. Write a prompt for your current task
2. It works well and produces good output
3. Extract the template by replacing specifics with placeholders
4. Save it in the appropriate category
5. Next time, use the template instead of starting from scratch

My Core Prompts

Here are the prompts I use most often:

Feature Generation

# Feature Implementation

Build this feature.

## Context
Tech stack: {stack}
Relevant files: {files}

## The Feature
{description}

## Requirements
{requirements}

## Constraints
{constraints}

## Reference
Follow the patterns in {reference}

## Output
1. Implementation code
2. Tests
3. Any migrations needed

Test Generation

# Generate Tests

Generate comprehensive tests for this code.

## Code
{code}

## Test Framework
{framework}

## Coverage Goals
- Happy path
- Edge cases: {specific_edge_cases}
- Error cases: {specific_error_cases}
- Security cases if applicable

## Test Patterns
Follow the patterns in {reference_test_file}

Code Review

# Code Review: {focus}

Review this code focusing on {focus}.

## Code
{code}

## Check For
{checklist}

## Output Format
For each issue:
- Location (file:line)
- Severity (Critical/High/Medium/Low)
- The problem
- Suggested fix

Debug

# Debug This Issue

## Symptom
{what_is_happening}

## Expected
{what_should_happen}

## Context
{relevant_code_and_logs}

## Help Me
1. List likely causes
2. How to confirm each
3. Most likely root cause
4. Suggested fix

Parameterizing Prompts

Good templates have clear placeholders:

Bad:

Generate code for the thing I'm working on.
Follow our patterns.

Good:

Generate a {component_type} component.

Purpose: {purpose}
Props: {props}
State: {state_requirements}
Events: {events_to_handle}

Follow the patterns in {reference_component}.

Clear placeholders remind you what to fill in.

Prompt Composition

Complex tasks combine multiple prompts:

# Complex Feature Workflow

For large features, run these prompts in order:

1. **Architecture Review** (prompts/review/architecture.md)
   Input: Feature description
   Output: Approved approach

2. **Contract Definition** (prompts/generation/contracts.md)
   Input: Approved approach
   Output: API contracts and types

3. **Backend Implementation** (prompts/generation/api-endpoint.md)
   Input: Contracts
   Output: Backend code

4. **Frontend Implementation** (prompts/generation/component.md)
   Input: Contracts
   Output: Frontend code

5. **Test Generation** (prompts/generation/test-suite.md)
   Input: All code
   Output: Tests

6. **Security Review** (prompts/review/security.md)
   Input: All code
   Output: Security issues

Version Controlling Your Prompts

Your prompts are code. Version control them:

• Store in your repo or a dedicated prompts repo
• Commit changes with messages explaining improvements
• Tag versions that work well
• Branch for experiments

Sharing With Your Team

Prompt libraries multiply when shared:

1. Central repo with team prompts
2. Contributing guidelines for adding new prompts
3. Review process for quality control
4. Documentation on when to use what

A team prompt library means everyone benefits from anyone’s discoveries.

Evolving Your Prompts

Prompts need maintenance:

# Prompt Improvement Log

## 2024-01-15: test-suite.md
Added edge case categories after forgetting them twice.
Now explicitly lists: null inputs, empty collections, boundary values.

## 2024-01-20: api-endpoint.md
Added telemetry requirement after shipping endpoints without logging.
Now includes: "Add telemetry with {telemetry_service}."

## 2024-02-01: security.md
Expanded OWASP categories after missing an injection vulnerability.
Now covers all OWASP Top 10 explicitly.

Track why prompts change. Learn from what didn’t work.

The Prompt Development Loop

1. Use a prompt
2. Evaluate the output
3. Identify what was missing or wrong
4. Update the prompt
5. Repeat

Your prompts should get better over time.

Quick Access

Make your prompts easy to use:

• Keyboard shortcuts to insert templates
• Snippets in your editor
• CLI tool to cat prompts
• Browser bookmarks if using web UI

Friction kills reuse. Make it effortless.

Tomorrow

You have prompts that work. You have a library. But how do you know AI is actually helping? Tomorrow I’ll cover measuring what matters: is AI making you faster, or just making you feel faster?

Try This Today

1. Think of a prompt you’ve written multiple times
2. Extract it into a template
3. Save it somewhere you’ll find it
4. Use the template next time

Start with one prompt. Add more as you encounter them. In a month, you’ll have a library that saves you real time.