DEV Community: Learn AI Resource

Stop Writing Boilerplate: How I Automated My Entire Workflow with LLM APIs

Learn AI Resource — Tue, 14 Jul 2026 15:00:51 +0000

Stop Writing Boilerplate: How I Automated My Entire Workflow with LLM APIs

You know that feeling when you're about to write the same prompt-engineering code for the third time? Yeah, that sucks. I spent way too long copy-pasting LLM API calls until I realized I could just... automate the whole thing.

Here's what I built and how you can steal my setup.

The Problem: Repetitive LLM Glue Code

Every project that uses Claude, GPT, or any LLM usually needs the same scaffolding:

Loading API keys from environment files (securely, hopefully)
Handling rate limits and retries
Streaming responses without blocking the UI
Parsing structured output from JSON-ish responses
Logging for debugging (because of course your prompts broke in production)

I was writing this by hand every single time. Different versions. Different bugs. Different mistakes.

The Solution: Build Once, Use Everywhere

I created a simple abstraction layer that handles all the boring stuff. Nothing fancy—just a utility module that wraps the API calls and gives me a clean interface.

Here's the gist:

// Load key once, reuse everywhere
const llm = new LLMClient({
  provider: 'claude',
  apiKey: process.env.ANTHROPIC_API_KEY,
  model: 'claude-3-5-sonnet-20241022',
  maxRetries: 3
});

// Simple method signature
const response = await llm.complete({
  prompt: 'Write a function that does X',
  temperature: 0.7,
  maxTokens: 1024
});

// Handles streaming, errors, and retries automatically
const stream = await llm.stream({
  prompt: 'Generate a blog post about...',
  onChunk: (chunk) => console.log(chunk)
});

No more boilerplate. No more "did I handle the 429 error correctly?" anxiety.

Real Example: Turning Unstructured Notes into Tasks

I use this constantly for converting my messy voice notes into structured todo items. Here's the actual code:

const notes = `
  Remember to fix the login bug, also need to update docs
  and someone said we should add caching somewhere maybe
`;

const tasks = await llm.complete({
  prompt: `Convert these notes into actionable tasks:\\n${notes}`,
  jsonOutput: true,
  schema: {
    tasks: [
      {
        title: 'string',
        priority: 'high|medium|low',
        estimatedTime: 'number'
      }
    ]
  }
});

// Returns properly typed JSON without manual parsing
console.log(tasks.tasks[0].title); // No errors, it just works

The jsonOutput flag tells the client to enforce structured responses, handle parsing errors, and retry if the LLM returns malformed JSON. You never see that mess.

Another Real One: Batch Processing with Proper Rate Limiting

Processing 500 customer feedback entries? Here's how you do it without getting rate limited:

const feedbackItems = await loadAllFeedback();

const processor = llm.createBatcher({
  batchSize: 10,
  delayMs: 1000, // Smart delay between batches
  parallelRequests: 3
});

const analyzed = await processor.batch(feedbackItems, async (item) => {
  return llm.complete({
    prompt: `Analyze this feedback and extract sentiment:\\n${item.text}`
  });
});

// Automatically handles retries, rate limits, failures
// Returns results in the same order as input

No more "oops, I hit the rate limit on request 247" debugging sessions.

The Developer Quality of Life Stuff

What really sold me on this approach:

Error messages that actually help:

