DEV Community: Panav Mhatre

Why Your Claude-Generated Code Works But Feels Wrong (And What to Do About It)

Panav Mhatre — Sun, 21 Jun 2026 14:50:16 +0000

You ship the feature. Tests pass. The PR looks clean. But three days later, when you try to extend it, something feels off. The structure doesn't quite fit. You're not sure if a piece of logic belongs where it is. You start second-guessing the naming. You end up rewriting it anyway.

Sound familiar?

This is one of the most common experiences developers have after a few months of shipping with Claude. The code isn't wrong — it runs fine. But it's subtly alien. It doesn't feel like yours.

I want to talk about why this happens and what actually fixes it.

The real problem isn't your prompts

The instinct is to reach for better prompts. More specific requirements. Clearer constraints. And that helps — but it's treating the symptom.

The root cause is usually this: you're handing Claude a task before you have a clear picture of what the output should connect to.

Claude is an extremely capable generator of locally coherent code. Given a well-formed requirement, it will produce something that solves the literal problem. The issue is that "locally coherent" isn't the same as "fits your system."

When you don't bring a clear picture of your existing structure to the session, Claude fills the gap with its best guess. That guess is based on general patterns — which are often good — but they're not your patterns. The code solves the problem you asked about, but makes implicit decisions about naming, structure, error handling, and data flow that you didn't notice until you went to change something.

Over several sessions, these implicit decisions compound. You end up with a codebase where different parts solve similar problems differently, where naming conventions drift, where you're not quite sure what anything "owns." It all works, but it's expensive to reason about.

I think of this as AI-assisted drift — not technical debt in the traditional sense, but architectural incoherence that accumulates when you move fast without bringing your existing context into each session.

What actually helps

Here are three habits that made a concrete difference in the maintainability of my Claude-assisted code:

1. Write a one-paragraph "brief" before each session

Before you type a single prompt, write out: what you're building, what already exists that it needs to connect to, and what you're explicitly NOT changing.

This sounds like overhead. It's actually the opposite — it's the work that prevents you from doing the same thing twice. When you write out the constraints that aren't obvious from the surface request, Claude's output starts fitting into your codebase instead of beside it.

You don't have to share the whole brief every time. Just writing it clarifies your own thinking, which changes how you ask.

2. Ask Claude to summarize what it understood before it writes code

After giving Claude a task, ask: "Before you write anything, tell me what you understood the task to be and what assumptions you're making."

This sounds like it would slow you down. It doesn't — it takes thirty seconds and it surfaces the hidden assumptions before they're baked into 200 lines of code.

The assumptions you want to catch are things like: "I'm going to create a new module for this" (you didn't ask for a new module), or "I'll use a dict here since there's no existing data class" (there is one, in a different file you didn't paste in). These are small decisions that feel obvious to Claude in the moment and that create friction for you six commits later.

3. Treat every AI output as a draft, not a handoff

The posture shift that matters most: Claude's output is a starting point for your thinking, not a finished result.

This doesn't mean you rewrite everything. It means you read it the way you'd read a PR from a junior engineer you trust — with the assumption that it's mostly right but with the responsibility to understand it before you ship it.

The developers who get into trouble with AI-assisted code aren't the ones who use it too much. They're the ones who accept it without engaging. The code works, they move on, and two features later they've built something no one can explain.

The underlying issue: confidence without context

AI-generated code has a subtle property that makes this worse: it's confident-looking by default. The formatting is clean, the naming is reasonable, the structure is plausible. There are no obvious tells that it might be making bad assumptions.

Human-written code tends to show its uncertainty — the comment that says "not sure if this is right," the variable name that reveals confusion, the TODO that signals something was deferred. AI output doesn't do that. It looks finished even when the underlying assumptions are wrong.

This means the normal debugging instinct — "if it looks right, it probably is" — doesn't quite apply. You need to actively interrogate the output, not just visually scan it.

The specific things worth checking in any non-trivial AI output:

State and ownership: does this function know more about external state than it should?
Error handling: what happens when the thing it assumes is there isn't?
Naming conventions: does this match the patterns in the rest of the codebase, or did it invent its own?
Implicit dependencies: what would break if you moved this to a different module?

None of this requires being suspicious of Claude. It requires having a clear enough picture of your system to notice when something doesn't fit.

A free resource if you want to go deeper

I put together a starter pack — prompt templates, a shipping checklist, and a workflow structure — specifically for developers who want to ship with Claude without accumulating the kind of invisible mess I described above. The focus is on maintainability and workflow design, not prompt tricks.

It's free, no upsell: Ship With Claude — Starter Pack

It's aimed at indie builders and first-time founders, but the principles apply whether you're solo or on a small team. The core idea is that you should finish a Claude session understanding your codebase better than when you started — not worse.

The goal isn't to use Claude less. It's to use it in a way that leaves you in control of what you're building.

The speed is real. The maintainability tradeoff is also real. You don't have to choose between them — but you do have to be intentional about how you work.

Your Claude-built app works. But do you actually understand it?

Panav Mhatre — Sat, 13 Jun 2026 14:03:22 +0000

You asked Claude to build something. It did. Tests pass. It ships.

But here's the question that doesn't get asked enough: do you actually understand what was built?

Not "can you explain it at a high level" — I mean: if something breaks in three months, will you know where to look? If a new dev joins, will you be able to walk them through the decisions? If you need to extend it, will you know which abstraction to reach for?

For a lot of AI-assisted projects, the honest answer is no. And that's not a skills problem. It's a workflow problem.

The pattern I kept seeing

Here's what typically happens when someone ships with an AI assistant:

You describe the feature. Claude writes the code.
You test it. It works. You move on.
Six weeks later, you need to touch that code again.
You can't remember why anything is structured the way it is.
You ask Claude to explain it. Claude gives you a confident explanation that may or may not match the original intent.
You patch it, things get messier, the cycle continues.

