DEV Community: Learn AI Resource

Stop Drowning in Docs: Build a Smart Document Pipeline

Learn AI Resource — Thu, 04 Jun 2026 15:00:51 +0000

Stop Drowning in Docs: Build a Smart Document Pipeline

You know that feeling when you have 15 Notion pages, 8 Markdown files, a Google Doc folder you forgot about, and three Slacks full of decisions that are apparently "documented somewhere"? Yeah.

I spent last month building a simple document pipeline for my team using Claude API + some basic tooling, and it's weirdly transformed how we ship. So here's what actually works.

The Problem Nobody Wants to Say Out Loud

Documentation isn't the problem. The problem is finding it and keeping it current. By the time someone's written that beautiful architecture doc, the code's changed three times. Your design decisions live in old Slack threads. API changes get buried in PRs nobody's reading.

We were losing velocity just digging for context.

What I Actually Built

It's simpler than it sounds:

One source of truth — everything lands in a single folder (we use GitHub + Markdown, but Notion works too)
AI-powered search — Claude indexes your docs and answers questions
Auto-generated summaries — keep key docs updated without manual work
Smart linking — AI suggests connections between related docs you probably forgot existed

No fancy infrastructure. No ML training. Just smart APIs doing smart things.

How It Works In Practice

Let's say I'm onboarding a new dev. Old way: 45 minutes of me explaining stuff that's theoretically written down somewhere.

New way: They ask our doc bot "How do we handle async tasks in the queue?" Claude searches our doc folder, finds three relevant files, combines the context, and gives them a 2-minute answer that actually makes sense.

Same thing with architecture decisions. Instead of digging through GitHub issues, you ask: "Why did we choose DynamoDB over Postgres for the session store?" It finds the ADR (decision record), the relevant PRs, and the trade-offs we accepted.

The Real Implementation

Here's what I'm actually running:

import os
import json
from pathlib import Path
import anthropic

client = anthropic.Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))

def load_docs(doc_folder):
    """Load all markdown files into a dict"""
    docs = {}
    for file in Path(doc_folder).glob("**/*.md"):
        with open(file, 'r') as f:
            docs[str(file)] = f.read()
    return docs

def search_docs(query, docs):
    """Use Claude to search and synthesize docs"""
    docs_text = "\n---\n".join([
        f"FILE: {path}\n{content}" 
        for path, content in docs.items()
    ])

    message = client.messages.create(
        model="claude-3-5-sonnet-20241022",
        max_tokens=1024,
        messages=[
            {
                "role": "user",
                "content": f"""Search these docs and answer the question. 
Be specific and reference which docs you found it in.

QUESTION: {query}

DOCS:
{docs_text}"""
            }
        ]
    )

    return message.content[0].text

# Usage
docs = load_docs("./docs")
answer = search_docs("How do we handle payment webhooks?", docs)
print(answer)

Dead simple. No vector databases, no fancy embeddings (yet). Just Claude reading your actual docs and answering questions.

Why This Works When Traditional Docs Don't

Real talk: developers don't read documentation. We read answers to specific problems. This flips that. Instead of maintaining perfect docs (impossible), you maintain searchable docs. The AI does the work of connecting the dots.

Your docs can be rougher, more conversational, less polished. Because they're not meant for humans to read linearly anymore—they're a knowledge base for an AI to synthesize.

We've cut onboarding time from 2 weeks to 3 days. Not because our docs got better, but because information's actually findable now.

The Stuff That Actually Matters

What I'd do differently:

Namespace your docs (we use folders: /architecture, /api, /runbooks, /decisions)
Keep ADRs (Architecture Decision Records) small and current—these are gold for context
Don't delete old docs, just mark them deprecated—AI's better with full context
Run summaries monthly, not daily (the API costs add up)

Cost reality:
This runs us about $40/month on Claude API. That's insanely cheap compared to the time saved.

One warning:
Claude's good at synthesis, not perfect. Always verify critical information. But for "remind me how this works?" it's bulletproof.

What's Next

We're about to add:

Automated doc generation from code comments
Smart alerts when docs drift from actual behavior
A Slack bot so people can ask without context-switching

But honestly? This basic setup is already solving 80% of our documentation problem.

Try It Yourself

You need:

Your docs (even rough ones) in one place
Anthropic API key
30 minutes to adapt the script above

Throw it at your documentation mess and see what happens. I think you'll be surprised how much better information becomes when it's actually findable.

Your future self (and your next hire) will thank you.

Want more on building smart workflows with AI? Check out LearnAI Weekly for practical patterns that actually work in production.

Stop Spending $500/Month on API Calls: Build Your Own LLM Pipeline

Learn AI Resource — Wed, 03 Jun 2026 15:00:55 +0000

You know that moment when you hit your API quota on a Tuesday and your CI/CD pipeline grinds to a halt? Or when you're building a side project and every inference costs you a penny, so you end up overthinking every request?

Yeah. Let's fix that.

The Real Problem with Cloud LLMs

Don't get me wrong—cloud APIs are amazing for production workloads. But for development, testing, and internal tools? You're often paying for speed you don't need while burning through credits like they're going out of style.

Here's what changed: local LLMs are actually good now. We're talking Llama 3, Mistral, and smaller quantized models that run on a beefy laptop or a $200/month VPS. They're not as smart as Claude or GPT-4, but they're smart enough for most workflows you actually build.

What a Local Pipeline Looks Like

Here's the setup I use for the AI tools I demo to clients:

# 1. Spin up a local Ollama instance (Mac, Linux, Windows)
ollama pull mistral

# 2. Run it in the background
ollama serve

