DEV Community: Learn AI Resource

Using AI to Debug Code Without Losing Your Mind

Learn AI Resource — Tue, 04 Aug 2026 15:00:24 +0000

Using AI to Debug Code Without Losing Your Mind

You know that moment? 3 AM, you've got a weird race condition that only happens on Wednesdays, and Claude is like "have you tried adding logs?" Yes. You've tried adding logs. You've tried everything.

Here's what actually works when you're debugging with AI: stop trying to describe the problem. Show it the problem.

The Wrong Way (That Everyone Does)

"Hey Claude, I have a Node app that crashes sometimes when under heavy load, any ideas?"

You'll get back a generic checklist. Memory leaks, async issues, event emitter warnings. All technically true, none of it actually helps.

The Right Way

Dump the actual error stack, relevant code snippets, and your recent git commits into the conversation. Even better: give AI a reproduction case. Something small that consistently breaks the same way. A specific test file. A 10-line script that triggers it.

Then ask specific questions:

"Why does this throw an error but only with concurrency > 100?"
"This worked in v16, broke in v20. What changed?"
"Walk through what's happening at line 47 step by step"

AI is terrible at vague problems. AI is weirdly good at explaining specific code.

Concrete Example: Memory Leak Debugging

I had a WebSocket server leaking memory. Every connection added ~100KB that never got freed. Annoying but not catastrophic at small scale.

Instead of asking "why is my server leaking memory," I:

Captured a heap snapshot after 1000 connections
Showed the detached DOM node count, listener counts, and memory timeline
Pasted the cleanup code in my disconnect handler
Asked: "What's keeping these listeners alive after disconnect?"

Claude immediately spotted it: I was adding to a Map on the class but never deleting the entries. Five-minute fix.

Without the heap dump? I'd still be flailing around guessing.

Tools That Actually Help

Chrome DevTools - Heap snapshots for Node apps. Export the JSON. Include it.

clinic.js - Profiles your app and shows flame graphs. Way better than just "CPU is high"

Node --inspect - Remote debugging. You can actually watch the code execute.

git diff + git log - Show what changed recently, not your guesses about what might have changed.

The secret: AI debugging isn't magic. It's just having the right context so the AI can actually help instead of spitballing.

The Real Win

Stop thinking "AI will solve this for me." Think "AI will help me understand this faster if I give it the actual evidence."

You're not outsourcing the debugging. You're giving yourself a pair of fresh eyes that's available at 3 AM and won't get annoyed at your fifth question about the same thing.

Want to stay sharp on the tools and techniques actually worth learning? Join LearnAI Weekly for practical AI tips from real development work — no fluff, just what works.

Stop Pasting Stack Traces to ChatGPT: Build a Real Debugging Workflow

Learn AI Resource — Mon, 03 Aug 2026 15:00:35 +0000

Your error message shows up. You copy-paste it to ChatGPT. You get a generic answer. You waste 20 minutes. We can do better.

The problem? Most of us treat AI as a search engine substitute instead of a debugging partner. Here's how to actually integrate AI into your workflow so it catches stuff before production.

The Setup That Actually Works

Install these locally (no cloud required):

# Ollama for local LLM (runs on your machine)
brew install ollama
ollama pull neural-chat

# Or use your existing API if you prefer
export OPENAI_API_KEY=your_key_here

Create a .debug directory in your project:

.debug/
├── error-context.md
├── logs/
└── snapshots/

The Workflow

Step 1: Capture Context, Not Just Errors

When something breaks, don't just grab the error. Grab context:

# Create a debug snapshot
echo "## Error at $(date)" > .debug/error-context.md
echo "### Stack Trace" >> .debug/error-context.md
your-app-command 2>&1 | tee -a .debug/error-context.md

# Add recent changes
echo "### Recent Commits" >> .debug/error-context.md
git log --oneline -5 >> .debug/error-context.md

# Add environment
echo "### Environment" >> .debug/error-context.md
env | grep -E "NODE|PYTHON|DB_" >> .debug/error-context.md

This file becomes your AI's input. It's everything the AI needs to help you.

Step 2: Ask the Right Question

Wrong: "Why am I getting this error?"
Right: "Given this context, what changed recently that could cause this? What should I check first?"

# If using local AI
cat .debug/error-context.md | ollama run neural-chat "Analyze this error with context. What's the most likely cause? What do I test first?"

# If using API
curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{  
    "model": "gpt-4",
    "messages": [{
      "role": "user",
      "content": "'"`cat .debug/error-context.md`""'

Dont give me generic debugging steps. Tell me specifically what changed that caused this."
    }]
  }'

The difference: you're not asking "what's wrong" — you're asking "given what you see, what's the fastest fix?"

Step 3: Verify Before You Trust

AI can be confidently wrong. Add a verification step:

# Before you apply the fix, test it in isolation
# Example: if AI says "check your DB connection"
npm test -- --grep "database.*connection"

# Or reproduce with minimal code
cat > .debug/test-hypothesis.js << 'EOF'
// Test only the thing AI suggested
const db = require('./db');
db.connect().then(() => {
  console.log('Connection works');
  process.exit(0);
}).catch(err => {
  console.error('Connection fails:', err.message);
  process.exit(1);
});
EOF

node .debug/test-hypothesis.js

If the fix works in isolation, apply it. If it doesn't, you have evidence to push back on the suggestion.

Real Example: The Silent Cache Bug

Your API returns stale data. You check Redis, it's fine. You check the code, it's fine. Classic.

Your debug file captures:

The exact response with timestamp
Your recent refactor (moved cache invalidation logic)
Environment config
Server logs from the time it happened

You ask the AI: "I moved cache invalidation to a different function last Tuesday. The timestamps show the data got cached after my change. What did I miss?"

AI responds: "You're probably invalidating in the old location. Check if you have two cache implementations."

You grep for it. Found it. 30 seconds instead of 30 minutes.

Tools That Actually Help

Local options (privacy + speed):

Ollama + neural-chat: Free, runs on your machine
LM Studio: GUI wrapper, easier to use