I've started calling this AI-assisted debt — not broken code, but orphaned code. It ships, it runs, but it was never really yours. The decisions that produced it live in a chat history you've already lost.

Why this happens

The root cause isn't the AI. It's that most people use AI assistants as output machines, not thinking partners.

You send a problem, you get a solution. But the reasoning behind the solution — why this structure, why this tradeoff, why this library over that one — evaporates between sessions.

This is different from the usual "prompting" conversation. It's not about whether you asked the right question. It's about whether the answer became part of your working model of the system, or just part of the codebase.

What a better workflow looks like

A few things that have actually helped:

1. Before accepting a solution, ask why

Don't just review the code. Ask Claude: "What was the main tradeoff you made here?" or "What would break if I changed X?" This forces the reasoning into your session context, and more importantly, into your head.

2. Keep a short decision log

It doesn't need to be formal. Even a DECISIONS.md with three bullet points per major feature — what you chose, what you rejected, and why — makes a huge difference when you come back three months later.

3. Distinguish between "it works" and "I understand it"

These are different signals. A failing test means something is wrong. A passing test means nothing about comprehensibility. Get in the habit of asking yourself: could I explain this to someone else? Could I rewrite it if I had to?

4. Use Claude to check your understanding, not just produce output

After Claude generates something, summarize your understanding of it back to Claude and ask if you've missed anything. It sounds slow. It's actually the fastest way to catch the gaps before they become bugs.

The long-term payoff

Projects built this way are slower upfront. But they're dramatically easier to maintain, extend, and hand off. You end up with code you own rather than code you're hosting.

Speed and quality aren't always at odds — but speed and understanding sometimes are. The builders who figure out how to protect both are the ones who don't end up firefighting forever.

If this resonates, I put together a free starter pack with some of these workflow patterns more fully fleshed out — prompts, checklists, and structure for shipping with Claude in a way that doesn't leave you confused about your own codebase: Ship With Claude — Starter Pack (free, no upsell).

Curious what workflows others have found useful here — what do you do to make sure AI-written code stays maintainable?

Why Your Claude-Generated Code Becomes Hard to Maintain (And How to Fix It)

Panav Mhatre — Fri, 12 Jun 2026 14:04:43 +0000

You've been using Claude for a few weeks. You ship faster. Features appear in minutes that used to take hours.

Then something breaks. You open the file to fix it and... you don't recognize the code. It works, but it's layered in a way you don't fully understand. There's logic in places you didn't expect. You make a small change and something unrelated breaks.

Sound familiar?

This isn't a Claude problem. It's a workflow problem — and most developers I talk to are hitting it.

The real issue: Claude fills gaps you didn't know you left open

Claude is very good at completing tasks. That's also the problem.

When you don't define the boundaries of a task explicitly, Claude makes reasonable inferences. And those inferences are usually locally correct — the immediate task gets done — but structurally problematic. Concerns get mixed. Files grow. Patterns drift.

It's not that Claude writes bad code. It's that Claude writes code optimized for the task you described, not the codebase you're trying to maintain.

Here's a concrete example of how this plays out:

You ask Claude to "add a loading state to this component."

Without constraints, Claude might:

Add state management inline rather than extracting it
Import a utility it creates on the fly rather than using one you already have
Silently restructure part of the component to make the change cleaner

Three requests later, your component is doing five things and you're not sure why.

The gap isn't prompting skill — it's structural context

There's a common assumption that if you're getting messy output, you need to write better prompts. That's partly true, but it misses the real issue.

Claude doesn't know your project's conventions unless you tell it. It doesn't know which files are in scope. It doesn't know that you keep auth logic separate from UI, or that you're avoiding a certain pattern for reasons you figured out two months ago.

Without that context, it improvises. And its improvisations are competent enough that you often don't notice the drift until you're three features in.

A better approach: brief before you delegate

What works better than better prompts is better briefing.

Before handing any meaningful task to Claude, I now write what I call a task brief — a short block at the top of my prompt that answers three questions:

What's in scope? Which files, components, or layers is Claude allowed to touch?
What patterns apply? What conventions should it follow or avoid?
What's the stopping condition? Should it ask before making structural changes, or just flag them?

It sounds like overhead. It isn't — it takes 30 seconds and saves you from hours of untangling later.

Here's a simple example:

Context: We're in /components/UserCard.tsx only.
Conventions: Use our existing useAsync hook for async state. Don't add new imports without asking.
Scope limit: If this requires changes outside this file, stop and describe what's needed instead of making the change.

Task: Add a loading skeleton while the user data is fetching.

That's it. That brief gives Claude enough structure to work within your system rather than around it.

The habits that prevent AI debt

Beyond task briefs, a few other things have made a big difference:

Treat Claude output as a first draft by default. Fast generation doesn't mean fast shipping. Build in a 5-minute "does this fit?" review before accepting any significant chunk of output.

Name the anti-patterns explicitly. If you've learned the hard way that you don't want deeply nested conditionals, say so. Claude can follow architectural constraints — it just needs to know they exist.

Use Claude for incremental changes, not whole-file rewrites. The larger the scope, the more it drifts from your existing patterns. Smaller, more constrained tasks produce code that fits better.

When something breaks, fix it before continuing. The temptation to keep generating and fix later creates compounding drift. Technical debt from AI moves faster than the old kind.

The underlying shift

The developers I see getting the best results from AI-assisted coding have made one key shift: they stopped thinking of Claude as a coder and started thinking of it as a contractor who builds exactly what's in the brief — and no more.

That shift sounds subtle. In practice, it changes everything about how you prepare, prompt, and review.

