How GitHub, Unsloth, compilers, tests, documentation, and developer tools can reduce unnecessary AI usage
The modern developer workflow increasingly looks like this:
Problem → ask AI → copy code → ask AI why it failed → ask AI to fix it → ask AI to explain the fix.
That workflow is convenient.
It can also create a strange dependency: the developer becomes an API client for another intelligence instead of becoming better at engineering.
The goal shouldn't be to eliminate AI from software development.
The better goal is:
Use AI where reasoning is expensive, and use deterministic tools where computation, verification, and repetition are cheaper.
This becomes especially important as developers move into AI engineering and inference engineering.
Tools such as Git, GitHub, compilers, linters, debuggers, profilers, Docker, Ollama, vLLM, Hugging Face, and Unsloth can handle large portions of the development lifecycle without requiring an LLM for every step.
1. When should you NOT use AI?
There are many situations where calling an LLM is unnecessary.
1.1 When the answer is deterministic
If you need to calculate:
1024 × 768
use a calculator.
If you need to format code, use a formatter:
ruff format
gofmt
prettier
Asking an LLM to perform deterministic work introduces another failure mode: the model can be wrong about something that a machine can calculate exactly.
2. Don't ask AI to do what your compiler already does
Consider:
def add(a, b)
return a + b
You don't need an AI model to tell you that the program has a syntax error.
Run the interpreter:
python app.py
The interpreter already knows.
The same principle applies to:
- syntax errors
- type errors
- import errors
- formatting
- linting
- test failures
- dependency resolution
- build failures
- static analysis
A useful engineering hierarchy is:
Compiler
↓
Tests
↓
Debugger
↓
Profiler
↓
Documentation
↓
Search
↓
AI
AI belongs toward the end of the chain when deterministic tools cannot adequately answer the question.
3. GitHub can reduce unnecessary AI usage
Git is already an incredibly powerful developer reasoning system.
Instead of asking:
"What changed in my project?"
run:
git diff
Instead of:
"What did I change yesterday?"
use:
git log
Instead of asking an LLM to reconstruct why a line exists:
git blame file.py
can identify the commit that introduced it.
For source control, start with the official Git documentation and GitHub documentation.
For AI-assisted development, see the official GitHub Copilot documentation.
GitHub Copilot can assist with writing, understanding, reviewing, and changing software, but the important engineering principle remains:
Don't use an LLM when your source-control system already contains the answer.
4. Documentation beats AI when documentation contains the exact answer
Suppose you need to know how FastAPI handles dependency injection.
There are two approaches.
Approach A
Ask:
"How does FastAPI dependency injection work?"
Approach B
Read the official documentation and inspect the actual API.
The second approach gives you something extremely important:
authority and version-specific behavior.
AI can generate an explanation, but documentation defines what the software actually supports.
For production engineering, the workflow should often be:
Official documentation
↓
Minimal reproduction
↓
Test
↓
AI assistance if necessary
not:
AI
↓
AI
↓
AI
↓
Maybe documentation
5. Tests are an AI-reduction technology
One of the most underrated ways to reduce AI usage is to write good tests.
Imagine a developer asks an AI:
"Is my authentication implementation correct?"
That's a weak question.
Instead:
pytest
might tell you immediately.
Even better:
def test_invalid_token_is_rejected():
...
Now the machine can repeatedly verify the behavior.
This changes the role of AI.
Instead of:
AI decides whether the implementation works.
you get:
AI proposes an implementation → tests decide whether it works.
For Python projects, pytest's official documentation is the reference point.
That's a much healthier architecture.
6. Debuggers are another AI replacement
Suppose you have:
result = calculate_price(order)
and result is wrong.
Instead of immediately asking AI:
"Why is result wrong?"
use a debugger.
Inspect:
order
↓
inputs
↓
function arguments
↓
intermediate variables
↓
return value
A debugger gives you actual program state.
An LLM gives you a hypothesis.
Those are not equivalent.
AI becomes more useful after you've collected evidence.
For example:
"At line 142,
discount=0.2, butcalculate_discount()returns 0.0. Here is the function and failing test."
Now the AI has a constrained debugging problem rather than a guessing problem.
7. Profilers can replace a surprising amount of AI speculation
Performance engineering is particularly vulnerable to AI speculation.
Developers often ask:
"Why is my Python application slow?"
An LLM may produce 20 possible explanations.
A profiler can tell you where the program actually spends its time.
For example:
request
├── database query 72%
├── JSON serialization 14%
├── Python computation 9%
└── logging 5%
Now you don't need a philosophical discussion about Python performance.
You have evidence.
The same principle applies to AI inference.
8. Inference engineering makes this even more important
Inference engineering is fundamentally about turning a model into a useful, reliable production system.
Important variables include:
Model
Quantization
KV cache
Batch size
Context length
GPU memory
Throughput
Latency
Concurrency
Tokens/sec
Cost/request
Time-to-first-token
You don't want an LLM guessing these numbers.
You benchmark them.
For example:
Model A
batch=1
TTFT = 120 ms
generation = 80 tok/s
Model B
batch=1
TTFT = 180 ms
generation = 110 tok/s
The benchmark is more useful than an AI-generated statement saying:
"Model B should probably be faster."
For production inference, use actual benchmark data.
9. Unsloth changes the AI development equation
Unsloth is an open-source framework for local model training and inference workflows.
Its documentation covers running models, fine-tuning, reinforcement learning, datasets, deployment, and other model-development workflows. See the official Unsloth documentation.
That creates an important distinction.
Using AI
Developer
↓
Cloud AI API
↓
Answer
Engineering AI infrastructure
Developer
↓
Local model
↓
Inference engine
↓
Application
The second approach gives the developer more control over:
- model selection
- quantization
- inference parameters
- latency
- privacy
- deployment
- cost
- experimentation
10. Local models can reduce unnecessary API calls
Suppose you're building a developer tool.
You don't necessarily need to send every request to a large proprietary model.
You might use:
Small local model
↓
simple classification
↓
local embedding model
↓
RAG
↓
large model only when necessary
This is an important inference-engineering pattern:
Use the smallest system that can reliably solve the task.
For local model execution, developers can investigate tools such as:
The use case differs between them: local experimentation, optimized inference, model serving, fine-tuning, quantization, or production deployment.
11. The developer toolchain can be viewed as an "AI minimizer"
Think of the modern development stack as a series of increasingly expensive reasoning tools.
| Problem | Prefer first | AI needed? |
|---|---|---|
| Syntax error | Compiler/interpreter | Usually no |
| Formatting | Formatter | No |
| Linting | Linter | No |
| Type error | Type checker | Usually no |
| Regression | Tests | No |
| Git history | Git | No |
| Runtime state | Debugger | Usually no |
| Performance | Profiler | Usually no |
| API behavior | Official docs | Usually no |
| Unknown error | Search/docs | Sometimes |
| Complex debugging | AI | Often useful |
| Architecture exploration | AI + human | Useful |
| Novel implementation | AI + engineer | Useful |
| Large refactoring | AI agent + tests | Useful |
| Model optimization | Benchmarks + profiling + AI | Useful |
The point isn't that AI is bad.
The point is that AI shouldn't be the first tool for every problem.
12. How many developer tools can minimize AI usage?
You don't need hundreds.
A compact engineering stack can cover most repetitive work.
Core development
Verification
- pytest
- unit tests
- integration tests
- static analysis
- type checking
- CI/CD
Performance
- profiler
- benchmark tools
- tracing
- metrics
- logging
AI engineering
Hugging Face provides tooling for model and inference workflows, including Inference Providers and Inference Endpoints.
You don't need every tool.
You need the right tool for the problem.
13. The "AI tax"
Every AI interaction has a hidden cost.
Not necessarily money.
There is also:
Cognitive cost
You stop remembering how systems work.
Verification cost
You have to check generated code.
Context cost
You need to explain your project to the model.
Latency cost
You wait for responses.
Privacy cost
Sensitive information may leave your environment depending on the service and configuration.
Dependency cost
Your workflow becomes dependent on an external model or provider.
Skill cost
If AI constantly solves the problem before you understand it, your debugging ability may stagnate.
Therefore:
The cheapest AI request is sometimes the request you never had to make.
14. But "don't use AI" is also bad advice
Modern software systems are enormous.
Developers cannot memorize:
- every API
- every framework
- every compiler error
- every library
- every architecture pattern
- every security consideration
- every optimization technique
AI can dramatically reduce search and implementation time.
The official GitHub Copilot documentation describes its use across software-development workflows, including coding assistance and agentic workflows.
So the objective isn't:
"Developers should use less AI."
A better objective is:
Developers should use less unnecessary AI.
That's a completely different idea.
15. The future developer may use more AI while depending on it less
This sounds contradictory.
It isn't.
Consider an inference engineer who builds:
Developer
│
├── Git
├── Tests
├── Profiler
├── Benchmarks
├── Documentation
├── Local LLM
│ └── Unsloth
│
├── Inference engine
│ └── vLLM / llama.cpp / Ollama
│
└── Cloud LLM
└── Used only when necessary
They may actually use more AI models than the average developer.
But they don't ask an AI model to do everything.
They build systems where:
deterministic software handles deterministic work,
and:
probabilistic models handle problems where probabilistic reasoning is valuable.
That's the real engineering advantage.
16. A practical AI-minimal development loop
A strong workflow looks like this:
PROBLEM
│
▼
Can a deterministic
tool answer it?
/ \
YES NO
│ │
▼ ▼
Use the tool Read docs
│
▼
Search existing
solutions
│
▼
Build minimal
example
│
▼
Test/measure
│
▼
Still blocked?
/ \
NO YES
│ │
▼ ▼
Done AI
│
▼
Verify output
│
▼
Tests/benchmarks
This workflow produces a subtle but important benefit:
AI becomes a force multiplier rather than a crutch.
17. The rule I would use
Before asking AI to solve something, ask five questions:
1. Can a compiler answer this?
If yes, compile it.
2. Can a test answer this?
If yes, test it.
3. Can documentation answer this?
If yes, read it.
4. Can measurement answer this?
If yes, benchmark or profile it.
5. Is this genuinely a reasoning problem?
If yes:
Use AI.
And then verify the result.
Conclusion
The strongest developers of the AI era won't necessarily be the people who generate the most code with AI.
They may be the people who know when not to generate code at all.
Git can answer questions about history.
Compilers can find syntax errors.
Type checkers can find type problems.
Tests can verify behavior.
Debuggers can expose program state.
Profilers can identify bottlenecks.
Benchmarks can measure inference performance.
Documentation can define APIs.
Local AI stacks such as Unsloth can let engineers run and customize models themselves.
And when all of those tools reach their limits, AI becomes extremely valuable.
The mature workflow is therefore not:
Human → AI → code
It is:
Human → tools → evidence → AI when useful → verification
AI doesn't have to replace the developer's tools.
AI works best when the developer already has tools that can prove whether the AI is right.
That is how we get developers who are AI-assisted without becoming AI-dependent.
Top comments (0)