API options (more power):

Claude (Anthropic): Best for understanding weird edge cases
GPT-4: Fast, good for quick questions
Sonnet (Claude 3.5): Sweet spot for most bugs

Pick one and stick with it. You'll learn how to ask it better questions.

The Habit

Error happens
Grab context (30 seconds)
Ask AI with the context (1 minute)
Test the hypothesis (2-5 minutes)
Apply the fix or dig deeper

Boring? Yes. Effective? Also yes.

The magic isn't the AI. It's the context. Most of us give AI 5% of the information it needs. That's why the answers are generic. Give it 95% and you'll be shocked how specific the advice becomes.

Want practical tips on building better dev workflows? Check out LearnAI Weekly — real strategies for actually shipping faster, not just hype.

Happy debugging.

Debug Faster: AI Tools That Actually Catch Your Mistakes

Learn AI Resource — Sun, 02 Aug 2026 15:00:27 +0000

You know that feeling when you spend 20 minutes staring at a bug that turns out to be a missing semicolon? Yeah. We've all been there. The annoying part isn't the bug—it's that you knew where to look, you just didn't look carefully enough.

That's where AI debugging tools shine. Not as replacements for your brain, but as tireless pairs of eyes that never get bored or distracted.

The Stack Trace Translator Problem

Ever gotten a stack trace so cryptic it might as well be written in ancient hieroglyphics? Throwing it into Claude or ChatGPT usually works, but you're context-switching, pasting things around, losing flow.

Tools like Cursor (the IDE, not the pointer) changed the game. You can highlight a stack trace, ask the AI what's happening, and get context-specific explanations without leaving your editor. Same with GitHub Copilot Chat—I paste an error, it suggests fixes immediately.

The time saved isn't huge per bug, but it adds up fast. Five minutes saved per day is 20+ hours per year. That's not nothing.

The "Wait, Does This Actually Work?" Test

Before I trust an AI fix, I actually run it. Which sounds obvious, but here's the trick: ask the AI to explain why the fix works. If it can't, I don't trust it.

Example: error about missing dependency. Copilot says "add this import." But is that actually fixing the root cause? Ask it. "Walk me through why this import fixes it." If the explanation makes sense, I proceed. If it doesn't, it's either hallucinating or I'm missing context.

Most AI tools are genuinely good at this kind of reasoning now. They're not perfect, but they're better than a random Stack Overflow answer.

Real Debugging Setup (Not Magic)

Here's what actually works in practice:

Logs first. Before asking AI anything, look at your actual logs. Add console statements if needed. AI can't debug what it can't see.
Cursor or VS Code + Copilot. Highlight weird code, ask "what does this do?" or "why might this fail?" Instantly.
Claude for complex stuff. Paste the whole file, explain the context, ask for help. It's slower but handles gnarly problems better than inline tools.
Run the fix locally. Don't just trust it. Confirm the behavior changes the way you expect.
Document it. If it's a weird fix, add a comment. Future-you will thank you.

The Productivity Multiplier

The real win isn't about AI being smarter than you. You're smarter. The win is that AI is faster at boring stuff:

Explaining cryptic error messages
Spotting typos you've looked past 10 times
Suggesting the obvious fix you somehow missed
Writing boilerplate test cases that confirm the fix works

You focus on the hard stuff—understanding why the bug happened, designing a better system so it doesn't happen again.

What Doesn't Work

I've tried asking AI to debug production outages without logs. Spoiler: it's useless. AI is great at explaining things, not great at guessing. Give it the data, it helps. Leave it guessing, you get a confident hallucination.

Also, AI is slower at fixing really new problems. If you're working with brand-new libraries or unusual patterns, AI might not have seen enough examples to help. Fall back to docs and experimentation.

The Honest Truth

You're still the debugger. AI just moves faster. Think of it like autocomplete for debugging—you still drive, it just knows common patterns and points out what you might've missed.

The developers I know who got good with AI tools aren't the ones who stopped thinking. They're the ones who think faster, asking clearer questions and confirming better.

Want to stay sharp with new tools and techniques? I write about practical AI, productivity systems, and real developer problems over at LearnAI Weekly—no fluff, just stuff that works.

Why Your Prompt Templates Aren't Working (And How to Fix Them)

Learn AI Resource — Sat, 01 Aug 2026 15:00:39 +0000

You spent 3 hours crafting the "perfect" prompt template. You saved it. You reused it a hundred times. And somewhere around try #47, you realized it only works like 60% of the time.

Sound familiar?

This is the dirty secret nobody talks about with AI tools. You can't just template-ize prompts like they're database queries. Every context is different, every code base is weird in its own way, and what works Tuesday breaks on Wednesday.

The Template Trap

Here's what people usually try:

You are an expert [ROLE].
Your task is to [TASK].
Follow these rules:
- Rule 1: [RULE]
- Rule 2: [RULE]
Analyze the following: [INPUT]

Then they fill in the brackets and hope. Sometimes it works. Sometimes you get garbage.

The problem? You're treating AI like a function with fixed inputs. It's not. You're working with a probabilistic system that responds to context, tone, and specificity in ways you can't fully predict.

What Actually Works

1. Context Over Structure

Instead of rigid templates, build modular context blocks you can mix and match.

Bad approach:

Analyze this code for bugs.

Good approach:

I'm debugging a Node.js service that handles real-time WebSocket connections. 
The app crashes randomly under load (>500 concurrent connections).
I've already checked logs—no error messages, just hard exits.
Here's the relevant code:
[CODE]

What would cause a silent exit without logging?

The difference? You're giving the AI your actual problem, not a generic template.

2. Fail Gracefully, Then Ask

Don't expect one prompt to solve everything. Build a two-stage process:

Stage 1: Quick sanity check

Does this look normal to you? (Yes/No + brief reason)
[CODE SNIPPET]

Stage 2: If it fails, deep dive