If this resonates and you're building with Claude regularly, I put together a free starter pack with the templates and workflow structure I use: prompt templates, a task brief format, a shipping checklist, and a reusable project structure that keeps Claude in its lane.

It's free — no email capture, no upsell: Ship With Claude — Starter Pack

Aimed at indie builders, students, and solo devs who want AI-assisted development that stays maintainable as projects grow.

Your Claude-Assisted Code Works. But Can You Actually Maintain It?

Panav Mhatre — Thu, 11 Jun 2026 14:04:04 +0000

There's a pattern I keep seeing with developers who use Claude or similar tools to build projects.

The first week is great. Velocity is high. Features ship fast. It almost feels like cheating.

Then around week two or three, something shifts. A bug appears and the AI-generated code around it is hard to follow. You ask Claude to fix it and it introduces two more issues. You add a feature and something unrelated breaks. The codebase starts to feel like it belongs to someone else.

This isn't a prompting problem. It's a workflow problem.

The Real Issue: AI Doesn't Know What You're Building

Here's what most tutorials won't tell you: Claude is excellent at generating code that looks correct for the input it receives. But it has no persistent sense of your architecture, your constraints, your naming conventions, or the decision you made three days ago about how state flows through your app.

Every new session, Claude starts fresh. If you don't actively bridge that gap, you end up with code that's locally coherent but globally inconsistent. Functions get duplicated. Patterns drift. The project slowly becomes a patchwork of micro-decisions made by a stateless assistant who didn't know about the last one.

What Changes When You Treat Claude as a Collaborator, Not a Generator

The builders who get the most sustainable results from Claude share a few habits:

1. They write structure first, code second

Before asking Claude to write a feature, they describe the system it's going into. Not a 10-page spec — just a paragraph. What does this module do? What doesn't it do? How does it connect to the rest? This gives Claude enough context to generate code that actually fits.

2. They verify against intent, not just output

The most dangerous output from an AI is confident-looking code that technically runs but does something subtly different from what you meant. The question isn't "does this work?" — it's "does this do what I actually need, and will I understand it in three weeks?"

3. They use checklists before shipping

Not to add bureaucracy, but because AI-assisted development creates a specific kind of blind spot: you're more likely to skip review when the code was generated quickly and looks clean. A short pre-ship checklist rebuilds that pause.

4. They reuse structure across projects

Instead of starting each prompt from scratch, they maintain a small library of prompt templates that already carry context — about their stack, their patterns, their standards. This dramatically reduces the drift between AI output and what the codebase actually expects.

The Hidden Cost of Moving Fast

There's a type of technical debt that AI coding creates which is different from the usual kind. Traditional debt is usually code you know is rough and plan to fix. AI debt is code you think is fine because it came from an intelligent-seeming source and passed your quick test.

That false confidence is expensive. Not on day one. On week four.

The good news: it's very preventable if you build the right habits early. It's mostly about designing your workflow so that AI output gets validated against your actual intent, not just tested for functionality.

A Free Resource If This Resonates

I've been building out a structured workflow around exactly this — prompts, a checklist, and a project structure designed for solo builders and students who want to ship things with Claude without creating a mess they can't maintain.

It's a free download: Ship With Claude — Starter Pack

No upsell trap — it's just the core system I'd give to a friend starting their first real project with Claude. 9 pages, 22KB, built for people who are actually going to build something with it.

What's been your experience with maintaining AI-assisted codebases over time? Curious what workflows or habits others have found that help.

Why Your AI-Generated Code Feels Clean But Breaks Everything Three Sprints Later

Panav Mhatre — Mon, 08 Jun 2026 14:05:31 +0000

There's a specific kind of pain that only AI-assisted developers know.

You open a file you shipped two weeks ago. The code is clean. Variable names make sense. Logic flows well. And you have absolutely no idea why it's breaking in production.

This isn't a bug story. It's a workflow debt story — and it's one of the least-talked-about problems with AI-assisted coding.

The Confidence Trap

When AI generates code that looks good, we tend to trust it more than we should.

Not because we're lazy. Because it reads like code written by someone who understands the problem. The naming is sensible. The structure is reasonable. It passes the obvious tests.

But AI doesn't understand your codebase. It understands your prompt.

That's a meaningful distinction. Your prompt described the surface of the problem. Your codebase has a shape — conventions, constraints, patterns that exist for reasons nobody writes down. The AI did its best with what you gave it.

What you got back is code that solves your prompt, not your system.

How Hidden Debt Accumulates

The failure mode isn't one bad commit. It's dozens of small optimistic decisions that each seem fine in isolation.

A utility function that duplicates one that already exists, but with slightly different behavior
Error handling that works for the happy path but silently swallows edge cases
State management that's technically correct but incompatible with how the rest of the app evolves
Naming that made sense in the context of the prompt but conflicts with how the team thinks

None of these are bugs. They're inconsistencies. And inconsistencies compound.

Three months later you're dealing with a codebase that works but is increasingly painful to change. You've accidentally imported speed debt — you moved fast now and made everything slower later.

The Root Cause Isn't the AI

Here's the uncomfortable part: this isn't really an AI problem.

Developers who ship maintainable AI-assisted code do something different before they write the first prompt. They define the problem boundary — what they're trying to change, what they're explicitly not changing, and what the output needs to fit into.

This sounds obvious. In practice, almost nobody does it.

Instead, the typical flow is:

Have a problem
Describe the problem to the AI
Get code that solves the description
Paste it in
Move on

The missing step is between 2 and 3: telling the AI what constraints it's operating inside.

What Actually Helps

Here are the practices I've found that reduce this kind of debt meaningfully:

1. Front-load your constraints, not just your requirements

Before describing what you want, describe what you're NOT willing to change. Which patterns should the output follow? Which abstractions already exist? Which decisions are already made?