# 3. Call it from your code (same API signature as OpenAI)
curl http://localhost:11434/api/generate \
  -d '{"model": "mistral", "prompt": "explain memoization to a junior dev", "stream": false}'

That's it. No auth tokens. No rate limits. No surprise bills.

The overhead? CPU usage. If you're running this locally, expect it to chew through cores—Mistral 7B needs ~8GB RAM, and it'll be slow on CPU alone. GPU makes it snappy.

The Hybrid Approach (What Actually Works)

Here's the honest take: I don't run everything locally. Here's how I split it:

Local LLM for:

Development and debugging (free unlimited queries)
Code generation and refactoring (speed doesn't matter, cost matters)
Testing prompt templates (iterate without guilt)
Internal documentation and knowledge base chat
Processing sensitive data (stays on your network)

Cloud API for:

Production inference (reliability > cost)
Complex reasoning tasks (better models, worth the cost)
Features your users actually pay for (pass cost to them)
Time-sensitive work (local models are slower)

Example from last week: I built a code review bot for a client. The first draft ran local Mistral for 95% of reviews (quick, surface-level stuff). For tricky architectural questions, it escalates to Claude and eats the $0.01 cost. User gets 95% free reviews with occasional expert insight.

The Tools You Actually Need

Ollama — The easiest entry point. Dead simple to install, handles model management, works offline.

LM Studio — GUI alternative, great if you hate the terminal. Good for experimenting.

vLLM — If you're deploying this in prod or at scale. Faster inference, better batching.

Hugging Face Transformers — If you want to fine-tune or customize models. More control, steeper learning curve.

The Real Wins

Cost clarity — You know exactly what you're spending. No surprise bills. No deleting your app at 2 AM because you forgot a rate limit check.
Offline capability — Your tool keeps working when the internet sucks. Your CI/CD doesn't depend on OpenAI's uptime.
Privacy — Data never leaves your network. For anything dealing with proprietary code or sensitive info, this is huge.
Experimentation velocity — You can call your model a thousand times without worrying about cost. Try weird ideas. Break things. Learn.

The Honest Downsides

Slower — Local inference is orders of magnitude slower than cloud APIs. This matters for user-facing features.
Dumber — Smaller models are dumber. They're not great at complex reasoning. Know your limits.
Resource hungry — GPUs are expensive. If you don't have hardware, this doesn't help.
You own the ops — No support, no SLA. If it breaks, you fix it.

How to Get Started (Actually)

Do it locally first — Download Ollama, run ollama pull mistral, test it. Takes 30 minutes. Cost: $0.
Benchmark your use case — What accuracy do you actually need? Mistral 7B might be enough.
Calculate the trade-off — If you're spending >$100/month on API calls for non-critical stuff, a local setup pays for itself in hardware in 2-3 months.
Build incrementally — Start with a local model for one job. Monitor latency. If it's fine, add another. If it's not, keep the cloud API.

The tools are free. The barrier to entry is basically zero. The only thing stopping you is not trying it.

Resources

Want to dig deeper into how to actually do this?

Check out LearnAI Weekly newsletter for weekly breakdowns of AI tools, local vs cloud trade-offs, and how other developers are building with LLMs. New issue every Thursday.

Also worth reading:

Ollama docs (seriously, they're great)
Mistral's open-source model docs
vLLM inference optimization guide

Stop paying for midnight API calls on side projects. You've got options now. Use them.

Stop Drowning in Pull Request Reviews: How to Actually Use AI for Code Quality

Learn AI Resource — Tue, 02 Jun 2026 15:00:35 +0000

Stop Drowning in Pull Request Reviews: How to Actually Use AI for Code Quality

Look, we've all been there. You open GitHub, see 15 PRs waiting, and realize you're about to spend three hours reading other people's code. It's necessary work, but it's mind-numbing.

Here's the thing: AI tools have gotten stupidly good at spotting problems humans gloss over when they're tired. Not as a replacement for human review, but as a first pass that catches the easy wins.

The Real Problem With Manual Code Review

When you're reviewing code manually, you get fatigue. By PR #5, you're skimming. By PR #10, you're checking syntax and trusting the logic. Your brain is fried.

I spent a month tracking this. Out of ~200 code reviews, about 40% of the issues caught were:

Missing error handling
Unused imports
Inconsistent naming
Off-by-one loops
Tests that didn't actually test anything

All fixable. All boring to hunt down manually.

How I Actually Set This Up

I use Claude's API (works with other models too) in a simple GitHub Actions workflow. Doesn't require plugins or fancy setups.

The workflow:

PR opens
GitHub Action grabs the diff
Sends it to Claude
Posts a review comment with findings
I skim that comment in 30 seconds instead of spending 15 minutes reading the whole thing

The prompt I use (simplified):

Review this code diff for:
- Security issues
- Performance problems
- Missing error handling
- Tests that won't catch bugs
- Style inconsistencies

Be specific. Point to the line. Don't say "consider using" — say "line 42 will crash if foo is null."

That's it. The AI catches the technical stuff. I handle architecture, logic, and "does this actually solve the problem?"

Real Examples of Catches

Last week, Claude spotted a race condition in database connection pooling that I would've missed. Dev thought the lock was working. It... wasn't.

Another time: a foreach loop was updating a shared list during iteration. Classic Python footgun. AI flagged it immediately.

Nothing groundbreaking, but these are bugs that slip to production if you're reviewing code tired.

The Honest Limitations

AI is bad at:

Understanding your architecture decisions
Knowing why you chose library X over Y
Catching logical errors in business logic
Reading your mind about what the code should do

It's good at:

Finding typos and silly mistakes
Spotting missing edge cases
Catching patterns that usually mean bugs
Being consistent (doesn't get tired)

Tools That Actually Work

Claude API — I use this because context window is huge and it understands code. $0.003 per review if you're running through thousands of lines.

GitHub Copilot — Built in, works okay, but feels less thorough.

Self-hosted Ollama — If you want to avoid API costs. Slower, less accurate, but free.

OpenReview or similar GH Apps — Some work, some are just marketing. Test in a private repo first.

How to Start

Create a .github/workflows/ai-review.yml
Use the GitHub API to get the PR diff
Send it to Claude/OpenAI/whatever
Post the review as a comment
Set it to not block merges (you're assisting, not automating decisions)

Takes maybe 2 hours to set up. Saves 5-10 hours per month in review time.

The Real Win

This freed me up to actually think about PRs instead of hunting typos. Now I can focus on whether the solution is good, not whether there's a missing null check.

And that's when code review actually gets interesting.

Want a weekly digest of AI tools and productivity hacks like this? Check out LearnAI Weekly — no fluff, just what actually works.

Stop Drowning in AI Code Review Suggestions

Learn AI Resource — Mon, 01 Jun 2026 15:00:28 +0000

Stop Drowning in AI Code Review Suggestions

You know that feeling? You set up an AI tool to review your pull requests and suddenly you're buried under 40 comments per PR. Some are gold. Most are noise. You're spending more time triaging suggestions than actually fixing code.

Yeah, I've been there too.

The Problem With "Review Everything"

Most AI code review tools operate on autopilot: every file, every function, every variable name gets scrutinized. It's like hiring a critic who comments on your grammar, your metaphors, and whether your tabs match your spaces. Helpful? Maybe. Sane? Absolutely not.

The real issue isn't that AI feedback is bad—it's that you need your feedback, not a feedback.

What Actually Works

Here's what I've settled on after killing three different "AI code review" experiments:

1. Narrow the Scope

Don't review everything. Tell your tool to focus on:

Security issues only
Performance problems
Logic errors in core functions

Skip style nits. You have a linter for that.

If you're using Claude or ChatGPT directly, paste the diff yourself and be explicit: "Review this for security issues only. Ignore style." That single line cuts noise by 60%.

2. Use It Async, Not In Your Face

Don't integrate it into your Git hooks or CI/CD feedback loop. Run reviews manually or on a schedule. Why? Because you can't context-switch every 30 seconds.

Set a time: "Friday at 3 PM, I review all PRs with AI." Batch it. You'll spot patterns you'd miss in real-time mode anyway.

3. Train Your Tool on Your Codebase

If you're using a tool that supports it (like providing context about your project), give it your actual patterns:

Share your architecture decisions
Show examples of code you like
Tell it what you care about

Claude in particular gets way smarter when you say things like: "We use dependency injection for everything" or "We prefer type safety over flexibility." Suddenly suggestions match your actual values.

4. Make It a Second Opinion, Not a Gate

Don't block PRs on AI feedback. Use it as a sanity check after human review. Your team's standards matter more than an algorithm's preferences.

Real workflow: Human review → AI review → Merge. Not the other way around.

The Numbers

I tried this with my last project (50 PRs over 2 months):

Default AI review: 35 comments per PR, 40% actionable
Scoped to security + logic: 6 comments per PR, 85% actionable
Async batch review: 2 hours of setup, 30 minutes per week of actual work

The time savings alone were worth it. But the real win was that the reviews actually helped instead of creating busywork.

Quick Start

Using ChatGPT/Claude:

Paste diff here. Find only these issues:
- SQL injection risks
- Memory leaks
- Logic errors that would break production

Skip: variable naming, code style, comments

Using a dedicated tool (CodeRabbit, etc.):

Disable style rules
Enable security only
Set to async mode
Review 2x per week

If you're building custom:

Start with static analysis (it's better than you think)
Add AI only for semantic issues
Make it a reporter, not a blocker

The Real Talk

Your PR queue isn't going to disappear. But you can stop pretending that 40 AI suggestions are going to make your code perfect. They won't. A focused, intentional review process with humans in the loop will.

Pick one thing AI is actually better at—let's say spotting potential security issues—and use it for that. Ignore the rest.

Better code comes from knowing why you're reviewing, not from reviewing everything at once.

Want more practical engineering advice without the hype? Check out LearnAI Weekly — real tools, real examples, no fluff.

5 AI Pair Programming Patterns That Actually Speed Up Development

Learn AI Resource — Sun, 31 May 2026 15:00:32 +0000

Been watching developers fumble with AI pair programming the past couple of years? They treat it like magic autocomplete. It's not. It's a skill, and once you nail the patterns, it's a game-changer for your velocity.

Here's what actually works.

1. The Rubber Duck, AI Edition

Explain your problem to the AI. Seriously. Not as a quick question, but a full brain dump. "I'm trying to build a caching layer for my GraphQL server. The issue is that mutations invalidate the cache correctly, but on high-load days I'm seeing stale data in subscriptions. The query is hitting the database even though it should be served from cache..."

That 3-minute explanation? That's not the AI being smart. That's YOU thinking clearly. About half the time, by the time you finish explaining, you've already spotted the bug. The AI is just your sounding board.

Result: Fewer dead-end debugging sessions. Clearer problem statements mean better solutions.

2. Narrow Scope, Focused Prompts

"Make this function faster" gets you mediocre advice. "This function does three things: validates input, transforms data, then writes to a database. The bottleneck is clearly the transformation loop (I profiled it). Show me how to optimize that loop specifically without rewriting the whole thing" — that's a prompt that works.

AI is genuinely good at staring at isolated code and suggesting improvements. It's terrible at understanding your entire system from a vague description.

Pro tip: Ask for specific output format. "Show me the optimized loop with before/after timing estimates" is better than "make this faster."

3. The Async Code Review Loop

Don't ask the AI to write code, then copy-paste it without thinking. That's how you get into weird debt territory.

Instead: AI writes → you review locally → you test it → you ask follow-up questions. Treat it like a junior developer who can respond in 30 seconds.

Example flow:

AI generates a TypeScript utility for parsing logs
You run it locally with your actual log format
It blows up on edge case X
You ask: "It's failing on lines with escaped quotes. Can you handle that?"
AI fixes it
You verify again

Why it matters: You catch problems early. You understand the code. No surprises in production.

4. Pattern Extraction for Your Codebase

This one's underrated. Ask the AI to identify patterns in your code. "I'm about to write the fifth webhook handler. Are there patterns in my other handlers that I should follow? Show me the common structure."

This works even better if you feed it a few examples. Copy 2-3 of your existing handlers into the prompt: "Here are three webhook handlers from my codebase. What's the pattern I should use for the fourth one?"

Result: Consistent code structure, faster implementation, fewer code review back-and-forths.

5. The "Tell Me Why" Pattern

Generate code? Sure. But then ask: "Walk me through this line by line, why did you make those choices?"

This does two things:

You learn why this approach is better than your first instinct
You catch cases where the AI made assumptions that don't match your system

"Why did you use Promise.allSettled instead of Promise.all?" → "Because if one request fails, the others still complete, so you get partial data instead of complete failure." → "Ah, but in my case, one failure means the whole operation is invalid. Should I use Promise.all?" → "Yes."

That's you getting smarter. The AI is just a mirror.

The Real Trick

The developers I know who actually benefit from AI pair programming treat it like having a smart coworker who never gets tired and never gets offended if you ignore their suggestions. They ask good questions. They verify the answers. They understand what they're shipping.

The ones who struggle? They treat it like magic. They copy-paste. They blame the AI when something goes wrong. They never learned to ask good questions.

Your job isn't to use AI. It's to get better at thinking clearly enough to ask AI the right questions.

Curious about building your own AI-powered development tools? The LearnAI Weekly newsletter breaks down practical AI patterns for developers — no fluff, just real examples you can use this week.

Stop Pasting Your Code Into ChatGPT For Debugging—Run LLMs Locally Instead

Learn AI Resource — Sat, 30 May 2026 15:01:01 +0000

Stop Pasting Your Code Into ChatGPT For Debugging—Run LLMs Locally Instead

Here's the scenario: You've got a nasty bug, and your first instinct is to copy the suspicious function into ChatGPT. Works great. Except now you've just sent your company's code, your API keys (if you weren't careful), and potentially sensitive business logic to a third party. And you've burned another API call.

There's a better way. Run an open-source LLM locally on your machine, feed it your code directly, and get real debugging help without the privacy tax or the cost per token.

Why Local LLMs Actually Work Now

Six months ago, running a useful LLM on consumer hardware felt like a compromise. Today? Models like Llama 3.2 and Mistral are fast enough and smart enough that you won't miss ChatGPT's responses.

The magic sauce is Ollama, LM Studio, or vLLM if you're brave. Download a model (~5-40GB depending on which one), point your editor/IDE at it, and boom—you've got a local API endpoint that works exactly like OpenAI's.

Real talk: A 13B parameter model (Mistral 7B or Llama 3.2) handles code review, debugging, and refactoring better than you'd expect. A 70B model (if you've got the VRAM) basically matches GPT-4 quality for code tasks.

The Setup (15 Minutes, Seriously)

Option 1: Ollama (fastest to get working)

Download Ollama from ollama.ai
ollama pull mistral (fast, ~7GB) or ollama pull neural-chat (also solid)
ollama serve runs the local API on localhost:11434
Done.

Option 2: LM Studio (has a GUI)

Download from lmstudio.ai
Browse their model library, download one (they'll auto-convert it)
Click "Start Server"
Local API on localhost:1234

Option 3: VS Code Extension

Install "Continue" or "Codeium" (Codeium free tier has local LLM support)
Point it at your Ollama instance
Use /explain, /debug, /refactor directly in your editor

Real Example: That Loop That Won't Quit

Say you've got this mess:

for (let i = 0; i < users.length; i++) {
  if (users[i].status === 'active') {
    for (let j = 0; j < orders.length; j++) {
      if (orders[j].userId === users[i].id) {
        totalSpent += orders[j].amount;
      }
    }
  }
}

You paste it into your local LLM with "why is this slow?", and instead of a vague response about algorithmic complexity, you get:

"This is O(n²) because you're iterating all orders for every user. Use a Map to index orders by userId first, then iterate users once. [Shows code]. On 1M users and 5M orders, you'll go from 45 seconds to 200ms."

Not hypothetical. That's the actual speed difference. And you didn't leak your code to a third party.

The Trade-offs (Be Real About Them)

Pros:

Your code never leaves your machine
No API calls = no token bills (especially good if you debug a lot)
Works offline
Fast for iterative debugging (no network latency)
Models keep improving (latest ones are legit good)

Cons:

Takes up disk space (~10-40GB for useful models)
Initial download can be slow
Uses GPU VRAM (or CPU if you want it slow)
Smaller models miss edge cases that GPT-4 catches

Real decision tree:

Debugging/code review/refactoring? → Local LLM, no question
Writing complex prompts with context windows >100k tokens? → Cloud API
Playing it safe for production-critical analysis? → Use both (local for exploration, cloud for final sign-off)

The Trick That Actually Saves Time

Most developers think "local LLM = I have to learn a new tool." Nope.

If you're already using an editor with LSP support (VS Code, Neovim, JetBrains), grab Continue (open source, works with Ollama), and you're literally replacing ChatGPT with a local API. Same commands, same workflow, just faster and private.

Or if you're CLI-oriented, just curl your Ollama endpoint:

curl http://localhost:11434/api/generate -d '{
  "model": "mistral",
  "prompt": "explain this bug:\n\n[paste code here]",
  "stream": false
}'

Five seconds later, you've got your answer in the terminal.

What I Actually Use

Ollama + Mistral 7B on my MacBook Pro for quick code review (when I don't need insane accuracy)
Continue extension in VS Code pointed at Ollama for /explain and /refactor
ChatGPT when I'm stuck and need the 70B parameter artillery (rare, honestly)
Local indexing of my codebase with Ollama for "find similar patterns" queries

The 80/20 split: 80% of my "quick AI question" needs are answered by the local model. The other 20% go to the cloud.

One More Thing

Once you've got a local LLM running, you unlock a bunch of other things:

Batch code analysis across your entire codebase
Privacy-respecting code suggestions (no telemetry)
Embedded RAG (Retrieval-Augmented Generation) for custom knowledge bases

But that's a rabbit hole for another article.

Try It This Week

Seriously, allocate 30 minutes:

Download Ollama or LM Studio
Grab a model
Point your editor at it
Paste one piece of confusing code and ask "what's wrong here?"

You'll be surprised how useful it is. And you'll never paste production code into ChatGPT again.

Stay sharp. If you found this useful, check out LearnAI Weekly for more practical AI tips written by developers, for developers.

Stop Paying for Every API Call: Running LLMs Locally for Better Debugging

Learn AI Resource — Fri, 29 May 2026 15:00:28 +0000

The cloud AI endpoints are great until your debugging session burns through your API credits like a confusing npm error burns through your sanity. I've been experimenting with local LLMs for the past few months, and here's what I've actually learned works.

Why Local Matters Now

Ollama, llama.cpp, and similar tools have gotten weird good. You can actually run useful models on modest hardware. No more "wait for API response" delays. No more rate limits. Your debugging becomes interactive again.

Last week I was hunting a gnarly race condition in a Go service. I'd normally be pasting code snippets into Claude, waiting 5 seconds, tweaking the prompt, waiting again. With a local 7B model running on my M2, I could try 20 different explanations in the time it would've taken 3 API calls.

What Actually Works

Mistral 7B - Fast, good code understanding, costs basically nothing in electricity. You'll get solid suggestions for most debugging scenarios.

Llama 2 13B - Better at complex logic. Slower than 7B but worth it when you're stuck on something architectural.

Code Llama 34B - If you specifically need code generation help, this one gets it. Fair warning: needs about 24GB RAM.

The Setup (5 Minutes)

# Install Ollama (one binary, just works)
curl https://ollama.ai/install.sh | sh

# Grab a model
ollama pull mistral

# Start serving
ollama serve

Now you've got a local API at http://localhost:11434. Drop it into your editor's LLM settings or use it directly:

curl http://localhost:11434/api/generate -d '{  
  "model": "mistral",
  "prompt": "Why would this Go function panic?",
  "stream": false
}'

Real Scenario: That Bug That Wouldn't Die

I had a subtle JSON marshaling issue that only appeared in production. The API calls worked fine for quick questions, but I needed to explore edge cases fast. I spun up a local model and just... kept asking variations:

"What if the field is null instead of missing?"
"How would this behave with very long strings?"
"Does Go's JSON encoder handle this type differently?"

Got the answer (it was the null case), fixed it in 20 minutes instead of the usual "hunt through Stack Overflow for an hour" approach.

The Catch

Local models are dumber than the big brothers. You won't get the same quality on complex architectural decisions. But for debugging? For exploring code behavior? For "why is this regex not matching?" They're genuinely useful.

Also: Token limits. Mistral 7B tops out around 8k tokens. Bigger contexts = need a bigger model.

When to Use What

Use local:

Debugging and exploring
Code review quick checks
"Does this approach make sense?"
Rapid iteration while coding
When you're tired of waiting for APIs

Keep using cloud APIs:

Complex system design
Writing something from scratch
When context matters (long files, multiple dependencies)
When you need the best possible answer, not a fast one

Costs vs Speed Tradeoff

Running Mistral 7B costs me about $2/month in electricity (rough estimate). No API costs. The speed gain alone—no network round trips, instant responses—makes it worth the small local resource hit.

Your debugging workflow becomes faster, cheaper, and you're not dependent on API availability. That matters when you're in a firefighting mood at midnight.

What's Next?

The landscape is moving fast. Keep an eye on:

Ollama updates - They add new models constantly
local.ai - Another solid option if you want more control
LM Studio - GUI-based, good if you hate terminals

The point: don't assume you need cloud APIs for everything. Experiment locally. The tradeoff between raw capability and speed/cost/independence is actually worth it for most debugging work.

Try it this week. Spin up Ollama, grab a model, and see how it feels to not wait for your debugging assistant.

Want to stay sharp on AI tools that actually work? Check out LearnAI Weekly — curated resources for developers building with AI, no hype, real examples.

AI Code Reviews: Where AI Actually Wins (And Where It Fails)

Learn AI Resource — Thu, 28 May 2026 15:00:43 +0000

We've all seen the hype. "Use AI for code reviews!" "Let Claude check your PR!" But here's the thing—I've been running AI-assisted code reviews for six months, and they're useful exactly when you stop treating them like a magic solution.

Let me share what actually works.

The Pattern Stuff: Where AI Crushes It

AI is phenomenal at finding structural issues:

Missing error handling. You write a function that talks to an API, forget the 500 error case, and the AI calls it out immediately.
Inconsistent naming. If your codebase uses fetchUser() but you wrote getUser(), an LLM catches it in seconds.
Security gaps. Using eval() instead of JSON.parse()? Missing SQL injection guards? It spots these.
Performance anti-patterns. N+1 queries, unnecessary loops, blocking calls in async code—these show up fast.

The key: these are structural. They don't require understanding your business logic.

How I Use It

I run this workflow:

1. Push a branch
2. GitHub Action triggers Claude on the diff
3. Get a report on structural issues (5-10 min)
4. Humans review the logic, architecture decisions, and intent

This saves maybe 15 minutes per review that a human would spend hunting for typos and obvious bugs. That time compounds.

Where It Breaks Down

AI code reviewers will miss everything about your actual product:

Logic that's wrong by design. You wrote a function to calculate prices with a 15% discount. It's syntactically perfect. The AI approves. Turns out you needed 20% for Q2, and nobody caught it because the code was "correct."

The "why" behind decisions. You're using a slower library because it's more maintainable for your team. Or you're building in a way that'll scale to what you're launching next month. An AI doesn't know this. It might suggest "faster" alternatives that are actually worse for your context.

Cross-cutting concerns. The PR looks fine in isolation. But it conflicts with a pattern your team established last quarter. AI doesn't know your conventions unless you explicitly train it on them.

The Honest Setup

Don't treat AI as a reviewer. Treat it as a first-pass filter:

AI stage: Catch obvious bugs, style issues, security gaps, performance problems.
Human stage: Review logic, architecture, business impact, team conventions.

Post-AI, humans are reviewing the stuff that actually matters. You've cut the noise by ~60%.

Real Example

I did this on a feature last week:

What the AI flagged:

A database query missing pagination (could timeout on large datasets)
Three error cases not handled
A naming inconsistency with existing code
A missing .catch() on a promise chain

What I had to fix manually:

The business logic was backwards in one function (discount applied to wrong field)
A test case was too narrow and wouldn't catch edge cases
The approach conflicted with our plan to move that service to a different schema next sprint

If I'd shipped after the AI approval, I'd have had problems. But without the AI pass, I'd have been squinting at those three error cases for ten minutes.

Tools That Work

If you want to try this:

GitHub + Claude API: Use Actions to comment on PRs with structured feedback
Local LLMs: If you're paranoid about code leaving your network, Ollama + a 13B model works surprisingly well for structural issues
Prompting pattern: Give it your codebase style guide, then ask it to check against that specific guide. LLMs are great at following explicit rules.

Don't use:

Pre-trained review bots that don't know your codebase (too many false positives)
AI as your only reviewer (you'll miss business logic mistakes)
LLMs for reviewing changes you don't understand (defeats the purpose)

The Vibe Check

The best code reviews aren't about catching every bug. They're about shared context. An AI can help you avoid the obvious stuff so humans can focus on the interesting problems—the architectural decisions, the "will this work in six months?", the stuff that actually shapes your product.

Use AI for what it's good at. Don't pretend it replaces human judgment.

Want weekly AI insights for developers? Check out LearnAI Weekly—practical tools, no BS.

Stop Switching Between 47 AI Tools: Build Your Own Productivity Stack in 2026

Learn AI Resource — Thu, 28 May 2026 02:15:03 +0000

The Problem Nobody Talks About

You are not unproductive because you do not use enough AI tools. You are unproductive because you are constantly closing ChatGPT to open Claude to check Perplexity to ask Codeium something.

I spent two months doing this dance. By month three I had lost more time to context switching than I had gained from having better tools.

Here is what actually works: stop treating each AI tool like a separate decision.

The Stack That Works

One main writing tool — everything creative and complex goes there
One research tool — a simple script that hits multiple APIs
One coding buddy — IDE integration, local-first, fast
One dashboard — a Markdown file with curl commands and snippets

Why This Matters

Every tool switch costs you. Not just time but cognitive load. Your brain is rewinding context. You are looking at a new interface. You are remembering which tab has which auth token.

Building Yours

Your stack should have these properties:

Few enough to remember
Fast enough that you do not resent it
Integrated with how you actually work
Documented so you can evaluate new tools properly

I cut from 9 tools to 3. My output did not drop. My focus improved. My monthly bill got smaller.

If you want a weekly breakdown of what is actually working, check out LearnAI Weekly. Real tools, real workflows, not hype.

Stop Prompting Like It's 2024: A Developer's Guide to AI That Actually Works

Learn AI Resource — Tue, 26 May 2026 15:01:11 +0000

Stop Prompting Like It's 2024: A Developer's Guide to AI That Actually Works

You know that feeling when an AI gives you trash output and you blame the AI? Yeah. It's usually you.

I spent weeks watching engineers throw the same bad prompts at Claude, ChatGPT, and Gemini—getting mediocre results, then complaining the tools suck. Then I watched someone else ask the exact same question differently and get something actually useful. The difference? Structure.

The Real Problem With Your Prompts

Most developers treat AI like a search engine. You type a question, expect an answer, get disappointed. The issue is you're not giving the model context or constraints. You're just... asking.

Here's what actually works:

Instead of: "How do I optimize this React component?"
Try: "I have a React component that re-renders 50 times on form input (profiler confirms it). The component maps over 200 items. I've already memoized the list. What's the next bottleneck to check?"

See the difference? The second one gives the AI:

What the problem actually is (excessive rerenders)
How you know it's a problem (profiler data)
What you've already tried (memoization)
The scale (200 items)

The AI can now give you targeted advice instead of generic optimization tips.

Four Moves That Changed My Output Quality

1. Role-play beats hand-holding

Instead of "explain async/await," try: "You're mentoring a junior developer who knows promises but finds async/await confusing. Explain it like they're about to debug a production bug."

The AI adapts its explanation to the mental model of someone who already understands related concepts. You get better answers.

2. Show, then ask

Drop in a code snippet or example of what you're stuck on. "Here's my current approach. Why might this fail in production?" beats "how should I handle errors?"

The AI sees the exact problem, your constraints, and your skill level all at once.

3. Ask for the second answer

After you get a response, follow up with: "That works, but what's the tradeoff? When would this approach fail?"

You get depth instead of the first-pass answer. Most people stop after the first response and miss the nuance.

4. Be specific about the medium

"Write this as a React hook" is better than "write this function." "Give me a shell one-liner" is better than "how do I find large files?" The AI optimizes for what you actually need.

Why This Matters More Now

AI models got smarter in 2025-2026, but they also got better at saying they understand when they don't. A vague prompt gets a confident-sounding vague answer. A specific prompt gets a specific answer—which is either right or wrong, no middle ground.

Good prompting is how you expose when an AI is bullshitting.

The Template That Works

When you're stuck, try this structure:

Context: What are you building? What's the constraint? (Speed? Security? Readability?)
Problem: What's actually failing or unclear?
What you've tried: This prevents the AI from suggesting the same thing again
What you need: A specific output (code, explanation, comparison, tradeoff analysis)
Who you're building for: A user in China? A machine with 512MB RAM? Matters more than you think

Example: "I'm building a CLI tool in Rust for processing large CSV files (1GB+). It's too slow. I've already switched to a streaming parser. I need to know if the bottleneck is disk I/O or CPU. Give me three profiling techniques for Rust that don't require external tools."

That's a real prompt. The AI can actually help.

The Uncomfortable Truth

If you're getting boring AI outputs, you're probably giving boring inputs. Not in terms of topic—in terms of clarity and specificity. The model doesn't know you. It doesn't know your codebase. It doesn't know what you've already tried.

You have to tell it.

Spend two minutes structuring your question. You'll save twenty minutes arguing with bad output.

What I Actually Use This For

Debugging weird errors (give stack trace + what you tried)
Architecture decisions (give constraints + tradeoffs you care about)
Learning new frameworks (give your experience level + what you already know)
Code review (paste the code + what you're worried about)

What I don't use it for anymore: generic answers to generic questions. That's what documentation is for.

Next Steps

Grab a problem you're stuck on right now. Rewrite the question using the template above. Notice the difference.

And if you're building something with AI tools, we're writing a weekly breakdown of what actually works—the patterns, the failures, the weird edge cases. Come hang at LearnAI Weekly if you want to stay ahead of what the developer crowd is actually using.

The AI isn't magic. Your prompts are.

Stop Asking AI to Debug Your Code (Here's What Works Instead)

Learn AI Resource — Wed, 06 May 2026 19:41:43 +0000

So you've got a bug. Stack trace looks like alphabet soup. Your instinct: paste it into Claude/ChatGPT and wait for genius. Doesn't work. AI can't debug your code for you. It's terrible at understanding your actual problem. Here's the real move.

The Problem With "Fix My Bug"

When you dump 50 lines of context and ask "why is this broken?", the AI guesses. It can't run your code. Can't see your environment. Can't step through with actual values. So it generates plausible-sounding nonsense, you copy-paste it, and 20 minutes later you're down a rabbit hole.

What Actually Works

Narrow the scope first, yourself
Don't paste the whole function. Find the smallest piece that reproduces the issue. Two functions, maybe three. Test it in isolation. You'll catch 40% of bugs just doing this.
Tell AI what you've already tried
"I added console.log at line 15 and the value is undefined. Expected a string from the API response." Now you're not asking AI to guess—you're asking it to explain your observation.
Ask for the mechanism, not the fix
Instead of "fix this," ask "why would arr.length be undefined here?" Force the AI to explain what should happen, then you verify against what's actually happening.
Use it for rubber-ducking, not magic
Explain your code to AI like you're teaching a friend. Half the time you'll find the bug while explaining. That's the real value.

Real Example

Bad: "Why doesn't my API call work? [pastes entire controller]"

Good: "My fetch returns status 200 but .json() throws. I know the response body exists (logged it). Why would parsing succeed in Postman but fail in my app?"

That's specific. That's actionable. AI can actually help.

The Workflow

Understand the symptom
Isolate the smallest reproducer
State what you know to be true
Ask what should happen instead
Compare reality to expectation
Fix it yourself (you'll learn more)

Yeah, it takes longer than pasting into AI. You'll also actually fix the bug and remember how next time.

Want to level up your dev skills faster? Check out LearnAI Weekly newsletter — practical AI tools, automation tips, and coding resources delivered every week.

The AI Coding Workflow That Finally Clicked

Learn AI Resource — Tue, 05 May 2026 15:01:29 +0000

The AI Coding Workflow That Finally Clicked

I tried using AI for coding for six months. Mostly failed.

Not because the tools were bad. Because I was using them wrong.

I'd ask ChatGPT to "write me a function" and get code that looked right but broke in weird ways. I'd paste errors into Claude and get explanations that didn't actually fix anything. I'd generate entire components that I had to rewrite anyway.

Then I changed one thing about how I used AI, and suddenly it actually worked.

The shift: Stop asking AI to write code. Start using it to think through problems.

What I Was Doing Wrong

Before: "Write me a React component that fetches user data and displays it in a table with sorting."

What I got: 200 lines of code that:

Used old syntax
Had no error handling
Didn't match my existing patterns
Broke when I tried to integrate it

What I did next: Spent 30 minutes fixing it. Could've written it from scratch in 20.

That's not productivity. That's just extra steps.

The Workflow That Actually Works

I stopped treating AI like a code generator. Started treating it like a senior developer I could rubber duck with.

Step 1: Explain the Problem First

Instead of asking for code, I explain what I'm building.

Bad prompt:

Write a function to validate email addresses

Good prompt:

I'm building a signup form. Need to validate emails before sending to API.
Requirements:
- Block obviously fake emails (test@test.com)
- Allow + in email addresses
- Should feel fast (no external API calls)
- Needs to work with our existing form validation library (Yup)

What should I consider before implementing this?

What AI gives me:

Edge cases I forgot (internationalized domains, subaddresses)
Tradeoffs (regex vs library)
Security considerations
Actual recommendations

Now when I write the code myself, I avoid 5 bugs I would've hit later.

Time saved: 2 hours of debugging next week.

Step 2: Use AI for Architecture, Not Implementation

Ask "how should I structure this?" before asking "write this for me."

Example: Building a file upload feature with progress tracking.

My question:

I need to add file uploads to our app. Users upload large files (100MB+), 
need progress bars, should handle failures gracefully, and allow resume.

What's the best architecture for this? What are the gotchas?

What AI tells me:

Use chunked uploads (didn't know that was a thing)
Need backend presigned URLs (security)
Client-side: track chunks, handle retries per chunk
Consider libraries (Uppy, Resumable.js)
Suggests specific AWS S3 multipart upload pattern

What I do: Read the recommendations. Pick Uppy. Read their docs. Implement with their patterns. Done in 2 hours instead of spending a day figuring out chunked uploads from scratch.

AI didn't write the code. It showed me the path. I walked it.

Step 3: Debug by Asking "Why" Not "Fix"

When something breaks, don't paste the error and beg for a solution.

Bad:

Getting error: "Cannot read property 'map' of undefined"
Fix this code: [paste 100 lines]

Good:

Getting "Cannot read property 'map' of undefined" on this line:
  data.users.map(user => ...)

The API returns: { success: true, data: { users: [...] } }
My code expects: data.users

Why is 'users' undefined? What am I missing about the response structure?

What AI does:

Points out I'm accessing data.users but should access data.data.users
Explains the nested structure
Suggests adding console.log to verify
Recommends optional chaining: data?.data?.users?.map()

What I learn: The actual mental model of the problem. Next time I see similar issues, I fix them myself in 10 seconds.

Step 4: Use AI for Code Review

After writing code, I paste it and ask for review.

My prompt:

Review this function for bugs, edge cases, and improvements:

[paste code]

Context: This runs in a Next.js API route and handles user authentication.

What AI catches:

Missing error handling
Race condition with async operations
Suggests using try/catch
Points out I'm not validating input
Recommends rate limiting (didn't even think about it)

Time saved: Catching bugs before they hit production.

Step 5: Learn Patterns, Not Solutions

When AI shows me something new, I don't just copy it. I ask why.

Example: AI suggested using AbortController for fetch requests.

My follow-up:

Why use AbortController here? What problem does it solve?
When should I NOT use it?

What I learned:

Cancels in-flight requests when component unmounts
Prevents memory leaks in React
Avoids updating state on unmounted components
Not needed for server-side requests

Now I recognize when to use it. That pattern becomes part of my toolkit.

What Changed

Before: Ask AI to write code → get messy code → spend time fixing → slower than doing it myself

After: Ask AI to explain concepts → understand the problem better → write cleaner code → catch issues early → actually faster

The difference is subtle but huge.

Real Example: API Integration

I needed to integrate with a payment API (Stripe).

Old approach:

"Write Stripe checkout integration"
Get 400 lines of example code
Copy-paste
Doesn't work because it's generic
Spend 2 hours debugging

New approach:

Me: "I'm integrating Stripe checkout. Need to handle subscriptions, multiple price tiers, and trial periods. What's the recommended architecture?"

AI: Explains webhook pattern, suggests using Stripe checkout sessions, recommends storing customer IDs in DB, warns about webhook replay attacks.

Me: Reads Stripe docs based on recommendations. Implements step by step. Asks AI specific questions when stuck ("Why does Stripe recommend using webhook secrets?").

Result: Working integration in 3 hours with proper security. Understand how it works. Can debug it myself.

The Pattern

Explain context → get better advice
Ask for architecture → understand structure
Write code yourself → maintain quality
Use AI for review → catch bugs early
Ask "why" → learn patterns

AI is not a code generator. It's a thinking partner.

Stop trying to skip the learning. Use AI to learn faster.

Tools I Actually Use

For quick questions: ChatGPT (GPT-4) or Claude

For code context: GitHub Copilot (accepts/rejects suggestions, doesn't generate from scratch)

For exploration: Perplexity (search + AI combined)

For review: Paste into Claude with full context

What I don't use: AI to write entire features. That never works.

Try This Tomorrow

Next time you're about to ask AI to "write me a function," stop.

Instead, ask:

"What should I consider when building this?"
"What's the standard pattern for this problem?"
"What are common mistakes people make here?"

Then write the code yourself.

Use AI's knowledge. Keep your craftsmanship.

That's the workflow that finally clicked.

Want More Like This?

I write about real AI workflows, productivity techniques, and developer tools that actually work.

Subscribe to LearnAI Weekly — practical tips delivered every week. No fluff, just stuff you can use immediately.

What's your AI coding workflow? Still generating full functions or have you found something better? Drop a comment.