When NOT to Use AI

The Line That Rewired My Brain

There's a concept from Andrej Karpathy — the guy who led AI at Tesla and co-founded OpenAI — that changed how I approach every build:

"With software, anything you can specify, you can automate. With AI, anything you can verify, you can automate."

Read that again. It's doing more work than it looks like.

In old-school software, if you could write out every single step — do this, then check that, then calculate this — you could automate it. That's traditional code. A rigid rulebook. Every step spelled out.

AI changed the deal. Now, if you can look at the result and tell whether it's right or wrong, you can automate the process of getting there — even if you can't describe every step. You don't need to write the rulebook anymore. You just need to be able to grade the test.

That's the shift. And it's massive. But it also has a boundary that most people blow right past — especially now that AI tools make everything feel easy.

Two Ways to Think About It

Karpathy's version is precise. But it's also written for engineers. Here are two ways to frame it that click faster.

The "Cheap Critic" Framework

Automation used to require being a master architect. You had to understand every step, every edge case, every possible failure. Now it just requires being a good critic.

Doing the work is now cheaper than judging the work.

If you can instantly spot a bad email, a buggy piece of code, or a design that feels off — you can automate the creation of those things, because you can verify the output. You don't need to know how to write the email. You just need to know when it's wrong.

This is why AI-directed development works for people who aren't traditional coders. You don't need to understand the code. You need to understand the result.

The "What" vs. "How" Framework

Traditional software = you have to understand how to do it. AI = you have to understand what you want.

Code requires process knowledge. AI requires outcome knowledge. If the goal is clear and measurable, the machine can figure out the path. If the goal is fuzzy, subjective, or changes every time — the machine is guessing, and guessing at scale is expensive.

The Decision Table

Here's where this gets practical. When you're building something — whether it's an app, a workflow, or a system — every task falls into one of three buckets.

The pattern: if the task has a deterministic answer — one right output for every input — use code. If the task involves judgment, language, or ambiguity, AI probably helps. If it involves both, use both.

Why You'd Use Code Instead of AI

This is the part nobody talks about, because the AI hype machine doesn't have an incentive to mention it.

1. Math. Always Math.

LLMs are pattern engines, not calculators. When you ask an AI to multiply 7,849 × 3,267, it's not doing arithmetic. It's predicting what digits are most likely to follow that question based on its training data. Sometimes it gets the right answer. Sometimes it confidently gives you the wrong one.

A multiply() function gets the right answer every single time. It costs nothing to run. It takes microseconds.

This extends to anything with exact, deterministic logic: date calculations, unit conversions, financial formulas, sorting, filtering, counting. If the answer is supposed to be the same every time — don't use a tool that gives you a probably.

2. Speed

An AI API call takes anywhere from 500 milliseconds to several seconds. A function call takes microseconds. If you're doing something inside a loop, inside a user interaction, or inside anything that needs to feel instant — code wins by orders of magnitude.

3. Cost

Every AI call costs money. Tokens in, tokens out. Inference costs have dropped dramatically — and they keep dropping — but "cheaper" doesn't mean free. If you're making thousands of calls a day, it adds up.

A sort function costs nothing. A regex costs nothing. A date formatter costs nothing. Every time you use AI for something code does for free, you're paying for the convenience of not writing the code. Sometimes that trade-off makes sense. Often it doesn't.

4. Reliability

Code either works or it doesn't. It doesn't hallucinate. It doesn't give you a different answer on Tuesday than it gave on Monday. It doesn't decide to restructure your database because it thought that's what you meant.

For anything that needs to be consistent, repeatable, and auditable — code is the safer choice.

Building the Hybrid: Let Each Tool Do What It's Good At

This is where the people who are actually good at this separate from the people who just throw everything at the AI and hope.

Whether you're in an IDE like Cursor or Antigravity, a chat interface, or building something with an API — the principle is the same. Instead of sending raw data to the AI and hoping it figures it out, you preprocess with code first and hand the AI a clean, structured input.

Example: Analyzing sales data.

The brute-force approach:

Here's my entire CSV with 10,000 rows of sales data.
What trends do you see?

You just burned a massive chunk of your context window on raw data. The AI will skim the middle (remember the desk metaphor?), miss patterns, and give you a generic summary.

The hybrid approach:

I ran my analysis scripts first. Here's what the code found:
- Total revenue: $2.4M (up 12% QoQ)
- Top 3 products by margin: [A, B, C]  
- Anomaly: Region 4 dropped 23% with no seasonal pattern
- Customer churn: 8.2% (above our 6% benchmark)