AI is very good at satisfying constraints when you give them. The problem is we usually only give requirements.

2. Ask for a "before I write anything" summary

After your prompt, add: "Before writing any code, summarize what you understood from this request and what assumptions you're making."

This surfaces misalignments before they're baked into 200 lines of code. Half the time you'll catch something important.

3. Treat AI output like an external PR

Don't just check if it works. Check if it fits — naming conventions, abstraction level, error handling patterns. Ask yourself: if a new developer read this code in six months, would it feel like the rest of the codebase or like something that was dropped in from outside?

4. Keep a short project brief in your context

A 5-10 line description of what the project is, what patterns you're using, and what decisions are already locked. Paste it at the top of every significant prompt. Boring to write, dramatically reduces drift.

The Bigger Shift

The developers I've seen use AI most effectively think of it as a very fast implementation layer that needs clear direction — not an autonomous collaborator that understands what they're building.

That shift changes how you prepare. You spend more time thinking before prompting. You treat every output as something to integrate deliberately, not just accept. You verify understanding before execution.

It's slower at first. It gets faster quickly.

A Free Resource If This Resonates

I put together a free starter pack — Ship With Claude — for builders who want to use Claude more deliberately. It includes prompt templates, a shipping checklist, and a workflow structure built around exactly this kind of constraint-first approach.

It's free, no upsell required: https://panavy.gumroad.com/l/skmaha

Aimed at students and solo builders, but the framing applies to anyone who's found their AI-assisted code drifting in ways they didn't expect.

What's your experience with AI-generated code that looked right but aged badly? Curious whether others have run into this and what helped.

Your Claude-generated code works. That's the problem.

Panav Mhatre — Fri, 05 Jun 2026 14:03:14 +0000

There's a specific kind of project failure that's hard to recognize because it doesn't feel like failure at the time.

You open Claude. You describe what you need. Code appears. It runs. You commit. Repeat.

Six weeks later, you're staring at a codebase that technically works but that nobody — including you — can safely touch. Adding a feature feels like defusing a bomb. The tests pass but you don't trust them. You're scared to refactor because everything is connected in ways you can't quite see.

This is the most common shape of AI-assisted technical debt, and it's not caused by bad prompts. It's caused by not having a clear process for how you work with Claude — not just what you ask it.

The confidence gap

Claude is confident. Almost always. Whether it's right or not, it answers with the same assured tone. This is genuinely useful for moving fast, and genuinely dangerous when you're not in a position to verify.

The problem isn't that Claude gets things wrong. It's that you can't tell from the output when to trust it and when to push back.

Developers who use Claude well have internalized something like: treat Claude's output as a first draft from a competent but overconfident junior engineer. You wouldn't merge that engineer's PR without review. You shouldn't merge Claude's output without the same discipline.

But most people don't have a system for this. They have vibes.

The "it works" trap

"It works" is the most dangerous acceptance criterion in AI-assisted development.

When you're under pressure to ship, "it works" feels like enough. Claude produced something that passes your manual tests, you move on. But "it works" doesn't tell you:

Whether it handles edge cases
Whether the abstractions will hold when requirements change
Whether the naming and structure will make sense in three months
Whether you've introduced a subtle bug that only appears in production

These aren't problems Claude created. They're problems that exist in all software development. But AI-assisted coding creates pressure to skip the checks that normally catch them, because the output feels complete and authoritative.

What a workflow actually looks like

After going through this the hard way on a few projects, here's the structure that made the most difference:

1. Define before generating

Before you ask Claude to write anything, write down — in plain language — what the function should do, what it should not do, and what good output looks like. This sounds obvious. Almost nobody does it consistently. Without it, you're evaluating Claude's output against a fuzzy spec that only exists in your head.

2. Separate generation from verification

Don't generate and merge in the same session. Give yourself at least a beat — even 10 minutes — to come back to the output with fresh eyes. Read it like you're reviewing someone else's code. Ask: "If I didn't know Claude wrote this, would I approve this PR?"

3. Make uncertainty visible

When Claude is working in an area you don't fully understand, flag it. Add a comment. Open a note. Something. The danger isn't using AI in areas you're uncertain about — it's forgetting which parts of your codebase are "areas you were uncertain about."

4. Keep the context tight

Claude works best on contained, well-scoped tasks. The bigger the context you give it, the more it has to infer, and the more it can drift from what you actually want. If you find yourself writing paragraphs of context to get a good result, that's a signal to break the task down.

5. Own the architecture

Let Claude handle implementation details. Do not let Claude make structural decisions by default. Every time you ask "how should I structure this?" and accept the first answer, you're handing off a decision that will be hard to reverse. Structure decisions need to come from you, informed by Claude, not the other way around.

The thing under all of this

The builders I've seen get the most out of Claude aren't the ones who found the best prompts. They're the ones who figured out how to stay in charge of their own projects while using Claude as a force multiplier.

That means having a clear picture of what you're building before you start generating. It means reviewing Claude's output with the same skepticism you'd apply to any external contribution. It means knowing which decisions are yours and which ones Claude can help with.

This is less about technique and more about posture. Claude is extremely useful when you're directing it. It gets expensive — in time, in rework, in confusion — when it's doing the directing.

I've been thinking about this a lot lately and put together a free starter pack — prompts, a shipping checklist, and a workflow structure — for builders who want to move fast with Claude without ending up with a codebase they're afraid of. It's aimed at indie builders and students who are actually trying to ship things, not just experiment.

If any of this resonates, you can grab it free here: Ship With Claude — Starter Pack

No email required, no upsell on download. Just the pack.

Curious what patterns others have noticed. What's the thing that finally made AI-assisted development click for your workflow?

Why Your Claude-Generated Code Becomes a Mess (And How to Prevent It)