Something's wrong here. Let me give you more context:
[FULL LOGS]
[SYSTEM INFO]
[WHAT I'VE ALREADY TRIED]

Why might this be happening?

This isn't laziness—it's how you actually debug. You don't throw your entire codebase at a senior dev and say "fix it." You describe the symptom, get feedback, then dig deeper.

3. Examples Beat Rules

Instead of telling AI what to do, show it.

Bad:

Write clear comments in casual developer language.

Good:

I want comments like these:
// lol this is why we cache the user object
// setTimeout hack because the API is trash at batching
// TODO: replace this with actual error handling someday

Write comments for the following function:
[CODE]

Show examples of your actual voice, your actual style. AI will match the pattern much better than it matches abstract rules.

4. Temperature Matters (But Not How You Think)

You can't just blast everything with max temperature hoping for creativity. Different tasks need different settings:

0.3-0.5: Code generation, bug fixes, technical facts (low variance, high consistency)
0.7: Content writing, brainstorming ideas, refactoring suggestions (balance of creativity + reliability)
0.9+: Creative writing, naming things, weird edge cases (throw at the wall and see what sticks)

If your template works for code but fails for copy, you might just need different temperature settings for different prompts.

The Real Pattern

Successful prompt workflows look less like "one perfect template" and more like:

Start stupid - Ask the simplest version of your question
Provide feedback - "That's close but..." or "You're on the right track..."
Iterate - Include the previous response in the next prompt
Converge - It gets better with each loop

This is actually how you'd work with a junior dev. And it works with AI tools too.

A Real Example

I needed to refactor some gnarly TypeScript. Here's how it actually went:

Prompt 1:

Can you refactor this function to be more readable?
[FUNCTION]

Got back something overly clever. Not what I wanted.

Prompt 2:

That's too clever. I need it simple and obvious, not fancy.
The priority is "someone new to the codebase understands this immediately."
Try again with that goal.

Better, but missed a pattern I wanted.

Prompt 3:

You got it mostly right. One more thing—can you extract the 
validation logic into a separate function? I want to unit test it.
Otherwise, keep the rest as-is.

Done. Three prompts, each building on the previous.

Could I have written a "perfect template" that nailed it in one shot? Maybe. But it would've taken longer to design than just iterating three times.

The Productivity Hack

Stop trying to make templates that work for all cases. Instead:

Keep a prompt playbook - Not templates, but starting points
Note what works - When something lands well, write down what made it work
Reuse patterns, not exact text - "How do I structure a prompt for X type of task?"
Iterate like you mean it - Treat each response as feedback, not the final answer

Your prompts will get better, faster, and more reliable.

The irony? You'll end up with templates that work because you stopped trying to make generic ones.

Want to stay on top of AI tools, productivity hacks, and developer resources that actually matter? Check out LearnAI Weekly for curated insights that'll actually help you ship faster.

AI-Assisted Code Reviews: Your New Pair Programmer

Learn AI Resource — Fri, 31 Jul 2026 15:00:32 +0000

AI-Assisted Code Reviews: Your New Pair Programmer

Let's be real—code reviews are necessary but tedious. You're already tired, and now you have to nitpick someone's variable names while staying constructive. What if you had a second pair of eyes that never gets grumpy?

The Problem With Manual Reviews

Manual code reviews catch bugs, but they're slow. They're also subjective. One reviewer gets picky about formatting, another misses the logic error entirely. And if you're working async across timezones? Review turnaround can tank productivity.

Plus, junior devs often don't know what to look for. They'll approve code that has subtle performance issues or security holes because they haven't seen that pattern before.

The AI Approach (Actually Works)

Tools like Claude, ChatGPT, and specialized models like GitHub's Copilot can review code in seconds. But here's the trick: they're not replacing your reviews. They're handling the grunt work.

Here's what I've done with real projects:

Step 1: Automated pre-review screening

Before code hits your team, run it through Claude or a specialized linter AI. Input the diff. Get back:

Obvious bugs (null pointer risks, off-by-one errors)
Security issues (SQL injection, unvalidated inputs)
Performance flags (unnecessary loops, memory leaks)
Style inconsistencies

This takes 10 seconds instead of 5 minutes of human eyeballs.

Step 2: Context-aware suggestions

Paste the code with context—what it's supposed to do, the architecture it fits into. Ask Claude specifically: "Does this integrate cleanly with our existing cache layer?"

Real example: A junior dev wrote a fetch function that re-initialized the database connection every call. Claude spotted it immediately, suggested using a connection pool, and even provided a refactor. Without AI, that would've gone to production and caused latency issues a week later.

Step 3: Test coverage analysis

Paste the code and ask: "What edge cases aren't covered by tests?"

The model will typically catch:

Null/undefined handling
Boundary conditions
Error state handling

Then your team's review focuses on the business logic and architecture decisions—the stuff that actually matters.

The Real Workflow

Here's how I actually use this:

Developer submits PR
GitHub Actions runs tests + AI review (takes 30 seconds)
AI comments appear automatically: "Line 47: Potential race condition if X happens"
Developer sees it instantly, fixes it or responds
Human reviewer then looks at a cleaner PR, focuses on design decisions

You're not replacing humans. You're making human review faster and smarter.

Tools Worth Your Time

Claude API (v3.5 Sonnet is solid for code) — $3-5 per review, batched
Copilot for Business — integrated into GitHub, no per-review cost
SonarCloud — traditional, but good at security patterns
DeepSource — AI-native code quality, growing fast

Pick one that fits your workflow. Most have free tiers if you want to experiment.

The Catch

AI isn't perfect. It'll sometimes flag false positives (variable named result → "avoid generic names"). It might miss context-specific issues (why you're doing something the "wrong way" intentionally).

So: Human + AI = 10x better than either alone.

Quick Wins You Can Try Today

Take your last three failed deploys. Run the code through Claude. Would it have caught them?
Grab a recent PR that had bugs found in QA. Ask an AI to review it blind. Did it catch what humans missed?
Time a manual review vs AI review of the same code. Measure the delta.

You'll probably find AI catches the boring stuff while humans catch the subtle design flaws. That's exactly how it should work.

Want more practical AI tools for developers? Check out LearnAI Weekly—it's a solid resource for staying updated on what actually works (not the hype).

Stop Code Reviewing in the Dark: How Claude Became My Unofficial Senior Dev

Learn AI Resource — Thu, 30 Jul 2026 15:00:38 +0000

You know that feeling when you ship code and three days later you're staring at a Slack message saying "hey, did you consider X?" Yeah, I lived that life too. Now I don't.

Here's the thing: code review tools show you syntax problems. Claude shows you logic problems. Architecture issues. Performance gotchas. The stuff that makes you go "oh crap, I didn't think about that" at 2 AM.

The Problem With Traditional Code Review

Your team's doing their best. PR comments are helpful. But let's be honest: by the time someone reviews your code, they're context-switching from six other things. You get surface-level feedback. Typos, naming conventions, maybe a "consider using a Set here instead of an Array" comment if you're lucky.

The deeper stuff? The stuff that bites you in prod? That slips through because it's not visibly broken—it's just... fragile.

How I Actually Use Claude Now

I treat Claude like a senior dev who's read every architecture book and never has a bad day. Here's my actual workflow:

Step 1: Paste the code. Just dump it. I usually include the function and maybe 10 lines of context.

async function getUserPosts(userId, limit = 10) {
  const posts = await db.query('SELECT * FROM posts WHERE user_id = $1 LIMIT $2', [userId, limit]);
  return posts;
}

Is there anything I should think about here?

Step 2: Ask specific questions. Don't just say "review this." Say what you care about.

"Will this scale if we hit 100K users?"
"What security issues do you see?"
"Is my error handling solid?"
"Show me three ways this could break in production."

Step 3: Read the response like it's gospel. Not because Claude's always right—it's not—but because it's usually right, and the mental model it gives you is gold.

Real example: I pasted a caching function that I thought was solid. Claude said: "What happens if two requests hit this simultaneously while the cache is empty? You'll spawn two identical DB queries instead of waiting for the first one."

Mind blown. I'd shipped that exact pattern three times. Never caught it in review.

Practical Patterns That Actually Work

The "rubber duck, but smarter" pattern:

I'm trying to optimize this API endpoint. It's handling 500 requests/second but I'm seeing memory climb. Here's what I'm doing:

[paste code]

What's the leak?

Claude will usually spot N+1 queries, closure leaks, or unresolved promises before your APM tools even notice.

The "what could go wrong" pattern:

This function validates user input for a payment form. Assume the worst-case scenario. What's the exploit vector?

[paste code]

You'll catch SQL injection risks, auth bypasses, or race conditions that would've turned into a 2 AM incident.

The "am I overthinking this" pattern:

I'm about to refactor this whole service to use a message queue. Is that actually necessary, or am I solving the wrong problem?

[paste code + context]

Claude will tell you if you're optimizing prematurely or if you're about to dodge a bullet.

Why This Beats Other Approaches

vs. linters: Linters catch style. Claude catches intent.

vs. static analysis: Tools like SonarQube flag issues. Claude explains why it's an issue and how to fix it.

vs. humans: Humans are slower, more tired, and context-switching. Claude reads your code at 3 AM like it's the most important thing in the world.

vs. doing nothing: Yeah, we know this one.

The Catch

Claude's not perfect. Sometimes it gives you answer-shaped hallucinations. Sometimes it misses context. The move:

Treat it like a suggestion, not law. If something feels off, dig in.
Ask follow-up questions. "Why would that be a problem? Show me an example."
Test the advice. Run the refactored code. See if it's actually faster.
Compare to your actual metrics. If Claude says something's a bottleneck but your profiler says otherwise, trust the profiler.

The Real Benefit

After three months of doing this, something weird happened: I started thinking like Claude was looking over my shoulder. I'd catch my own issues before pasting. Architecture decisions got better. I stopped shipping the same types of bugs.

That's the actual win. Not that Claude reviews your code—it's that you internalize better practices through the dialogue.

Try This Tomorrow

Pick one function you shipped recently that you've thought twice about. Paste it to Claude with "What's wrong with this?" and see what comes back.

Odds are: you'll learn something. Something you'll use on the next function.

That's how you build better code. One review at a time.

Want to stay sharp on developer tools like this? Check out LearnAI Weekly newsletter for practical AI + productivity patterns that actually land in your workflows.

Building Production AI Features Without Becoming an ML Engineer

Learn AI Resource — Wed, 29 Jul 2026 15:00:59 +0000

Building Production AI Features Without Becoming an ML Engineer

You don't need a PhD in machine learning to ship AI features. Seriously. I've watched developers over-engineer solutions when they could've grabbed Claude's API, thrown some prompts at it, and shipped.

Here's the real talk: the hardest part isn't the ML. It's knowing what to actually build and not gold-plating it.

What Changed (And Why You Should Care)

Two years ago, using AI in production meant dealing with model deployment, scaling issues, and weird edge cases. Now? You call an API. The model sits somewhere else. Your job is wiring it into your app smartly.

The shift: from "build ML systems" to "integrate intelligence into your existing app."

Three Patterns That Actually Work

1. The Classifier (Replace Your Decision Trees)

Got complex logic for routing, categorization, or prioritization? Stop writing cascading if-statements.

Real example: Triaging support tickets by urgency and category.

async function classifyTicket(ticketText) {
  const response = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.ANTHROPIC_API_KEY,
      'content-type': 'application/json'
    },
    body: JSON.stringify({
      model: 'claude-opus',
      max_tokens: 200,
      messages: [{
        role: 'user',
        content: `Classify this support ticket:

Ticket: "${ticketText}"

Respond in JSON:
{
  "category": "billing|technical|feature_request|other",
  "urgency": "critical|high|normal|low",
  "reason": "one sentence why"
}`
      }]
    })
  });

  const text = response.content[0].text;
  return JSON.parse(text);
}