Given these numbers, what strategic recommendations 
would you make? Focus on the Region 4 anomaly and 
the churn rate.

Same question. Completely different result. The code did the math. The AI does the interpretation. Each tool does what it's best at.

This isn't just a trick for data analysis. It's how you build anything well. Your app needs to calculate a shipping rate? Write a function. Your app needs to generate a personalized message to the customer about that shipping rate? That's where the AI earns its keep.

The Preprocessing Principle

Code handles the "what happened." AI handles the "what does it mean."

This isn't just cleaner — it's cheaper. You're sending 200 tokens of preprocessed data instead of 50,000 tokens of raw CSV. At current rates, that's the difference between fractions of a cent and real money.

The Three Dimensions

When you're deciding between code, AI, or hybrid, you're actually balancing three things:

Cost

What does each approach cost in money, time, and compute? AI is getting cheaper per token, but code is still free for most operations. Factor in API costs, development time, and maintenance.

Quality

Which approach gives you a better result? AI is better at language. Code is better at logic. Hybrid is better at both — but takes more thought to set up.

Speed

How fast does the result need to arrive? Real-time? Batch? Once a day? If it needs to be instant, code almost always wins. If it can wait a few seconds and the task involves judgment, AI is fine.

These three dimensions pull against each other. Optimizing for cost might sacrifice quality. Optimizing for quality might sacrifice speed. The interesting decisions happen at the intersection.

Vibe Coding: Know What You're Accepting

You've probably heard the term "vibe coding" by now — Karpathy coined that one too, in 2025. It's the practice of describing what you want in plain language and letting AI generate all the code. Modern IDEs have made this the default workflow — you describe, it builds.

I'm not going to pretend I don't do it. I do. This site has plenty of AI-generated code. But there's a difference between directing AI to generate code you can verify and blindly accepting whatever the IDE spits out.

The problems people are running into in 2026:

• Security holes. AI generates code trained on public repos — including the insecure ones. Your IDE will happily write a login system with vulnerabilities baked in if you don't catch them.
• Knowledge debt. You built the thing, but you don't understand the thing. When it breaks at 2 AM (and it will), you're stuck staring at code you can't debug — and the AI that wrote it doesn't remember writing it.
• Technical debt at warp speed. AI produces code fast. Messy, poorly structured, undocumented code — also fast. You can accumulate months of technical debt in a weekend.

The fix? Same as everything else on this site: verify before you trust. Reading Code Without Knowing It covers the practical side of this — how to scan AI-generated code without being a developer. You can automate the writing of code — but only if you can verify whether the result is right or wrong.

If you can't tell whether the code the AI wrote is correct, you're not automating. You're gambling.

When AI Is the Wrong Tool

Even with modern tools that can search the web, run code, and access your files — there are still situations where AI is actively the wrong choice. Not "suboptimal." Wrong.

When the answer needs to be authoritative

If you need a current API spec, a legal requirement, a tax rate, or a library version — go to the source. Your AI tool can probably search the web for you, but there's a difference between the AI summarizing what it found and you reading the official docs yourself. For anything where "close enough" isn't good enough, read the source. Use the AI to find it, not to replace it. (This is also prime hallucination territory.)

When you need to learn, not just get the answer

AI will hand you the fish. Every time. And modern tools make it seamlessly easy — the answer appears right in your editor, formatted perfectly, ready to use.

That's exactly the problem.

If you're trying to understand how something works — how HTTP requests flow, how databases index, how CSS specificity works — having the AI explain it to you is not the same as wrestling with the docs yourself. The AI gives you an answer you'll forget by tomorrow because you never built the mental model.

There's a time for getting the answer fast. There's a time for understanding why the answer is what it is. Know which one you're in.

When the task is faster without AI

Renaming a file. Changing a color code. Adding a comment. Adjusting a margin by 4 pixels. Not everything needs a prompt. Not everything needs a context window. Sometimes the fastest path is just... doing it. Tab over, change the value, save.

When the stakes are too high for "probably"

Medical decisions. Legal advice. Security-critical code. Financial calculations that people's livelihoods depend on. AI can assist in all of these — surface patterns, flag anomalies, draft initial reviews. But it cannot be the sole decision-maker. If someone asks "is this safe?" and the best answer the system can give starts with a probability — that's not good enough.

The Actual Rule

If I had to boil this entire guide down to one line, it would be this:

Use AI for the parts you can judge. Use code for the parts you can specify. And never use either one for the parts you can't verify.

That's it. Learn to spot which bucket a task falls into, and you'll make better decisions about where to spend your time, your money, and your trust.