Panav Mhatre — Fri, 15 May 2026 21:38:11 +0000

There's a pattern I've seen play out over and over among developers who start using Claude heavily.

Week one: everything feels fast. Features are shipping. The code looks reasonable. You're loving it.

Week four: something subtle has gone wrong. The codebase is harder to navigate. Adding new things breaks old things in confusing ways. You're spending more time fixing Claude's fixes than you used to spend just writing code yourself.

What happened?

It's Not Bad Prompts. It's No Framework.

The reflex is to blame prompt quality. "I should write more detailed instructions." "I need to be more specific about what I want."

But in most cases I've seen, the problem isn't the prompts. The problem is the absence of a working framework for how to use Claude throughout a project — not just in a single session.

Claude doesn't have memory across sessions. It doesn't know what you decided three weeks ago, what your naming conventions are, or what constraints you established earlier. Every new session, you're starting fresh, and if you don't hold that context intentionally, the AI can't hold it for you.

The result is code that's technically functional but architecturally inconsistent. Different sessions produce different styles. Conventions drift. The codebase becomes a patchwork of "how I was thinking about this on Tuesday" and "how I explained it differently on Friday."

The Hidden Debt

This isn't a performance problem. It's a maintainability problem. And it sneaks up on you.

AI-generated code can look clean line-by-line while still accumulating what I think of as structural debt — decisions made in isolation, without an understanding of the broader system.

A few specific patterns that cause this:

Treating Claude like a search engine. You ask for a solution, it gives you one, you paste it in. No review of whether it fits the existing architecture. No consideration of edge cases that only make sense if you know your system's history.

Accepting "working" as the bar. If the tests pass and the feature ships, that's not enough. The question is: will another developer (or future you) be able to understand what's happening here? Does this code tell a coherent story?

No re-anchoring between sessions. When you start a new Claude session mid-project, you need to bring it up to speed on the context that matters — not just the current task. Most developers don't do this systematically. The result is that each session operates like a consultant who was hired yesterday and doesn't know the history.

Over-delegating decision-making. Claude is good at generating options and writing implementation. It's not good at knowing what matters most to your project. When you let it make architectural decisions by default (by not specifying constraints), you're outsourcing judgment you should be retaining.

What Intentional Use Looks Like

The developers who get good, long-term results from Claude tend to do a few things differently.

They treat their session setup as part of the work. Before asking Claude to write anything significant, they spend a minute establishing: what's the tech stack, what are the existing conventions, what are the constraints I want to preserve. This isn't elaborate — it's just deliberate.

They review for fit, not just function. When Claude returns code, they ask: does this fit how the rest of the codebase is structured? Is there anything here that only makes sense in isolation but breaks down when integrated? This is fast if you know what to look for.

They keep a lightweight "project brief" they can paste into new sessions. Even a 5-10 line summary of key decisions, architecture choices, and conventions dramatically improves consistency across sessions. Claude is very good at following explicit context. The problem is most people don't give it any.

They stay the engineer. Claude is a capable tool that can dramatically accelerate work — but the moment you stop being the decision-maker and let the AI direct the architecture, you're flying without instruments. Speed goes up. Visibility goes down. That's a tradeoff worth being intentional about.

A Free Resource

I put together a short pack — 9 pages, completely free — for builders who want to get more out of Claude without accumulating the technical debt that tends to follow fast AI-assisted development.

It covers the workflow patterns above in a practical format: how to structure your sessions, what to include in your project brief, how to approach verification, and how to stay in control of the architecture even when you're moving fast.

No upsell, no email required. Just the pack: Ship With Claude — Starter Pack

The goal isn't to make you slower. It's to make the speed you're already getting actually last.

What patterns have you found that help keep AI-generated code maintainable? Curious what others have figured out.

Why Your AI-Generated Code Works Today and Breaks Tomorrow

Panav Mhatre — Tue, 12 May 2026 14:09:12 +0000

I've been using Claude heavily for the past year — on greenfield projects, on legacy refactors, on one-night MVPs and slow-burn production systems. And I've noticed a pattern that I don't see talked about enough.

The code usually works. The problem comes three weeks later.

The False Confidence Problem

When you write code yourself, you accumulate a kind of working knowledge — not just what the code does, but why it does it that way, what you tried first, where the edge cases are, where the load-bearing assumptions live. That knowledge sits in your head and it makes you effective when something breaks.

When you generate code without deeply engaging with it, you ship without that map. The code is correct. The map is missing.

The system works until it doesn't. And when it stops working, no one knows where to start — not even the person who shipped it.

This isn't a failure of the AI. It's a failure of workflow.

The Speed Trap

AI-assisted coding is fast. Genuinely, impressively fast. And that speed creates a subtle trap: it makes not understanding feel fine, because understanding seems to slow you down.

But velocity without comprehension is just deferred debugging. You're borrowing time from your future self.

I've seen this play out in a few ways:

The unexplainable PR. You ship something, it works, then a teammate asks "why did you structure it this way?" and you have no good answer — because you didn't structure it, you accepted it.
The brittle integration. Two AI-generated modules that each work in isolation fail in ways neither their author nor the AI anticipated, because no one modeled the interaction between them.
The prompt loop. Something breaks, you paste the error back into Claude, it fixes it, something else breaks. You're debugging in circles because you don't have a model of the system — just a series of patches.

What Good Looks Like

The developers I've seen handle this well share a few habits:

They use AI for speed, not for understanding. They generate code faster, but they still read it — not to approve it, but to understand it well enough to maintain it. If they can't explain a function in plain language, they don't ship it.

They maintain an architecture in their head. Before writing (or generating) anything, they know how it fits. The AI fills in the implementation; they own the design.