Why this beats hardcoded rules:

New edge case comes up? Retrain is literally just... running it again
Your rules scale with real-world messiness, not your imagination
Takes 20 minutes instead of 3 hours of conditional hell

2. The Extractor (Stop Writing Regex)

Parsing semi-structured text is a nightmare. Regex lies to you. Parsing libraries are overkill.

Real example: Extracting structured data from invoice PDFs or email content.

async function extractInvoiceData(invoiceText) {
  const response = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.ANTHROPIC_API_KEY,
      'content-type': 'application/json'
    },
    body: JSON.stringify({
      model: 'claude-opus',
      max_tokens: 500,
      messages: [{
        role: 'user',
        content: `Extract structured data from this invoice:

${invoiceText}

Return JSON:
{
  "vendor": "company name",
  "invoice_number": "string",
  "amount": number,
  "due_date": "YYYY-MM-DD",
  "line_items": [
    { "description": string, "quantity": number, "price": number }
  ]
}`
      }]
    })
  });

  const text = response.content[0].text;
  return JSON.parse(text);
}

Why this beats parsing libraries:

Handles fuzzy, human-written formats naturally
Extracts meaning, not just patterns
One function handles 10 different invoice formats

3. The Brainstormer (Augment, Don't Replace, Users)

This one trips people up. Don't ask AI to make decisions for your users. Ask it to give them options or spark ideas.

Real example: Content recommendation or idea generation.

async function generatePostIdeas(topic, tone) {
  const response = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.ANTHROPIC_API_KEY,
      'content-type': 'application/json'
    },
    body: JSON.stringify({
      model: 'claude-opus',
      max_tokens: 1000,
      messages: [{
        role: 'user',
        content: `Generate 5 blog post ideas about "${topic}" in a ${tone} tone.

For each idea:
- Title (under 60 chars)
- Angle (what's different about this take)
- Why readers will click

Make them concrete, not generic.`
      }]
    })
  });

  return response.content[0].text;
}