LLMError: API rate limited. Retrying request 2/3 in 2s...
Provider response was invalid JSON. Original: {"incomplete": true...
Context length exceeded. Prompt was 8500 tokens, limit is 8192.

Automatic fallbacks:

const response = await llm.complete({
  prompt: userInput,
  fallback: 'Sorry, that was too complex. Try again?'
});

If the LLM request fails after retries, you get your fallback instead of a crashed application.

Built-in caching (optional):

const cached = await llm.complete({
  prompt: 'What is the capital of France?',
  cache: true, // Caches for 1 hour by default
  cacheKeyPrefix: 'geography'
});

Same prompt within the cache window? Instant response, no API call, no cost.

How to Get Started Right Now

Pick your LLM provider (Claude, OpenAI, whatever)
Create a utility module with a simple class that wraps their API
Add error handling, retry logic, and rate limiting
Use it everywhere instead of raw API calls

You don't need anything fancy. A solid 200-line module saves you hundreds of lines of boilerplate across all your projects.

The real win is consistency—same error handling, same logging, same rate limit behavior everywhere. When something breaks, you fix it once and it's fixed everywhere.

Quick Tip: Store Your API Keys Right

Use environment files with proper permissions:

# .env.local (never commit this)
ANTHROPIC_API_KEY=sk-ant-xxxx
OPENAI_API_KEY=sk-xxxx

Load them on startup, never pass them in code. Your future self (and security team) will appreciate it.

Want to level up your AI workflow even more? Check out LearnAI Weekly newsletter—it's got practical tips for building with modern AI tools, roundups of what's new, and solutions to problems you'll actually run into.

Stop rebuilding the same utilities. Automate the automation. Ship faster.

Stop Using 6 Chrome Tabs for Code Reviews—Do It in Your Terminal

Learn AI Resource — Mon, 13 Jul 2026 15:00:31 +0000

You know that moment when you're reviewing a PR and you need to:

Check the GitHub diff (tab 1)
Search stack overflow for the pattern (tab 2)
Open the docs (tab 3)
Look at existing similar code (tab 4)
Google the random error (tab 5)
Have slack open because someone inevitably messages you (tab 6)

Yeah. Let's fix that.

The Old Way Sucks

Browser-based code review tools are slow for one simple reason: they're not built for developers who think in terminal commands. You're constantly switching context—reaching for the mouse, squinting at small diffs, waiting for pages to load.

What if your code review tool was just... bash?

Enter Claude in the Terminal

There's a trick that changed how I review code. Instead of opening GitHub, I pipe the diff through Claude (or any LLM) and get instant feedback with actual reasoning.

Here's the real command I use:

git diff origin/main..HEAD | curl https://api.anthropic.com/v1/messages \\
  -H "x-api-key: $ANTHROPIC_API_KEY" \\
  -H "content-type: application/json" \\
  -d @- | jq '.content[0].text'

Drop that in a function, add some formatting, and you get structural feedback in seconds instead of 10 minutes of alt-tabbing.

What You Actually Get

When I used this on a recent refactor, it caught:

A query that would n+1 on user load (I missed it)
A memory leak in the cleanup function (would've been a production bug)
Three places where error handling was inconsistent
A security issue with unvalidated user input

Took Claude 3 seconds. I would've spent 15 minutes finding two of those.

Real Example: Your Actual Code

Let's say your coworker just pushed this and asked you to review:

function fetchUserData(userId) {
  return db.query(`SELECT * FROM users WHERE id = ${userId}`)
    .then(data => JSON.stringify(data))
    .catch(err => err.message)
}

Running it through the pipeline:

Critical issue: SQL injection vulnerability - userId is interpolated directly
Performance issue: Serializing with JSON.stringify adds latency
Error handling: catching errors as strings means you lose stack traces
Better approach: Use parameterized queries, let DB handle serialization

You can also ask it to explain the fix, not just flag problems. Takes 30 seconds for output that would take you 5 minutes to manually review.

The Speed Advantage

GitHub UI: Load PR → wait for page → read → switch tabs for context → 8 minutes
Terminal review: pipe diff → JSON response → 20 seconds

Not hyperbole. I timed it.

But Won't This Miss Context?

Sometimes. The LLM doesn't know your specific codebase patterns without telling it. So add context:

cat ARCHITECTURE.md | cat - <(git diff origin/main) | send_to_claude

Now it understands your patterns first. Way better reviews.

Two Ways to Do This

Option 1: Use existing tools

aider - Claude-powered pair programmer, includes review mode
git-review - wrapper scripts for automated review

Option 2: DIY (2 hours of work)

Write a bash function that pipes diffs to Claude's API
Add error handling and caching (so you don't hit rate limits)
Alias it to review and call it with review HEAD~5

I went with DIY because my team has specific standards I wanted Claude to enforce.

The Real Value

It's not that the AI is smarter than you. It's that it's consistent and fast. You're not tired after reviewing your 50th PR that day. You're not missing obvious stuff because you've been context-switching for 6 hours.

And the feedback is usually just detailed enough without being overwhelming. Better than some humans I've worked with, not gonna lie.

What's Next

The next level is semantic analysis—not just "this looks wrong" but "this contradicts the pattern you established in module-x". That's hard without buil them in, actually works.

For now, if you're drowning in PRs, try piping one through Claude. Spend 10 minutes setting it up. You'll save that back in a single review.

Want to stay sharp on AI tools and productivity tricks? Check out LearnAI Weekly—real strategies from people actually using this stuff, not hype.

Stop Letting Code Reviews Become Your Teams Bottleneck

Learn AI Resource — Sat, 11 Jul 2026 15:00:38 +0000

Stop Letting Code Reviews Become Your Team's Bottleneck

Your team's code review process is broken if it takes three days to approve a PR. You know the drill: someone writes the code, drops it in GitHub, and then it sits while reviewers are in meetings, context-switching, or just drowning in their own backlog.

Here's the move: use AI as your first reviewer.

Why Your Reviewers Are Overloaded

Code reviews are important, but they're also exhausting. Developers spend 15-20% of their time on reviews according to most surveys, and half that time is spent looking for obvious stuff:

Missing error handling
Inconsistent naming
Memory leaks or performance red flags
Security issues a linter could catch
Tests that don't actually test anything

That's busywork. Your human reviewers should be catching logic bugs, architecture issues, and "wait, what was the design decision here?" questions. Not whether someone forgot a semicolon.

The AI-First Review Pipeline

Here's what actually works in practice:

1. Pre-Review with Claude (or Your Favorite AI)

Before a PR even hits GitHub, the author runs the code through Claude or your AI of choice. This takes 2 minutes:

# Example using Claude API (or copy-paste into ChatGPT)
cat > code_review_prompt.txt << 'EOF'
You are a code reviewer. Check this code for:
- Security issues (SQL injection, exposed secrets, etc.)
- Memory leaks or performance problems
- Missing error handling
- Logic bugs

Be concise. Only flag real problems, not style nits.

---

[PASTE CODE HERE]
EOF

Real example: A junior dev wrote this function:

def fetch_user_data(user_id):
    response = requests.get(f"https://api.example.com/users/{user_id}")
    return response.json()

Claude flagged it immediately:

No timeout (could hang forever)
No error handling (what if the API is down?)
No validation (what if user_id is invalid?)
Leaks the API endpoint in code

The dev fixed all of those in 5 minutes. The PR was way better before hitting the team.

2. Automated Checks (Your Secret Weapon)

Before code reviews even happen, let your tools do the mechanical work:

Linters: eslint, pylint, golangci-lint — catch style/obvious bugs
Type checkers: TypeScript, mypy, Go — catch type mismatches
SAST tools: semgrep, SonarQube — catch security issues automatically
Test coverage: Your CI should reject low coverage PRs automatically

This stuff should block merges, not need human eyeballs.

3. Human Review (Now With Less Noise)

Your reviewers get a PR that:

Already passed automated checks
Was pre-reviewed by AI for obvious issues
Has comprehensive tests
Has a meaningful description

They can now focus on:

Does the logic actually solve the problem?
Is this the right architectural approach?
Are there edge cases we're missing?
Does this align with our team's patterns?

Actual timeline:

Before: 3-5 days for review, 2-3 rounds of comments
After: 4-6 hours, usually 1 round of comments (mostly about design, not bugs)

Tools That Actually Work

I use this combo in practice:

Claude or ChatGPT (free or $20/month) — Run code through before pushing
GitHub's built-in code scanning — Catches security issues automatically
Pre-commit hooks (githooks) — Format and lint before you even commit
CI pipeline checks — Type checking, tests, coverage must pass
Standard review checklist — Your team has 3-5 things humans check, not 50

Quick Implementation (Literally Today)

Create a .github/pull_request_template.md:

## What does this do?
[Brief description]

## Security checks
- [ ] No secrets in code
- [ ] Input is validated
- [ ] Error handling is present

## Tests
- [ ] Tests are included
- [ ] Coverage didn't decrease

Add a pre-commit hook to your repo:

#!/bin/bash
# .git/hooks/pre-commit
# Run prettier and eslint before every commit
npm run lint:fix && npm run format

Use Claude/ChatGPT for 2-minute pre-reviews on anything complex.

That's it. Three changes, huge difference.

The Real Benefit

You're not replacing code reviewers with AI. You're freeing them up to do the actual hard work — the thinking, the architecture decisions, the stuff that requires context and judgment.

Your team will spend less time on reviews and catch more bugs because humans are focusing where they're actually useful.

Next Level: Your Own Linter

If your team has specific patterns you want to enforce (naming conventions, error handling patterns, etc.), write a simple ESLint rule or Semgrep rule. Automated enforcement beats code review comments every single time.

Want to stay on top of AI tools and developer resources like this? Check out the LearnAI Weekly newsletter for curated tips, tools, and workflows every week.

Building Production Prompts That Actually Work (And Why Most Fail)

Learn AI Resource — Fri, 10 Jul 2026 15:00:52 +0000

Building Production Prompts That Actually Work (And Why Most Fail)

So you've got an LLM API key and grand plans. Then you ship it and... users get garbage. Sound familiar?

The problem isn't the model. It's that we treat prompting like writing documentation—verbose, formal, generic. But prompts are more like instructions to a coworker. Be specific. Be weird. Get the tone right.

Here's what actually works.

The Silent Killer: Vague Instructions

Bad prompt:

Summarize this text.

That could mean 3 sentences or 30. Could be bullet points or prose. The model has to guess.

Better:

Summarize this in 2-3 sentences. Use simple English. Answer: what happened and why it matters?

Even better (for production):

Summarize in exactly 2-3 sentences using words a 12-year-old knows. 
Format: [What happened] [Why it matters]
If you can't summarize it, say "unclear."

The extra details aren't padding—they're constraints that make outputs predictable. That's what production needs.

Example 1: The Debugging Assistant

Let's say you're building an IDE plugin that explains errors. Here's what bad looks like:

Explain this error:
{error_message}

Here's production:

You are a debugging assistant for junior developers. A developer got this error:

{error_message}

Respond with:
1. What went wrong (1 sentence)
2. Why it happened (2-3 sentences)
3. How to fix it (step-by-step, numbered)
4. One code example showing the fix

Keep it simple. Avoid jargon. If you're unsure, say "I'm not sure about this one."

See the difference? You're not just asking for an explanation—you're defining:

Who the audience is (junior devs)
What you want back (specific sections)
How detailed it should be (one code example, not ten)
What to do when uncertain

This turns an LLM into a reliable component, not a lucky roll.

Example 2: The Content Filter That Doesn't Suck

Naive approach:

Is this comment appropriate for a work chat?
{comment}

You'll get yes/no, but why is it inappropriate? What's the threshold?

Better:

You're a content moderator for a professional Slack workspace.

Is this message appropriate to post? Respond with JSON:
{
  "ok": true/false,
  "reason": "brief explanation if not ok",
  "confidence": 0.95
}

Guidelines:
- Profanity is sometimes fine (context matters)
- Sarcasm is okay
- Off-topic rants are not okay
- Politics/religion are not okay
- Venting about work is okay if not naming individuals

Message to review:
{comment}

Now you get structured output, consistency, and explicit rules the model follows.

Why Most Production Prompts Fail

Three reasons:

Too much context, no constraints. Dump 50 KB of docs and hope. Nope. Give examples and rules instead.
Forgotten about failure modes. What happens when the input is weird? When the model is confused? Add "If uncertain, say X." It costs nothing and saves your users.
Not tested with real data. You wrote the prompt in a happy-path demo. Try it with 1000 real requests. It breaks in ways you didn't expect. Then you add one-off fixes until it's a mess.

The Real Secret

Spend 30 minutes prompt engineering with your actual data, not toy examples.

What breaks it? Edge cases, weird formatting, ambiguous input?
What confuses it? Watch where it hallucinates or goes off-script.
What's the failure mode you actually care about? Speed? Consistency? Safety?

Fix those specific things. Then ship.

One More Thing

When you ship an LLM feature, you're not shipping a model—you're shipping a prompt. The model is a blackbox; your prompt is the API surface. Treat it like code:

Version it (prompts/v1.0.txt, prompts/v1.1.txt)
Test it (test_cases.json with expected outputs)
Document why you added each constraint
Monitor failures and iterate

What About Tools Like Claude?

If you're using Claude or another API, the principles are the same. But check the docs for platform-specific tricks:

Use <thinking> tags for reasoning-heavy tasks
Use <examples> blocks for in-context learning
Chain calls for complex workflows (don't try to do everything in one shot)
Use system prompts for static context, messages for dynamic input

Learn more advanced techniques in the LearnAI Weekly newsletter—practical guides on AI tooling, every week.

Next Steps

Pick a prompt you wrote recently
Test it with 10 weird inputs (typos, edge cases, things that don't fit the happy path)
Count how many times it breaks or outputs garbage
Add one constraint that fixes the most common failure
Test again

You'll be shocked how much better it gets.

Production-ready prompts aren't magic. They're just specific, constrained, tested. Like any good code.

Ship it.

Building Your Own AI Pair Programmer Without Breaking the Bank

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

Building Your Own AI Pair Programmer Without Breaking the Bank

I'm tired of those generic "use ChatGPT for coding" posts. So here's what actually works: using Claude's API as your personal pair programmer, keeping costs reasonable, and avoiding the BS that doesn't actually make you faster.

The Real Problem With Free Tiers

ChatGPT's free tier is slow. GitHub Copilot costs $10/month whether you use it or not. And both feel like you're borrowing someone else's brain instead of owning your own tool.

The Claude API? You pay for what you use. If you're smart about it, you're looking at $3-10/month for actual, useful help.

Here's My Actual Workflow

For architecture questions: I paste my file structure and ask Claude what's wrong. Not "fix my code" (lazy), but "where's this going to break?" It spots things I'd find in code review in 30 seconds.

For refactoring: Instead of guessing, I give it a function and say "make this more readable and explain why." The explanation matters more than the refactor — forces me to understand the change.

For documenting APIs: Claude generates docstrings from code way better than I write them. Then I edit. That's 70% faster than starting from scratch.

For debugging: Paste the error, the relevant code, and the context. Not the whole codebase — just the part that matters. Claude usually nails it.

How to Keep Costs Down

Batch your requests. Don't ask one question, wait, ask another. Save them up, send 5 at once.
Use the right model. Claude 3.5 Haiku is like 70% as good as Opus for most code work and costs a fifth. Use it first.
Trim your prompts. "Here's my file, here's the error" beats 500 lines of context. Claude's good at inference.
Cache when it makes sense. If you're refactoring a big module, use prompt caching to avoid repaying for the file each request.

Real numbers: I spend about $6/month for daily pair programming. That's one coffee.

What It Actually Speeds Up

Code review: 2 hours becomes 30 minutes.
Debugging: That weird race condition? Claude spots it while you're still thinking.
Boilerplate: Writing another CRUD endpoint? Let Claude draft it, you review and adjust.
Learning unfamiliar code: New codebase? Claude can explain the flow in plain English.

What it doesn't do: write production code without you reading it. If you're copy-pasting, you're doing it wrong and you'll regret it.

The Setup (in 5 minutes)

\`bash

1. Get an API key from claude.ai/account

2. Store it safely

export ANTHROPIC_API_KEY="your-key"

3. Use curl or your favorite HTTP client

curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "content-type: application/json" \
-d '{"model": "claude-3-5-haiku-20241022", "max_tokens": 2048, "messages": [{"role": "user", "content": "explain this code"}]}'

4. Or use the SDK in your favorite language

pip install anthropic
`\

Then write a little script to pipe code into Claude and you're done.

The Honest Part

You still have to think. Claude's not going to turn you into a developer if you're not one. But if you already know what you're doing? It's like having a really smart rubber duck that talks back and occasionally catches your mistakes before code review.

The developers I know who are actually faster with AI aren't using it to write code — they're using it to eliminate the slow thinking parts. Debugging takes time. Writing documentation takes time. Reviewing code takes time. All of those get compressed.

One More Thing

If you're leveling up on AI, check out LearnAI Weekly — it's got solid tutorials and actually useful resources instead of hype.

Try it for a week. Track your time. If you're not saving 5+ hours, you're not using it right and you should tweak your approach. If you are? Pay for the API and move on with your life instead of fiddling with tools.

Stop Doing Manual Code Reviews the Hard Way

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

You know that feeling when you're reviewing a PR and your brain turns to mush after the 50th file? Yeah. Let's fix that.

I've been using AI assistants for code review for about 6 months now, and it's genuinely changed how I work. Not in some futuristic "AI did everything" way — more like "I can actually focus on the stuff that matters."

The Real Problem With Manual Review

Code review is exhausting because you're juggling multiple contexts at once:

Understanding the business logic
Spotting actual bugs
Checking style consistency
Watching for security issues
Looking for performance traps
Maintaining team standards

Your brain can't do all of that simultaneously. You end up missing things or shipping reviews that miss obvious problems.

How I Actually Use AI For Review

I use Claude (paid version, via API) for a two-stage approach:

Stage 1: Automated scan
I dump the PR diff into Claude with a prompt like:

Review this code for:
- Logic errors or edge cases
- Performance issues
- Security vulnerabilities
- Places where error handling is weak
- Code that violates our team patterns

Focus on actual problems, not style.

Takes 30 seconds. Gets me a focused list of real concerns.

Stage 2: Strategic review
I then look at the PR myself, but I'm specifically hunting for:

Architectural decisions (does this fit the system?)
Whether the fix actually solves the root problem
Testing coverage
Documentation

The AI handles the tedious mechanical stuff. I handle the judgment calls.

Real Example

Last week, a teammate added a database migration. The code looked fine at first glance — proper column types, reasonable defaults. But Claude flagged: "No index on the new foreign key. If you're going to query by this field, add an index."

Caught something I would've missed. We added it before merge.

This happens almost every review.

Tools That Actually Work

Claude (paid) - Best at understanding context and explaining issues clearly
GitHub Copilot (paid) - Built into your workflow, integrates with PRs
ChatGPT (plus) - Works fine, slightly slower
Local Ollama - Free, but needs a decent machine

I use Claude because the context window is huge (100k tokens) and it rarely makes up problems that don't exist.

The Setup (10 minutes)

Get an API key from Anthropic, OpenAI, or wherever
Create a simple script that reads your diff and posts it to the API
Get the response back formatted nicely
Read it, make your own decisions, merge or request changes

If you use GitHub, there are already GitHub Actions that do this. I built a custom one that posts to Slack with the findings.

What Still Needs You

AI review misses:

Whether the feature actually solves the user's problem
If the architecture is future-proof
Team context ("oh, we tried this and it caused X")
Whether the person should've refactored first instead of patching

That's where your judgment lives. AI handles the mechanical stuff. You handle the wisdom.

Numbers That Matter

For me:

Average review time dropped from 25 minutes to 12 minutes per PR
Bugs caught increased (AI catches typos and edge cases I miss)
Time spent on actual judgment increased (better use of attention)

Your mileage varies. If you're reviewing straightforward code, the gains are smaller. If you're reviewing complex systems, this saves your sanity.

Quick Wins Today

Grab your last problematic PR that had bugs
Dump it into Claude/ChatGPT with "review this for bugs and issues"
See what it catches that you missed
See what it flags that's not real

That difference is your actual win.

Keep Learning

Want to go deeper on AI tools for developers? I write about this stuff weekly in the LearnAI Weekly newsletter — real workflows, real tools, no hype.

Bottom line: Use AI for the tedious parts. Use your brain for the important parts. Review PRs faster, catch more bugs, keep your sanity.

You're welcome.

Running Code Review with Local AI (No Cloud, No Waiting)

Learn AI Resource — Tue, 07 Jul 2026 15:00:49 +0000

Running Code Review with Local AI (No Cloud, No Waiting)

Your pull request sits in queue waiting for review. It's 3 AM. Your coworker's asleep. You need feedback now.

This is where most people reach for ChatGPT and hope nobody finds their proprietary code in a screenshot. But there's a better way: run AI code review locally, offline, with models that actually understand code structure.

The Problem with Cloud Code Review

Every time you paste code to ChatGPT or Claude, you're:

Uploading proprietary logic (even if you don't think you are)
Waiting for API rate limits
Building muscle memory to just... ask a chatbot instead of thinking through the problem
Getting generic feedback ("add error handling", "consider logging")

Local models don't have these issues. They're slower, sure. But they're yours.

Which Local Model to Use

Ollama is the easiest entry point. Download, run one command, done. For code review specifically:

ollama pull mistral:7b-instruct-q4

This pulls Mistral 7B (quantized), which is ~4GB. It's not bleeding-edge, but it understands code semantics well enough for real feedback.

For something heavier, Llama 2 13B is the sweet spot:

ollama pull llama2:13b-chat

Trades more VRAM for noticeably better code understanding. If you have a GPU, use it. CPU-only? Stick with 7B.

The Setup (5 Minutes)

Install Ollama from ollama.ai (Mac, Linux, Windows)
Pull a model: ollama pull mistral:7b-instruct-q4
Start the server: Just running Ollama keeps it running on localhost:11434
Create a simple script:

import requests
import json

def review_code(code_snippet, language="python"):
    prompt = f"""You are a strict code reviewer. Analyze this {language} code:

{code_snippet}

Provide:
1. Real bugs or logic errors (be specific)
2. Performance issues (not "could be faster" - real bottlenecks)
3. One thing they did well

Keep it short. No pleasantries."""

    response = requests.post(
        "http://localhost:11434/api/generate",
        json={"model": "mistral:7b-instruct-q4", "prompt": prompt},
        stream=True
    )

    full_response = ""
    for line in response.iter_lines():
        data = json.loads(line)
        full_response += data.get("response", "")

    return full_response

# Test it
with open("your_code.py") as f:
    code = f.read()
    print(review_code(code))

Save this as review.py. Run it. That's your code review bot.

Real Example: Catching the Bug I Almost Shipped

Here's a function I wrote last week:

def fetch_user_data(user_ids):
    results = []
    for uid in user_ids:
        try:
            data = api.get_user(uid)
            results.append(data)
        except APIError:
            continue  # Skip failed requests
    return results

Looks fine. Runs. Ships.

Local Mistral caught it: "You're silently dropping errors. Caller has no way to know which IDs failed. Use a dict with success/failure flags, or re-raise after collecting failures."

That's the difference between "your code works" and "your code is reliable." Cloud AI would probably say "consider error handling" and move on.

Integration Tips

With Git hooks:

#!/bin/bash
# .git/hooks/pre-commit
git diff --cached > /tmp/staged_changes.txt
python review.py < /tmp/staged_changes.txt

Won't commit if review flags something. Annoying? Yes. Educational? Absolutely.

With CI/CD:
Toss this in your pipeline as a non-blocking check. It won't fail the build, but you'll see the feedback in logs.

Real use case: Our team added this to our PR template. No enforcement—just available when someone wants a second opinion at 3 AM.

Why This Actually Works

Local models are:

Trained on code. Mistral and Llama have billions of GitHub tokens in their training data.
Surprisingly good at spotting patterns your eyes miss (unused variables, off-by-one in loops, missing bounds checks).
Terrible at architecture advice. Don't ask it to redesign your auth system. DO ask it to spot the null pointer you missed.
Confidential. Runs on your machine. Stays on your machine.

The Catch

Speed. A 7B model on CPU takes 30 seconds to review a 50-line function. GPU? 3-5 seconds. If you're reviewing 100 PRs a day, this isn't your bottleneck solver—use it for the complex ones.

Also: local models hallucinate. They'll sometimes flag something as a bug that isn't. That's why they're a second opinion, not a replacement for human review.

Quick Wins You Can Grab Today

Immediately: Install Ollama, pull Mistral, run the script above on your last five functions. See what it finds.
This week: Add it to your pre-commit hook. Let it run in the background.
This month: Measure how many real bugs it catches vs. false positives. Adjust your model if needed.

Most teams treat code review as "someone else's job." This makes it your tool. You get faster feedback, the junior dev learns more, and nothing leaves your machine.

Want to stay sharp on dev tools and productivity? Check out LearnAI Weekly—real tips from people actually using this stuff, not AI hype.

When Claude Saves Your Workflow (And When It Doesn't)

Learn AI Resource — Mon, 06 Jul 2026 15:00:36 +0000

I've watched people throw Claude at every problem, and half the time they're just wasting tokens. But when you actually understand what it's good at, it becomes genuinely useful. Here's what I've learned building production workflows with it.

The Real Strengths

Complex reasoning tasks. Claude actually thinks through multi-step problems. I built a code review system that catches architecture issues, not just linting errors. You describe the pattern you want enforced, and it reasons about trade-offs. That actually works.

Refactoring existing code. Need to migrate from one pattern to another? Give Claude the code and the target pattern. It understands context better than find-and-replace, and the output usually requires minimal cleanup. I used this to refactor a Vue 2 app to 3 in half the time I expected.

Documentation generation. Write the function. Ask Claude to write docs that explain why not just what. The narrative-style docs are actually useful for other developers, not the generated garbage you get from some tools.

Rapid prototyping. When you need to validate an idea fast, Claude can generate scaffolding that's actually structurally sound. It's not production-ready, but it gets you past the blank page problem.

Where People Waste Time

Debugging stranger problems. If your error message is weird or domain-specific, Claude will hallucinate a fix. The first suggestion sounds confident. It's usually wrong. Save yourself the frustration and search Stack Overflow instead.

Domain-specific business logic. Your system has 15 years of accumulated rules about edge cases. Claude doesn't know them. You'll spend more time correcting its assumptions than writing the code yourself. Not worth it.

Simple tasks where the solution is formula. If the answer is "use this regex" or "call this API endpoint like this," it's faster to just look it up. Claude will give you a working example, but so will the docs, and you'll learn something.

The Actual Strategy That Works

Use Claude as a thinking partner, not a code monkey:

For architecture discussions: Describe your problem. Ask it to push back on your approach. The questions it asks are often better than its suggestions.
For pattern extraction: "Here's code I wrote. What pattern am I using? Show me a cleaner way to express this." It's good at recognizing intent and generalizing.
For cross-language translation: Need to port some JavaScript to Go? Claude understands language idioms well enough to produce idiomatic code. This actually saves time.
For test generation: Write the implementation, ask it to write tests that cover edge cases. You still review them, but it accelerates the test-writing grind.
For documentation cleanup: First draft your docs in your own voice (messy, genuine). Ask Claude to organize and polish without changing tone. It improves clarity while keeping personality.

The Gotchas to Watch

Token costs add up. A 10K token request doesn't feel expensive until you're doing it 50 times a day. Track your usage. Set alerts. I learned this the hard way.

It gets worse with multiple turns. The more back-and-forth you do in one conversation, the more context it needs to track. After about 20 exchanges, the quality drops and costs skyrocket. Start fresh conversations.

Hallucinations get confident. Claude will generate code that looks syntactically perfect but calls non-existent methods or uses APIs wrong. It sounds sure of itself. Always verify. Always test.

It's not magical for your specific system. The more domain knowledge required, the less useful it is. Your system's business rules, your codebase's weird patterns, the gotchas you've discovered—Claude doesn't know any of it.

Real Numbers From My Projects

Code review automation: 3x faster reviews, 60% fewer follow-ups. Worth it.
Vue 2 to 3 migration: 40% faster than manual. Output quality was 85% there, 15% required fixes.
Test generation: 2x faster to write tests, but I still rewrote about 20% of them. Net win.
Debugging session with Claude: 4 failed suggestions before one that worked. Faster to Google in the first place.

The Bottom Line

Claude is a productivity multiplier for thinking work. It's weak at guessing. Strong at reasoning and explanation. If your task involves understanding complexity, explaining concepts, or transforming existing code—use it. If your task is "get this working" and you're not sure what's broken—don't.

Stop treating AI like a code generator. Treat it like a senior developer who's brilliant but has memory loss and can't actually run your code. That's when it becomes genuinely useful.

Want to stay current with AI tools that actually work? Check out LearnAI Weekly for curated resources on productive AI workflows, real tools, and practical patterns. No hype. Just what works.

AI Code Review: When It Actually Saves Time (And When It Doesn't)

Learn AI Resource — Sun, 05 Jul 2026 15:00:27 +0000

I've been using AI for code review for about a year now, and honestly? It's been... fine. Sometimes great, sometimes a complete waste of 10 minutes. Here's what actually works.

The honest truth

AI code review isn't a magic bullet. Claude or GPT-4 can spot some things faster than humans — sure. But they also miss context, and sometimes they just confidently recommend refactors that break your specific use case.

The real win is knowing when to use AI for review and when to just have your teammate grab some coffee and look at the PR.

Where AI actually kills it

Security patterns. Feed AI your authentication code, permission checks, SQL queries. It'll catch the weird stuff humans gloss over after the 50th PR. I caught three potential injection vectors last month using Claude on a 200-line auth module. Would I have caught those in manual review at 5 PM on Friday? Nope.

Consistency audits. "Does this match our naming conventions? Error handling? Return types?" Boring, mechanical work. AI is bored by this. It won't miss it. Set up a quick prompt, run it on PRs, done.

Explaining weird code. We all have that legacy function that makes your brain hurt. Ask AI to explain it, then explain what it should be doing. Often reveals the bug without you having to understand the mess.

Where it falls apart

Business logic. "Is this the right approach for this feature?" Nope. AI doesn't know your product roadmap, your performance constraints, or why you're doing this weird workaround. A human needs to check this.

Architecture decisions. Someone's refactoring your API structure. AI will give you generic best practices that may be terrible for your codebase. Bad idea.

When context is unclear. If the PR description is vague, AI will either miss it or confidently give wrong feedback. It amplifies the problem instead of solving it.

My actual workflow

Human first for architecture/business logic. Real review from someone who knows the project.
AI audit pass. After human approval, I run the changes through Claude with a prompt like: "Check for security issues, performance red flags, and consistency violations. Flag anything weird."
Save the time bomb. If the AI catches something the human missed, we're golden. If not, no harm — we already had human eyes.

The template I use

You're reviewing a code change. Focus on:
- Security issues (injection, auth bypasses, exposed data)
- Performance red flags (N+1 queries, memory leaks, blocking ops)
- Inconsistency with existing patterns in our codebase
- Obvious bugs the human reviewer might have missed

Be specific. For each issue, say WHERE it is and WHY it matters.
Ignore stylistic stuff we have linters for.

Takes like 30 seconds to run, catches stuff, moves on.

Real example

Had a dev update our caching layer. Human review looked fine — code was clean, logic made sense. AI flagged that the cache invalidation only worked for one user type, not three. Would've been a production incident. The dev thanked us later.

Another time, AI got excited about "optimizing" a query that was fine as-is. Ignored the flag. The human had already checked it anyway, so we were good. Not every AI suggestion is gold.

Bottom line

Use AI for the stuff that's tedious and low-context. Let humans handle judgment calls. Treat AI like your annoying coworker who's great at catching typos but has no idea what the project is actually trying to do. That's... actually a solid coworker.

If you're using AI as your only code review, you're trusting a tool that can confidently recommend terrible things. But as a safety net after human review? Different story. Way less context to worry about.

Want more practical takes on using AI without the hype? Check out LearnAI Weekly newsletter — real tips, weird tools, nothing generic.

AI Code Review Without the Theatre

Learn AI Resource — Sat, 04 Jul 2026 15:00:48 +0000

AI Code Review Without the Theatre

I've been running LLM-powered code reviews on our team for three months now, and the honest take: it's saved us from shipping bugs, but only because we stopped using it wrong.

Here's what most teams get wrong with AI code review, and how to actually make it work.

The Dumb Way (That Everyone Tries First)

You paste your PR into Claude or ChatGPT and ask "review this code." Then you get back a wall of generic advice: "Consider adding error handling. Make variable names more descriptive. Add docstrings."

Useless. Your code already has those things, or you don't care.

The problem? You're not giving the AI context. It's like showing someone your code with your hands over half of it.

What Actually Works

1. Review by Behavior, Not Style

Instead of "review this code," ask: "What could break this function with these inputs: [examples]?"

// What I used to do
"Review this payment processing function"

// What works
"I'm processing refunds. Edge cases that scare me:
- What if the user's bank rejects the refund?
- What if they request it twice in 5 seconds?
- What if the amount is \$0.01?
Here's the function: [code]
Could any of these scenarios cause problems?"

The AI will actually find the issues because you've told it what to look for.

2. Review Actual Diffs, Not Whole Files

Show it what changed, not everything:

- OLD: const price = item.price * quantity;
+ NEW: const price = Math.max(0, item.price * quantity);

Then ask: "Does this handle negative prices correctly in refunds?"

Context is everything. A 50-line diff with a specific question beats a 500-line file review.

3. Review for Your Stack, Not Generic Code

Tell it what matters to you:

"We run this on serverless (cold starts matter). 
Our p99 latency SLA is 200ms. 
We can't use external dependencies without approval.
Review this image processing function for those constraints."

Now it's actually helpful because it knows your constraints.

Real Examples From Our Practice

Example 1: Database Query

Bad: "Review this SQL query"
Good: "This query gets user comments ordered by recency. We have 50M comments and the user IDs are random. Will this be slow? What index would you add?"

AI caught that we were sorting post-filter instead of using an indexed sort. 🎯

Example 2: React Component

Bad: "Review this form component"
Good: "Users complain this form is slow to type in. Here's the component. Where could it be re-rendering unnecessarily?"

Found three unnecessary state updates. Fixed one, saved 200ms on keystroke. 🎯

Example 3: API Endpoint

Bad: "Review this endpoint"
Good: "This endpoint handles file uploads (up to 50MB). We've had issues with memory spikes. Does this code keep the whole file in memory?"

It did. We fixed it. 🎯

The One Rule That Changes Everything

Ask it to explain its reasoning for every recommendation.

"Here's why this is a problem: [explanation]. Here's how to fix it: [fix]. Here's why that fix matters: [impact]."

Lazy AI reviews will say "consider error handling" and that's it. Force it to justify. If it can't explain why something matters for your specific case, ignore it.

Tools That Make This Easier

GitHub Copilot PR review – Built into your workflow, understands context
Continue.dev – Bring Claude/Copilot into your editor, review as you write
Custom tools – We built a small script that grabs the PR diff, adds our constraints, and feeds it to Claude API. Takes 2 minutes to set up.

Don't overthink tooling. Shell script + Claude API works. CLI tool works. Paid service works. Pick one and actually use it.

What This Isn't

AI code review isn't a replacement for humans. It's a filter.

Human review is still for: architecture decisions, API design, big picture concerns.
AI review is for: silly bugs, edge cases you missed, performance gotchas, context-specific issues.

Let the machine be good at what it's good at. Let humans be good at what they're good at.

Next Steps

Start small. Pick one annoying thing your PRs have (memory leaks, SQL N+1s, missing edge cases) and ask AI specifically to hunt for that. You'll be shocked what it finds when it's looking.

Then expand. Different app, different concern.

Want more practical AI patterns for developers? Check out LearnAI Weekly newsletter – real tools and techniques (not fluff).

Happy reviewing.

Run LLMs Locally Without Losing Your Mind: A Dev Workflow Guide

Learn AI Resource — Fri, 03 Jul 2026 15:00:55 +0000

Run LLMs Locally Without Losing Your Mind: A Dev Workflow Guide

So you want to use AI in your development workflow but don't want to send every code snippet to the cloud? I get it. Privacy concerns, latency headaches, API costs adding up—all valid. Here's how I actually set this up and what actually works.

Why Local LLMs Matter Right Now

Cloud APIs are great until:

You're debugging sensitive code and don't want it in someone's training data
You're on spotty wifi and waiting 10 seconds for a response kills your flow
Your team burns through API budgets faster than expected
You need the LLM to just... stay offline

Local LLMs fix most of this. They're fast, they're free after setup, and you keep your code to yourself.

The Honest Assessment: What Works, What Doesn't

Local models that actually help:

Llama 2 (7B) - Surprisingly useful for code explanations and simple refactoring
Code Llama - Specifically trained on code. Better at completions and bug spotting than general models
Mistral 7B - Fast, decent reasoning for middleware and architecture questions
Phi 3 - Tiny but effective for quick debugging hunches

What doesn't work great:

Asking them to debug genuinely complex issues (they struggle with context beyond a few hundred lines)
Expecting them to learn your codebase unless you feed them docs explicitly
Using them for system design when you need real creativity (they tend to suggest textbook solutions)

The Setup (Real Talk)

You'll need either Ollama or LM Studio. I recommend Ollama because it's dead simple and has good integration options.

# Mac/Linux
brew install ollama
ollama run llama2

# Or grab Code Llama directly
ollama pull codellama
ollama serve  # Runs on localhost:11434

That's it. You now have a local API running on http://localhost:11434.

Integrating It Into Your Workflow

Option 1: CLI (Fastest for quick questions)

# Using curl to hit your local LLM
curl http://localhost:11434/api/generate -d '{
  "model": "codellama",
  "prompt": "Why would this break? function merge(a, b) { return {...a, ...b} }",
  "stream": false
}'

Option 2: VSCode Extension
Install "Continue" or "Codeium" (run locally) and point it to localhost:11434. You get autocomplete without leaving your editor. Game changer for repetitive patterns.

Option 3: Custom Scripts
I wrote a small Python wrapper that pipes code snippets to my local LLM and formats responses as comments. Keeps everything in my editor flow.

import requests
import sys

def ask_model(code_snippet, question):
    resp = requests.post("http://localhost:11434/api/generate", json={
        "model": "codellama",
        "prompt": f"{code_snippet}\n\nQuestion: {question}",
        "stream": False
    })
    return resp.json()["response"]

# Usage: python ask.py "your code here" "what's wrong"

Real-World Scenarios Where This Shines

Scenario 1: Code Review on Your Terms
You're reviewing a PR at 2 AM and don't want to wait for cloud latency. Run codellama locally, paste the diff, get feedback in seconds. No API calls logged anywhere.

Scenario 2: Learning Someone Else's Codebase
Feed the LLM a module's README and some key files. Ask it to explain the data flow. You get better explanations than you'd get from a generic LLM because it's working with your actual code.

Scenario 3: Rapid Prototyping
Building a small CLI tool and want to brainstorm patterns? Local models are fast enough that you can iterate quickly. No rate limits, no costs, just feedback.

Gotchas You'll Hit

Memory: Even the 7B models need 8GB+ of RAM to run smoothly. If you've got 16GB+, you're golden. If you're maxing out memory, Phi 3 (3B) is smaller but still useful.

GPU Acceleration: The first time you run a model it's slow. But if you have a GPU, Ollama will use it. This is the difference between 30 seconds and 3 seconds per response.

Context Window: These models top out around 4K-8K tokens. You can't feed them your entire codebase. Work around it by being specific: "Here's the function, here's how it's called, here's the error."

Cold Starts: If your system hasn't used the model in a while, the first request will load it into memory. Annoying but quick once it's loaded.

When to Use Cloud APIs Instead

Be honest with yourself:

If you need state-of-the-art reasoning (Claude, GPT-4), local models won't compete
If you're working on ML/data science and need sophisticated analysis, cloud LLMs are better
If your internet is solid and you trust your provider with your code, the convenience might be worth it

I use local for everyday development and cloud for the hard problems. Best of both worlds.

Quick Wins This Week

Install Ollama, run ollama pull codellama
Try one code snippet: ask it to explain something confusing in your current project
If you like it, integrate it into your editor next week
Measure your own experience—don't take my word for it

The whole setup takes 15 minutes. Even if you never use it regularly, you'll know what's possible.

Want to stay current on AI tools and developer productivity? Check out LearnAI Weekly—practical resources and tool roundups delivered every week, no fluff.

Stop Pretending to Explain Code to Ducks—Use AI Instead

Learn AI Resource — Thu, 02 Jul 2026 15:00:39 +0000

You know that feeling? You're stuck on a bug for 45 minutes. You open a new tab to ask for help, and by the time you've written out a detailed explanation of your problem, you've already spotted the issue yourself.

That's rubber duck debugging. It works because explaining forces you to think differently about the code. But let's be honest—finding an actual rubber duck every time is weird. Your teammates judge you.

Good news: AI is way better at this than waterfowl.

Why Rubber Duck Debugging Works (And Why AI Does It Better)

When you explain code aloud, your brain restructures the problem. You slow down. You notice assumptions you didn't know you were making. The duck doesn't need to respond—just existing forces clarity.

AI does the same thing but also responds. It can spot obvious mistakes you glossed over while explaining. It asks clarifying questions. It doesn't judge.

The Setup (5 Minutes)

Pick your tool:

Claude/ChatGPT: Free tier works fine. Paste your function, describe the problem.
GitHub Copilot Chat: Right in VS Code. No context switching.
Cursor: IDE built for AI pair programming. Honestly my favorite.
Local llama.cpp: If you're paranoid about sending code to the cloud (valid).

That's it. No setup.

The Process (That Actually Works)

Step 1: Paste the function

function calculateDiscount(price, userType, itemsInCart) {
  if (userType === "premium") {
    return price * 0.9;
  }
  if (itemsInCart > 5) {
    return price * 0.85;
  }
  return price;
}

Step 2: Explain the bug in casual language

"So this is supposed to give the best discount, but when someone's premium AND has more than 5 items, they only get 10% off instead of the stack. I think the problem is the if statements are checking one at a time?"

Step 3: Let it respond

Most tools will immediately see the issue: your conditions don't combine. You're not checking both conditions together, so a premium user with 5+ items gets 10% instead of 17.5%.

Step 4: Ask a follow-up

"Should I use Math.max to pick the best one, or add them?"

Now you're actually thinking through the logic with a partner instead of alone in frustration.

Real Example: The Async Gotcha

I spent 30 minutes yesterday wondering why a promise chain wasn't executing. My mental model said:

const data = await fetchUser(id);
const posts = await fetchPosts(data.id);
return { data, posts };

This should be fast enough, right? I was making one request at a time, but my brain was skipping over that detail while coding.

Pasted it to Claude, said "This feels slow", and boom—first response: "You're awaiting sequentially. Those calls are independent. Use Promise.all()."

I knew that intellectually. But I wasn't seeing it until I had to explain it to someone (or something) else.

The Patterns You'll Actually Spot

After doing this a few times, you start seeing the same bugs:

Off-by-one errors (when iterating or indexing)
Logic that should combine but doesn't (AND/OR confusion)
Async sequencing when you meant parallel
Forgetting to null-check after a filter
State mutations in React when you meant to create new objects

AI gets really good at spotting these because it's seen thousands of them.

When This Saves the Most Time

Authentication bugs: So easy to miss an edge case. Explain it to AI, it asks "What about the logout case?"
Race conditions: Describe your async flow, AI immediately sees the timing issue.
SQL queries: Paste your join. AI spots the missing WHERE clause or the cartesian product waiting to happen.
Regex patterns: Just paste it. Say what you're trying to match. AI can usually spot what's breaking.

The Bonus: It Teaches You

Unlike a real duck, AI explains why the bug happened. You learn patterns. After a few weeks of this, you start catching these bugs yourself before they even compile.

Make It a Habit

Next time you're stuck:

Don't spend 15 minutes trying to figure it out alone
Don't open a real question on Stack Overflow
Just open Copilot Chat or a new ChatGPT tab and explain it

You'll feel stupid for like 30 seconds. Then relieved for the next 30 minutes you just saved.

Want more practical dev tools and workflow tips? Sign up for LearnAI Weekly—real resources for actually building stuff, not generic hot takes.