They treat AI output as a draft, not a deliverable. A first pass from Claude is the beginning of a conversation, not the end. They push back, ask for alternatives, probe edge cases. The output improves and so does their understanding.

They define their interfaces before asking for implementations. This keeps the AI from making structural decisions it shouldn't be making. The contracts are human-defined; the filling-in is AI-assisted.

The Underlying Issue

Most of the frustration I hear from developers using AI tools comes from one of two things:

They don't know how to communicate their intent clearly enough to get useful output
They accept output without verifying it, then get surprised when it breaks in production

Both of these are workflow problems, not AI problems.

The AI isn't failing you. The workflow is failing you.

A Practical Starting Point

If you're building with Claude and finding that your projects feel fragile or hard to maintain, the issue is almost never the prompts themselves. It's usually the absence of a structured approach to:

how you communicate the architecture before asking for code
how you review and stress-test generated output
how you maintain continuity across a project that spans many sessions
how you keep your codebase from drifting as Claude makes locally-sensible but globally-inconsistent decisions

I put together a free starter pack specifically for this — prompt templates, a shipping checklist, and a workflow scaffold for working with Claude in a way that keeps your projects maintainable as they grow. It's aimed at solo builders, indie hackers, and first-time founders who want to move fast without creating a mess they can't debug.

No upsell, no email required — just a PDF you can use on your next project: Ship With Claude — Starter Pack (free)

If you've run into this pattern — code that works on Friday and breaks on Monday — I'd be curious what you've found helps. Drop a comment.

claude #ai #webdev #productivity

I Let Claude Write the Whole Thing. Here's What I Learned the Hard Way.

Panav Mhatre — Sun, 10 May 2026 14:30:39 +0000

Six months ago I shipped a project that I was proud of. Claude wrote about 80% of the code. It worked great on launch day.

Three weeks later I couldn't add a single feature without something else breaking.

This wasn't a prompt quality problem. I was writing detailed prompts. I was being specific about what I wanted. The issue was something subtler, and once I understood it, I changed how I work completely.

Here's what I figured out.

The real problem isn't the AI. It's the handoff.

When you work with Claude on a project, there's an invisible handoff happening at every step: you're transferring the responsibility for design decisions to the model, and the model is making those decisions based on what's locally coherent — not what's globally maintainable.

Every session, Claude starts fresh. It doesn't know why your auth module was structured a certain way last Tuesday. It doesn't know that you made a specific tradeoff in your database layer because of a constraint you discovered three sessions ago. It fills in those gaps with plausible guesses.

Individually, those guesses are fine. Accumulated over 30 sessions? You have a codebase that works but that nobody — including you — fully understands.

That's not AI failure. That's a workflow problem.

What I changed: session hygiene before anything else

The thing that helped most wasn't better prompts. It was treating each Claude session as a handoff between two contractors who don't share memory.

Before I start any session that touches existing code, I now write a brief context block. Not a massive doc. Just 5–10 lines covering:

What module I'm working on
What it's allowed to do (and what it's explicitly not responsible for)
Any constraints that aren't visible from the code itself
What "done" looks like for this session

This sounds bureaucratic. In practice it takes two minutes and it changes the quality of what Claude produces significantly. Not because the model suddenly became smarter — but because it stopped having to guess at things I should have told it.

The confidence trap

Here's the part I wish someone had told me earlier: Claude is confident by default.

When it doesn't know something, it doesn't usually say "I'm not sure how this fits into your architecture." It builds something that fits a reasonable interpretation of what you asked. That output looks right. It passes your quick review. You move on.

The cost doesn't show up until you're three features deeper and the whole thing starts fighting itself.

The fix is building in a verification step that isn't "does this look okay to me right now." It's closer to: "does this follow the structural contract this module was supposed to have?" That's a different question, and it requires you to have that contract written down somewhere before you generate the code.

Scope containment is a superpower

The other shift that helped: I stopped asking Claude to "implement feature X" and started asking it to "implement the data layer for feature X, nothing else."

Smaller scope, tighter output, easier review. When each session has a single clearly bounded job, the integration work becomes predictable. When sessions are open-ended, you get code that assumes things about adjacent parts of your system — assumptions you won't discover until something breaks in production.

This isn't about distrusting the model. It's about recognizing that you're the one who holds the system-level view, and acting like it.

One practical place to start

If any of this resonates, the most useful thing you can do today isn't switching tools or rewriting prompts. It's starting a PROJECT_CONTEXT.md file in your repo.

In it: write what your project does, what each major module is responsible for, and what the rules of the road are (error handling conventions, naming patterns, what should never happen in this layer).

Then, at the start of every Claude session that touches existing code, paste the relevant section.

You'll notice the difference within one or two sessions.

I put together a free pack around this kind of workflow structure — starter templates, a shipping checklist, and some prompt scaffolding for first-time Claude builders. It's free, no email required, no upsell. If you're working through this problem on a solo project, it might save you a few frustrating weeks: Ship With Claude — Starter Pack

If you've figured out other ways to handle the continuity problem with Claude sessions, I'd genuinely like to hear them. This is one of those things where everyone seems to be figuring it out independently and not sharing much.

Why Your Claude Code Rots (And How to Stop It Before It Starts)

Panav Mhatre — Sat, 09 May 2026 04:11:08 +0000

There's a pattern I've seen repeat across dozens of solo projects and small teams:

Week 1: Claude generates something. It works. You're flying.

Week 4: You need to add a feature. You open the codebase and feel faintly ill. You can't tell what's load-bearing and what's scaffolding. You try prompting Claude again. It makes things worse.

This isn't a model problem. It's a workflow problem — and it happens so early you usually can't see it coming.

What Actually Goes Wrong

Most people assume the issue is prompt quality. If their Claude output is messy, they think: "I need better prompts."