Why this works:

Users make the final call (they should)
Saves them 10 minutes of blank page syndrome
You're helping, not automating away the human part

The Gotchas (Real Ones)

Cost creeps up quietly. Log your token usage. A classifier running 10k times/day at $0.015 per 1k tokens adds up.

Latency matters more than you think. If your classifier takes 2 seconds, that's a bad UX when it was instant before. Use streaming for longer outputs.

Bad prompts = bad output. Spend 15 minutes on the prompt. Iterate. Test edge cases. Your prompt IS your model.

Context is cheap until it isn't. Send relevant context, not your whole database. 100k tokens gets expensive fast.

The Practical Setup

Pick a provider. Claude (Anthropic), OpenAI, Cohere. They're all solid. Pick one and learn it deeply instead of context-switching.
Environment variables, not hardcoding. process.env.ANTHROPIC_API_KEY. Every time.
Timeouts and retries. APIs go down. Network hiccups happen. Handle gracefully:

async function callAIWithRetry(prompt, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      const response = await fetch(..., { timeout: 30000 });
      return response;
    } catch (error) {
      if (i === maxRetries - 1) throw error;
      await new Promise(r => setTimeout(r, 1000 * (i + 1)));
    }
  }
}

Test the outputs. Have a human review sample results. Bad data will hide until production.

What You Actually Need to Learn

Prompt engineering (the real skill now)
Token counting (so cost surprises don't happen)
How to frame problems so the API understands them
Error handling (APIs are flakey)

You don't need to learn transformers, backpropagation, or linear algebra.

Next Steps

Pick one small thing in your app that could use intelligence:

Classifying something
Extracting data from text
Generating variations of content

Build it in an afternoon. Deploy it Monday. Measure if it actually helps.

Don't wait for the perfect setup. The barrier is lower than you think.

Want more on AI in production? Subscribe to LearnAI Weekly for practical tips on shipping AI features without the hype. Real examples, real code, no buzzwords.

Stop Reviewing Code Like It's 2020: An AI-First Workflow That Actually Works

Learn AI Resource — Tue, 28 Jul 2026 15:00:33 +0000

Your PR review process is probably slow. Someone reads 400 lines of code, gets distracted by the formatting, misses the actual logic bug, and then two weeks later production breaks because nobody caught it.

Here's the reality: AI is better at spotting certain issues than you are. Not all issues. But some. And if you're not using it to handle the tedious parts, you're throwing away 20% of your time.

The Old Way vs. The Actually Useful Way

Dumping your entire codebase into ChatGPT and asking "is this good?" doesn't work. That's cargo cult programming.

What does work:

Automated format & lint checks (your CI should handle this)
AI for security pattern matching (using focused prompts)
AI for test coverage gaps (it's surprisingly good at this)
Humans for business logic and architecture (keep this)

The split matters. Don't ask AI to judge whether your architecture is elegant. Do ask it to find the off-by-one error in your loop or spot the unhandled exception.

Practical Setup That Takes 30 Minutes

Step 1: Use Claude or GPT for Pattern-Based Reviews

Create a simple script that sends isolated functions to an LLM:

# Extract a function from your PR
git diff HEAD~1 | grep -A 20 "^+" > /tmp/changes.txt

# Send to Claude via API
curl https://api.anthropic.com/v1/messages \\
  -H "x-api-key: \$ANTHROPIC_API_KEY" \\
  -H "content-type: application/json" \\
  -d @- << EOF
{
  "model": "claude-opus-4-1",
  "max_tokens": 500,
  "system": "You are a code reviewer. Find: (1) security issues, (2) memory leaks, (3) off-by-one errors, (4) missing null checks. Return ONLY the issues found, not praise.",
  "messages": [{"role": "user", "content": "Review this code change:\n\n\$(cat /tmp/changes.txt)"}]
}
EOF

This takes 3 seconds. It catches about 60% of real bugs that make it past your eyes.

Step 2: Test Coverage Analysis

AI is weirdly good at spotting what should be tested but isn't:

# Run coverage report, send to Claude
coverage report --format=json | curl https://api.anthropic.com/v1/messages \\
  -H "x-api-key: \$ANTHROPIC_API_KEY" \\
  -d '{"model": "claude-opus-4-1", "max_tokens": 300, "messages": [{"role": "user", "content": "Given this test coverage report, what critical paths are missing test cases?\n\n\$(cat /tmp/coverage.json)"}]}'

You get a ranked list of "you probably need to test this" suggestions. Often right.

Step 3: The Human Part (The Actually Important Part)

Once the AI handles security patterns and test gaps, your human review becomes sharper:

Does this solve the actual problem?
Will this scale?
Did we miss a cheaper approach?
Is the API design intuitive for callers?

These are judgment calls. They're what you're paid for.

Real Example: Catching the Subtle Ones

I ran this workflow on a real PR last week. The change was a refactor of our caching layer:

What the author caught: "I moved the TTL calculation to a helper function."

What the AI caught: "The helper function doesn't validate that ttl > 0\. If a config value is negative, this silently caches forever."

What I caught: "Agree with AI, and we should bump up the integration test coverage here because this is a common config mistake."

All three caught different things. The AI would've missed the business judgment; humans would've missed the silent-forever-cache bug; the linter wouldn't care because there's no syntax error.

The Tools I Actually Use

Cursor or GitHub Copilot for in-editor suggestions (saves time, usually accurate)
Claude via API for structured code reviews (best at finding real logic bugs)
Shellcheck and pylint for the stuff you don't need AI for (it's free automation)

For the newsletter link, if you're staying on top of AI and productivity trends, grab the weekly dose at https://learnairesource.com/newsletter — it's the good stuff without the hype.

The Honest Part

AI code review isn't magic. It won't replace code review. It will replace the boring parts of code review — the parts where you skim looking for null\ checks and buffer overflows.

And honestly? Your brain is better used thinking about system design than hunting for typos.

Use the tool for what it's good at. Keep humans in charge of what matters.

How AI Context Windows Changed My Code Review Process (And Yours Can Too)

Learn AI Resource — Mon, 27 Jul 2026 15:00:37 +0000

If you're still copy-pasting code snippets one at a time into Claude or ChatGPT for reviews, you're leaving massive productivity on the table.

Last month, I started throwing entire pull requests—full diffs, test files, related modules—into a single prompt. The difference? I stopped getting generic advice about "code quality" and started getting specific, actionable feedback on actual architectural problems in my codebase.

This isn't rocket science. It's just using the tools we have better.

The Old Way (And Why It Sucked)

You'd ask: "Review this function."

AI would say: "Consider adding error handling and type safety."

You'd think: "Cool, thanks, totally unhelpful."

Why? Context. Without seeing:

What this function is actually used for
What the error cases look like
How the surrounding code handles similar problems

...an AI is just following a checklist. It's not reviewing your code. It's reviewing a snippet.

The New Way: Dump Everything

Here's what I started doing:

Pull the full PR diff

   git diff main..feature/my-branch > /tmp/pr.diff

Include related files
- The test file for this feature
- Any module imports
- The types/interfaces being used
Dump it all in one prompt

   Here's a PR for a new authentication system. 

   Context:
   - We're replacing JWT with session-based auth
   - The old code used Redis
   - We're keeping backward compatibility for 30 days

   [full diff here]
   [test file here]
   [schema file here]

   What am I missing? What breaks in production?

Get actual feedback
- "Your session timeout doesn't account for timezone changes in DST"
- "You're not invalidating related sessions when a user changes their password"
- "This migration path will cause issues with concurrent requests"

Real problems. Not templates.

Why Modern LLMs Finally Make This Work

A year ago, context windows were small. Now? Claude has 200K tokens. GPT-4 has 128K. You can fit:

A full microservice (10-15 files)
Complete test suite
Related API endpoints
Database schema
Architecture diagrams as text

All in one shot.

Plus, models got better at reading code. They're not just pattern-matching against StackOverflow. They understand data flow, state management, and edge cases.

Concrete Example: The Database Migration That Almost Broke

Last week I had a schema migration that dropped a column but kept using it in a view. I almost shipped it.

Instead, I threw at Claude:

Current schema
New migration
The 12 queries that use this view
The ORM mapping file
Last 6 months of git history for that table

Single prompt: "What breaks if I run this migration on production with 50K active sessions?"

Response: Three specific queries fail. Here's why. Here's how to fix it. Here's the deploy order that doesn't break anything.

I literally prevented an outage. Saved maybe 4 hours of debugging.

How to Set This Up (No Magic)

You don't need special tools. Just:

Get a decent LLM with large context
- Claude 3.5 (200K tokens) ✅
- GPT-4o (128K tokens) ✅
- Llama 2 local (8K tokens) ❌ (too small)
Build a simple script to gather context (optional but useful)

   #!/bin/bash
   # collect-context.sh
   echo "=== Changed Files ===" > /tmp/context.txt
   git diff --name-only main >> /tmp/context.txt

   echo -e "\n=== Full Diff ===" >> /tmp/context.txt
   git diff main >> /tmp/context.txt

   echo -e "\n=== Test Changes ===" >> /tmp/context.txt
   git diff main -- "*.test.ts" >> /tmp/context.txt

   wc -w /tmp/context.txt

Ask better questions
- Not: "Is this good?"
- But: "What breaks this? What's the worst case?"

The Gotchas (Real Ones)

Garbage in, garbage out. If your code is messy, the feedback is less useful. I've noticed AI catches way more issues in well-structured code.

Token costs add up. A full PR with context is 15-30K tokens. At $3 per 1M input tokens, you're spending $0.05-0.15 per review. Cheaper than a coffee. But do 50 reviews a day and it matters.

Privacy matters. If you're using cloud AI, you're sending your code to their servers. For open source? Fine. For proprietary stuff? Check your company's policy first.

Still need humans. An AI caught 6 real bugs in my last 10 reviews. But they also suggested 3 changes that looked good but would've broken product logic. You still need judgment.

What I Changed in My Workflow

Before: Copy-paste snippets, get generic advice, mostly ignore it
Now: Full context dumps, specific feedback, actually implement it

Time spent? Same. Quality? Dramatically better.

My advice: Pick one PR this week and try it. Dump the whole thing. See what happens.

If you're writing about this stuff or want to dive deeper into AI productivity workflows, check out LearnAI Weekly—they send solid real-world examples every week.

What workflows are you using AI for? Hit me up on Twitter or drop a comment below.

Running LLMs Locally: The Productivity Hack Nobody's Talking About

Learn AI Resource — Sun, 26 Jul 2026 15:00:28 +0000

Running LLMs Locally: The Productivity Hack Nobody's Talking About

Here's the thing nobody tells you: you don't actually need to call OpenAI or Claude every time you want to use an LLM. I spent six months hammering the API limits before I realized I could just... run one on my machine.

Why You Should Care

Cloud APIs charge per token. It's 10 cents here, 25 cents there. Add up a few hundred API calls a day and suddenly you're dropping $30-50/month on what could've been a local inference problem.

But that's not even the best part. Local LLMs:

Run offline (no sending code snippets to some server)
Return results in milliseconds (no network latency)
Let you use weird models that fit your exact use case
Work in your dev environment without an internet connection

I wasn't buying it either until I tried it. Switched to local Llama 2 for code completion, and my IDE response time went from "wait for the network" to instant.

The Setup (30 minutes)

Step 1: Get an LLM

Grab Ollama (ollama.ai) — it's the easiest path. It handles the model download, quantization, and serving automatically.

# Install Ollama, then run:
ollama pull mistral
ollama pull llama2

That's it. Mistral runs fine on 8GB RAM. If you've got 16GB, you can run Llama 2 70B with context.

Step 2: Start the Server

ollama serve

Now you've got a local API server on localhost:11434. Same format as OpenAI's API, except it's on your machine.

Step 3: Use It

curl http://localhost:11434/api/generate -d '{\"model\": \"mistral\", \"prompt\": \"Write a function to parse JSON\", \"stream\": false}'

Or use any client that supports OpenAI-compatible APIs. The point is, it just works.

Real Use Cases

Code completion — I run a smaller Mistral instance in the background while coding. When I'm stuck, I hit a keybind and get a suggestion instantly. No API call overhead.

Drafting documentation — Generate first drafts of README files, docstrings, API docs. Edit locally, no billing surprises.

Testing prompts — Building an AI feature? Test 50 variations of your prompt for free before paying for API calls to evaluate which one works best.

Privacy-sensitive work — Client data stays on your machine. No questions asked.

The Tradeoff

Local models are cheaper and faster, but they're not as smart as the biggest cloud models. Mistral is solid for coding and general tasks. For complex reasoning or specialized domains, you might hit the ceiling.

My system: use local models for 90% of stuff, reserve API calls for the 10% that needs reasoning power.

Getting Better Results

Two things make a huge difference:

1. Prompt engineering — Local models are pickier about prompts. Be explicit. Instead of "write a function," try "Write a Python function that takes a list of numbers and returns the median. Include type hints and a docstring."

2. System prompts — Set a good system message to guide the model's behavior. Something like "You are a helpful developer. Be concise. Provide code examples when relevant."

Next Steps

Once you've got local inference running, you can:

Integrate it into your dev environment with extensions
Build a Chatbot around it for your team
Use it in batch jobs for bulk text processing
Chain multiple models for complex workflows

The barrier to entry is stupidly low now. If you're spending money on APIs for routine tasks, you're leaving optimization on the table.

Try it this week. Spend 30 minutes getting Ollama running locally, then use it for one task you normally would've hit an API for. You'll either save money or learn why the cloud approach is worth it for your workflow.

Either way, you'll know.

Want to stay sharp on AI productivity trends? Check out LearnAI Weekly — real insights, no hype.

Stop Prompt Engineering Everything: Smarter LLM API Patterns

Learn AI Resource — Sat, 25 Jul 2026 15:00:37 +0000

Stop Prompt Engineering Everything: Smarter LLM API Patterns

So you've added an AI feature to your app. Congrats. Now you're debugging why it works great on Tuesdays but eats itself on Fridays. Here's the real talk: it's not about better prompts—it's about better patterns.

I've watched teams throw tokens at the problem for months. The fix? Structuring how they use the API, not begging the model to be smarter.

The Problem With "Better Prompting"

Everyone's obsessed with crafting the perfect prompt. Chain of thought! Few-shot examples! Temperature tweaking! And yeah, that stuff matters. But it's like optimizing your website's CSS when the database query is doing a full table scan.

The actual win is in how you structure your requests:

Streaming vs. batch
Context window management
Error handling and retry logic
Token budgeting

Pattern 1: Structured Output Instead of Parsing Text

This kills me. Teams send a prompt like "extract the name and email from this text, return it nicely formatted" and then regex their way through the response.

Use function calling or schema validation instead:

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Extract person info from: " + text}
    ],
    tools=[
        {
            "name": "extract_person",
            "description": "Extract person details",
            "input_schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "email": {"type": "string"},
                    "company": {"type": "string"}
                },
                "required": ["name", "email"]
            }
        }
    ]
)