That's not quite right.

Prompts are requests. What breaks things is the structure you give those requests — or the absence of one.

Here's the specific failure mode I see most often:

You ship Claude's first-pass output without establishing a coherent structure first.

Claude is excellent at filling in a shape. It's much weaker at designing the shape autonomously when it has no context about your constraints, your project's specific invariants, or what "good" looks like for your codebase.

The result: you get code that compiles, passes your quick test, and ships — but whose internal logic is idiosyncratic. Each module makes slightly different assumptions. There's no consistent error-handling pattern. The naming is half yours, half whatever Claude defaulted to.

This is fine for a weekend hack. It becomes a serious liability the moment you try to build on top of it.

The Debt Is Invisible at First

What makes this especially tricky is that AI-generated technical debt doesn't look like debt.

Traditional tech debt is ugly. You can see it. It slows you down immediately.

AI-assisted debt often looks clean. The functions are named sensibly. There are docstrings. Unit tests exist. But the underlying structure was never designed — it was generated. And generated structure degrades fast under change.

The tell: every new feature requires you to fight the existing code rather than extend it. Or you find yourself completely re-explaining the codebase to Claude in every new session because it has no idea what your own project is doing.

The Fix Isn't More Prompts — It's More Structure

The builders I've watched who actually ship maintainable AI-assisted code all do some version of the same thing:

They design the interface before they generate the implementation.

Before they ask Claude to write code, they've written (in plain English or pseudocode):

What this module is responsible for
What it is not responsible for
What the inputs and outputs look like
What invariants must hold

Claude then works inside that container. It fills in a shape you've designed, rather than designing a shape from scratch.

This isn't new engineering advice. It's just that with AI-assisted coding, skipping it has become so easy — and so costly — that it's worth spelling out explicitly.

Context Sessions Are Their Own Problem

The other major source of rot: Claude doesn't remember your project between sessions.

Every conversation starts fresh. If you don't have a compact, accurate description of your system — something Claude can absorb quickly — you're re-inventing context every time. And if you do that informally ("just tell it what's going on"), Claude builds a picture from your description that may drift from reality.

A few things that help:

Keep a PROJECT.md that describes your app's architecture in 2-3 paragraphs. Update it as you build. Feed it to Claude at the start of sessions.
When you add a new module, write its "contract" before generating code: what it does, what it doesn't do, what error cases it handles.
After any significant refactor, update PROJECT.md before the session ends.

These feel like overhead. They're actually the minimum viable documentation for AI-assisted work — and they pay for themselves in saved debugging time within weeks.

Trust Your Output, But Verify the Structure

Claude is confident. That's part of why it's useful. But confidence doesn't mean correctness, and it definitely doesn't mean coherence with your existing system.

The single question I ask most often when reviewing AI-assisted code:

Could I explain why this is structured this way — not what it does, but why it's shaped like this?

If the answer is no, there's a problem. Not necessarily a bug, but a structural choice you don't understand and can't maintain.

That's the moment to pause and refactor before moving forward, not after three more features are built on top of it.

A Free Resource

I've been thinking about this problem for a while and put together a small free starter pack — prompts, a checklist, and a workflow structure for going from idea to MVP with Claude in a way that doesn't leave you with a mess.

It's aimed at CS students, interns, and first-time builders who are shipping with Claude for the first time and want to do it right from the start: Ship With Claude — Starter Pack (free, no upsell).

If you're already experienced, you probably have most of this figured out. If you're just starting, it might save you a few weeks of figuring it out the hard way.

What patterns have you found that keep AI-assisted codebases healthy? I'm genuinely curious what's working for others — drop a comment.

Your Claude-generated code works. Then it doesn't. Here's why.

Panav Mhatre — Wed, 06 May 2026 23:24:07 +0000

I've talked to a lot of developers who use Claude daily and describe the same arc:

"It worked great for the first week. Then the codebase got confusing. Now every new feature breaks something."

This isn't a Claude problem. It's a workflow problem — and once you see it, you can't unsee it.

The real issue: AI collapses the gap between "working" and "right"

When you write code by hand, there's a natural forcing function. The act of typing out logic makes you think through it. You notice when something doesn't fit. You slow down at the edges of your understanding.

With AI assistance, that friction disappears. Claude generates something that compiles, passes a few manual checks, and looks right. You move on.

Three weeks later, you have:

Two components doing the same thing, named differently
Utility functions scattered across files with no clear ownership
A module that started as a "quick helper" and is now load-bearing
Zero test coverage on the parts that matter most

None of this was the AI's fault. The AI did exactly what you asked. The problem is what you didn't ask — and what you didn't define before you started.

What's actually happening under the hood

Claude is a prediction engine operating on the context you give it. If your context is fuzzy — a vague feature description, an implied architecture, an assumption you never stated — it fills that fuzziness in with something plausible.

"Plausible" is not the same as "aligned with your system."

When you prompt Claude without first being explicit about:

What already exists and shouldn't change
What the target state looks like
What constraints apply (naming, patterns, file structure)
What "done" actually means

...you're essentially asking it to make architectural decisions for you. Sometimes that's fine. Often, it drifts.

The shift that actually helps

The most effective Claude users I've seen treat it less like an oracle and more like a contractor.

You wouldn't hand a contractor a vague brief and walk away. You'd spend time upfront making sure they understand the building's existing structure, what you want added, what they're not allowed to touch, and how you'll know the work is done.

That's the mental shift.

Before starting any feature with Claude, I now answer four questions explicitly:

What exists? (Which files are relevant. What the current behavior is.)
What should change? (The specific delta — not a vague description of the end state.)
What must not change? (Explicit constraints. Adjacent code, interfaces, conventions.)
What does done look like? (How will I verify this worked.)