Now you get JSON back. No parsing, no hallucinations, no "oops the model put HTML in there."

Pattern 2: Batching for Cost & Speed

Running inference one-by-one? You're leaving money on the table.

If you're processing lists (emails, documents, support tickets), group them:

# Bad: 1000 API calls
for item in items:
    result = call_api(item)

# Better: Batch messages, single call per batch
batches = [items[i:i+100] for i in range(0, len(items), 100)]
for batch in batches:
    prompt = "Process these 100 items: " + json.dumps(batch)
    result = call_api(prompt)

Fewer round trips, cheaper, faster. The model handles batch processing fine.

Pattern 3: Caching Context for Multi-Turn Interactions

If your user's doing multiple actions in a session, you're re-sending the same context every time.

Use prompt caching:

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are a code reviewer. Maintain context across messages."
        },
        {
            "type": "text",
            "text": large_codebase_or_docs,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[
        {"role": "user", "content": "Review this function..."}
    ]
)

On the first call, it caches. Every followup in that session reuses it—cheaper and faster.

Pattern 4: Streaming for UX, Not Just Tokens

Streaming isn't just for showing live responses. It's for validating early.

with client.messages.stream(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[{"role": "user", "content": user_input}]
) as stream:
    response_text = ""
    for text in stream.text_stream:
        response_text += text
        # Early exit if you detect something wrong
        if "error" in text.lower() and len(response_text) < 100:
            stream.close()
            return None

You can detect bad responses as they stream in, not after 2000 tokens.

Pattern 5: Exponential Backoff + Timeout for Real Systems

Production APIs fail. Rate limits hit. Networks hiccup.

import time
from anthropic import RateLimitError

max_retries = 3
for attempt in range(max_retries):
    try:
        response = client.messages.create(
            model="claude-3-5-sonnet-20241022",
            max_tokens=1024,
            messages=messages,
            timeout=30
        )
        return response
    except RateLimitError:
        wait_time = 2 ** attempt  # 1s, 2s, 4s
        print(f"Rate limited. Waiting {wait_time}s...")
        time.sleep(wait_time)
    except Exception as e:
        if attempt == max_retries - 1:
            raise
        time.sleep(1)

Don't just let it fail. Make it resilient.

Pattern 6: Token Budget Your Prompts

Know how many tokens you're spending per request. It sneaks up:

system_tokens = count_tokens(system_prompt)
context_tokens = count_tokens(user_context)
required_output = 500  # for the response

available = 4096 - system_tokens - context_tokens - required_output
if available < 100:
    # Truncate context or reject the request
    context = truncate_context(user_context, available)

Prevents surprises. Keeps costs predictable.

The Real Win

None of this is rocket science. It's just thinking about the API as a system, not a magic box.

Structure your outputs so you don't parse text
Batch when you can
Cache context for multi-turn flows
Stream to catch problems early
Handle failures gracefully
Know your token budget

Do this stuff and you'll spend less, go faster, and have way fewer "why did it work yesterday but not today" moments.

Stay sharp with AI development tips. Subscribe to the LearnAI Weekly newsletter for patterns like these, real dev stories, and tool roundups.

What patterns are you missing? Hit the comments.

Stop Pasting Stack Traces Into ChatGPT: A Better AI Debugging Workflow

Learn AI Resource — Fri, 24 Jul 2026 15:00:33 +0000

Stop Pasting Stack Traces Into ChatGPT: A Better AI Debugging Workflow

You know the dance. Your tests fail. You copy the error message, paste it into ChatGPT, get a generic answer that doesn't match your codebase, waste 20 minutes. Then you find the bug yourself in 2 minutes.

There's a better way to use AI for debugging—one that actually saves time instead of creating this weird dependency where you feel like you should use AI but it's not actually helping.

The Problem with Random Prompting

Most developers treat AI like a debugging vending machine: throw error in, hope for solution out. The result? Generic advice that ignores:

Your specific tech stack
How your code actually flows
The real root cause (usually 3 layers deeper than the error message)

ChatGPT isn't a mind reader. It needs context. Good context.

A Real Debugging Workflow

Here's what I actually do when something breaks:

1. Stop and Read the Error First (Yes, Really)

Spend 60 seconds looking at what the error is actually saying. Not the error message—the context. What function was running? What changed recently?

Most bugs are one of five things:

Off-by-one error
Null/undefined value you didn't expect
Type mismatch
Race condition/timing issue
Assumption that's no longer true

Guess which one before you touch AI.

2. Isolate the Failure

Reproduce it in isolation. Write a minimal test case. This isn't for AI—it's for you to understand what's actually failing.

// Bad: "why isn't my API working?"
// Good: isolated test that fails
const testCase = () => {
  const result = getUserById('123');
  console.assert(result.name === 'John', 'Expected name to be John');
};

Smaller scope = clearer thinking = faster fix.

3. Use AI as a Rubber Duck, Not a Solver

This is the key mindset shift. Instead of "fix this," ask yourself the question out loud to AI:

"I'm expecting result to be an object with a .name property. Instead I'm getting undefined. My fetch call is in a useEffect, and the data loads correctly because I can see it in DevTools. But when I access it on the first render, it's undefined. What am I missing?"

Frame it as a specific scenario, not a generic error. Paste only the relevant code (the fetch, the state, the place where it breaks).

4. Push Back on Generic Answers

If AI says "you need to add error handling," but you already have it—say so. Push back. Make it specific:

"I'm already handling the error. The fetch succeeds, data logs correctly in the console, but accessing it on the first render returns undefined. Why would the data be available in one place but not another?"

This forces you both to think deeper. Often the answer will be something you realize while typing it, which is the whole point.

5. Verify Locally Before Shipping

AI gets things right 75% of the time. That remaining 25% will ship to production and break at 3 AM. Always test the suggested fix in your actual environment first.

Real Example: The Race Condition

Here's a bug I actually hit last week:

What I saw: Form submission works on the second try, not the first.

What I asked AI: Generic error + stack trace (wasted 10 minutes).

What I should have asked:

"After a user submits a form, I call resetForm() immediately. The form resets, but if they try to submit again right away (within 500ms), the submission doesn't work. What could cause a function to be unavailable right after being called?"

The answer: I was nulling out a reference I needed. Simple once stated clearly.

Tools That Actually Help

If you want real AI assistance, use it in context:

GitHub Copilot in your IDE: Knows your codebase and gives targeted suggestions
Perplexity or Claude for detailed explanations of why something works
Your own test suite: Run it, watch it fail, use AI to explain the failure in your specific code
LearnAI Weekly newsletter: Real developers sharing actual debugging tactics and tools that work (https://learnairesource.com/newsletter)

The Real Skill

The ability to debug well—with or without AI—is about:

Being precise about what you're observing
Having hypotheses before asking for help
Understanding your own code well enough to know what's wrong
Knowing when to trust the machine and when to trust your gut

AI is best when it's helping you think clearer, not replacing the thinking.

Next Time

Next time something breaks:

Don't paste immediately
Sit with the error for 60 seconds
Ask yourself the question out loud
Then ask AI, with full context
Verify before you ship

You'll find yourself debugging faster, understanding more, and needing AI help less often. Which is probably the whole point anyway.