When I brief Claude at this level, output quality goes up significantly. More importantly, the output fits — it doesn't create new confusion to clean up later.

The hidden cost of prompt speed

There's a seductive productivity loop with AI tools: prompt → accept → move on. It feels like velocity. And short-term, it is.

The debt shows up later. You're not adding features anymore — you're managing the inconsistency of a codebase that was shaped by dozens of half-specified prompts.

This is what I'd call AI-assisted drift: the codebase grows, but coherence shrinks. You end up spending more time context-switching and reading AI-generated code you don't fully trust than you would have if you'd been more deliberate from the start.

A practical checklist before your next AI coding session

Before you open Claude for your next feature, try this:

[ ] Write one sentence describing the exact change, not the desired outcome
[ ] List 2-3 files that are relevant
[ ] Name at least one thing that must not change
[ ] Define what you'll check to know it worked

It takes 3 minutes. It saves hours of cleanup.

Free resource if this resonates

I put together a starter pack around this approach — prompt templates, a shipping checklist, and a reusable project structure for keeping Claude-assisted work maintainable over time.

It's completely free (no email required, no upsell): Ship With Claude — Starter Pack

It's aimed at solo builders and developers who ship real things with Claude and want their projects to stay coherent over time — not just in the first sprint.

What patterns have you noticed in your own AI-assisted workflow? I'm curious whether the "briefing" approach resonates or if you've found different solutions to the drift problem.

The Hidden Cost of AI-Generated Code: Why Your Claude Project Becomes Unmaintainable (And How to Fix It)

Panav Mhatre — Tue, 05 May 2026 04:06:55 +0000

You start a project with Claude. The first week is incredible — features land fast, the code runs, you feel like a 10x developer.

Then, somewhere around week three or four, something quietly shifts. You ask Claude to modify a function and it breaks two other things. You ask it to add a feature and the solution doesn't fit the patterns already in your codebase. You open a file you "wrote" a month ago and realize you can't fully explain what it does.

This isn't a prompt problem. It's a workflow problem — and it's one that almost nobody talks about.

The Real Cost of AI-Assisted Speed

Here's what's actually happening: Claude is remarkably good at producing code that works right now. It's less naturally optimized for code that stays coherent over time as your project grows and changes.

When you move fast without a clear structure, you accumulate what I call AI debt — not just technical debt, but comprehension debt. Code you don't fully understand, architecture decisions that weren't made so much as generated, modules that are internally consistent but don't fit together coherently.

The warning signs:

You've started re-prompting the same kinds of fixes repeatedly
Claude's suggestions are getting longer and more convoluted
You feel like you're fighting the codebase instead of building on it
Onboarding anyone else (or your future self) feels impossible

Why This Happens: The Handoff Problem

Most developers using Claude fall into one of two failure modes:

1. The Oracle Mode: Treating Claude as a black box that produces output you ship without fully understanding. Fast in the short term, catastrophic for maintainability.

2. The Prompt Fatigue Loop: Crafting increasingly elaborate prompts trying to control Claude's output, burning time and context on workarounds instead of building.

Both patterns share a root cause: there's no clear protocol for what you own and what you're delegating. When that boundary is fuzzy, comprehension decays across sessions.

A More Sustainable Approach

This isn't about prompting better — it's about designing a better working relationship with the model. Here's what actually helps:

1. Establish ownership before you generate

Before you ask Claude to write something, be specific about what architectural decisions are already made. Don't let the model make structural choices implicitly — those are yours to make explicitly.

Bad: "Build me a user authentication system"

Better: "Using our existing Express middleware pattern and the session structure in auth.js, add email/password login. The session shape should match what's in types.ts."

2. Verify understanding, not just output

The question isn't "does this code work?" — it's "do I understand why it works?" If you can't explain a function to a colleague in plain English, you don't own it yet. Run it past Claude: "Explain what this does in plain English, then tell me what would break if X changed."

3. Keep a project brief Claude can reference

One of the highest-leverage things you can do: maintain a short BRIEF.md in your project root. It describes the architecture decisions, the conventions, the parts that are intentionally weird. Paste it at the start of each new session. This simple habit dramatically reduces drift between sessions.

A brief doesn't need to be long — a few paragraphs covering: what the project does, what the main patterns are, and what NOT to change. That's enough to anchor most sessions.

4. Distinguish between exploration and production

Some Claude sessions are explorations — prototyping, trying ideas, seeing what's possible. Others are production sessions — shipping real code into your system. These require different modes.

For exploration: give Claude a lot of latitude. Run fast.

For production: be explicit about constraints, verify outputs carefully, update your brief when architectural decisions get made.

Mixing these two modes without being intentional about it is one of the biggest sources of maintainability problems.

5. Treat the context window as a resource

Claude's context is limited. If you're loading a whole codebase into context and asking for a change, you're probably doing it wrong. Instead, think about what minimal context the model needs to make a good decision. This forces you to understand your own code better — and usually produces better output from Claude too.

The Meta-Lesson

The developers I've seen get the most out of Claude long-term aren't the ones with the best prompts. They're the ones with the clearest picture of their own system.

AI tools give you speed. They can't give you comprehension — that has to come from you. But if you design your workflow around maintaining that comprehension, you get both.

A Free Resource

I put together a starter pack for exactly this problem: a workflow + checklist + prompt templates built around maintaining clarity and ownership while using Claude. It's free, no upsell.

👉 Ship With Claude — Starter Pack (free)

It's aimed at developers and solo builders who are already using Claude and want to stop feeling like they're losing control of their projects. Nine pages, practically oriented, no fluff.

If you've hit any of these patterns — or found other strategies that work — I'd genuinely love to hear about it in the comments. This is one of those areas where the community's collective experience is way ahead of what's written down anywhere.