{"slug": "when-developers-should-not-use-ai", "title": "When Developers Should NOT Use AI", "summary": "A developer argues that AI coding assistants should sit at the end of the engineering toolchain, used only when deterministic tools like compilers, tests, debuggers, profilers, and Git cannot answer a question. The writeup recommends running commands such as git diff, git blame, and pytest, and consulting official documentation for version-specific behavior, rather than routing every step through an LLM.", "body_md": "The modern developer workflow increasingly looks like this:\n\nProblem → ask AI → copy code → ask AI why it failed → ask AI to fix it → ask AI to explain the fix.\n\nThat workflow is convenient.\n\nIt can also create a strange dependency: **the developer becomes an API client for another intelligence instead of becoming better at engineering.**\n\nThe goal shouldn't be to eliminate AI from software development.\n\nThe better goal is:\n\n**Use AI where reasoning is expensive, and use deterministic tools where computation, verification, and repetition are cheaper.**\n\nThis becomes especially important as developers move into AI engineering and inference engineering.\n\nTools such as [Git](https://git-scm.com/?utm_source=chatgpt.com), [GitHub](https://github.com/?utm_source=chatgpt.com), compilers, linters, debuggers, profilers, [Docker](https://www.docker.com/?utm_source=chatgpt.com), [Ollama](https://ollama.com/?utm_source=chatgpt.com), [vLLM](https://docs.vllm.ai/?utm_source=chatgpt.com), [Hugging Face](https://huggingface.co/?utm_source=chatgpt.com), and [Unsloth](https://unsloth.ai/?utm_source=chatgpt.com) can handle large portions of the development lifecycle without requiring an LLM for every step.\n\nThere are many situations where calling an LLM is unnecessary.\n\nIf you need to calculate:\n\n```\n1024 × 768\n```\n\nuse a calculator.\n\nIf you need to format code, use a formatter:\n\n```\nruff format\ngofmt\nprettier\n```\n\nAsking an LLM to perform deterministic work introduces another failure mode: **the model can be wrong about something that a machine can calculate exactly.**\n\nConsider:\n\n``` python\ndef add(a, b)\n    return a + b\n```\n\nYou don't need an AI model to tell you that the program has a syntax error.\n\nRun the interpreter:\n\n```\npython app.py\n```\n\nThe interpreter already knows.\n\nThe same principle applies to:\n\nA useful engineering hierarchy is:\n\n```\nCompiler\n   ↓\nTests\n   ↓\nDebugger\n   ↓\nProfiler\n   ↓\nDocumentation\n   ↓\nSearch\n   ↓\nAI\n```\n\nAI belongs toward the end of the chain when deterministic tools cannot adequately answer the question.\n\nGit is already an incredibly powerful developer reasoning system.\n\nInstead of asking:\n\n\"What changed in my project?\"\n\nrun:\n\n```\ngit diff\n```\n\nInstead of:\n\n\"What did I change yesterday?\"\n\nuse:\n\n```\ngit log\n```\n\nInstead of asking an LLM to reconstruct why a line exists:\n\n```\ngit blame file.py\n```\n\ncan identify the commit that introduced it.\n\nFor source control, start with the official [Git documentation](https://git-scm.com/doc?utm_source=chatgpt.com) and [GitHub documentation](https://docs.github.com/?utm_source=chatgpt.com).\n\nFor AI-assisted development, see the official [GitHub Copilot documentation](https://docs.github.com/en/copilot?utm_source=chatgpt.com).\n\nGitHub Copilot can assist with writing, understanding, reviewing, and changing software, but the important engineering principle remains:\n\n**Don't use an LLM when your source-control system already contains the answer.**\n\nSuppose you need to know how FastAPI handles dependency injection.\n\nThere are two approaches.\n\nAsk:\n\n\"How does FastAPI dependency injection work?\"\n\nRead the official documentation and inspect the actual API.\n\nThe second approach gives you something extremely important:\n\n**authority and version-specific behavior.**\n\nAI can generate an explanation, but documentation defines what the software actually supports.\n\nFor production engineering, the workflow should often be:\n\n```\nOfficial documentation\n        ↓\nMinimal reproduction\n        ↓\nTest\n        ↓\nAI assistance if necessary\n```\n\nnot:\n\n```\nAI\n ↓\nAI\n ↓\nAI\n ↓\nMaybe documentation\n```\n\nOne of the most underrated ways to reduce AI usage is to write good tests.\n\nImagine a developer asks an AI:\n\n\"Is my authentication implementation correct?\"\n\nThat's a weak question.\n\nInstead:\n\n```\npytest\n```\n\nmight tell you immediately.\n\nEven better:\n\n``` python\ndef test_invalid_token_is_rejected():\n    ...\n```\n\nNow the machine can repeatedly verify the behavior.\n\nThis changes the role of AI.\n\nAI decides whether the implementation works.\n\nyou get:\n\nAI proposes an implementation → tests decide whether it works.\n\nFor Python projects, [pytest's official documentation](https://docs.pytest.org/?utm_source=chatgpt.com) is the reference point.\n\nThat's a much healthier architecture.\n\nSuppose you have:\n\n```\nresult = calculate_price(order)\n```\n\nand `result` is wrong.\n\nInstead of immediately asking AI:\n\n\"Why is result wrong?\"\n\nuse a debugger.\n\nInspect:\n\n```\norder\n↓\ninputs\n↓\nfunction arguments\n↓\nintermediate variables\n↓\nreturn value\n```\n\nA debugger gives you actual program state.\n\nAn LLM gives you a hypothesis.\n\nThose are not equivalent.\n\nAI becomes more useful after you've collected evidence.\n\nFor example:\n\n\"At line 142, `discount=0.2`, but `calculate_discount()` returns 0.0. Here is the function and failing test.\"\n\nNow the AI has a constrained debugging problem rather than a guessing problem.\n\nPerformance engineering is particularly vulnerable to AI speculation.\n\nDevelopers often ask:\n\n\"Why is my Python application slow?\"\n\nAn LLM may produce 20 possible explanations.\n\nA profiler can tell you where the program actually spends its time.\n\n```\nrequest\n ├── database query       72%\n ├── JSON serialization   14%\n ├── Python computation    9%\n └── logging               5%\n```\n\nNow you don't need a philosophical discussion about Python performance.\n\nYou have evidence.\n\nThe same principle applies to AI inference.\n\nInference engineering is fundamentally about turning a model into a useful, reliable production system.\n\nImportant variables include:\n\n```\nModel\nQuantization\nKV cache\nBatch size\nContext length\nGPU memory\nThroughput\nLatency\nConcurrency\nTokens/sec\nCost/request\nTime-to-first-token\n```\n\nYou don't want an LLM guessing these numbers.\n\nYou benchmark them.\n\n```\nModel A\nbatch=1\nTTFT = 120 ms\ngeneration = 80 tok/s\n\nModel B\nbatch=1\nTTFT = 180 ms\ngeneration = 110 tok/s\n```\n\nThe benchmark is more useful than an AI-generated statement saying:\n\n\"Model B should probably be faster.\"\n\nFor production inference, use actual benchmark data.\n\n[Unsloth](https://unsloth.ai/?utm_source=chatgpt.com) is an open-source framework for local model training and inference workflows.\n\nIts documentation covers running models, fine-tuning, reinforcement learning, datasets, deployment, and other model-development workflows. See the official [Unsloth documentation](https://unsloth.ai/docs?utm_source=chatgpt.com).\n\nThat creates an important distinction.\n\n```\nDeveloper\n   ↓\nCloud AI API\n   ↓\nAnswer\nDeveloper\n   ↓\nLocal model\n   ↓\nInference engine\n   ↓\nApplication\n```\n\nThe second approach gives the developer more control over:\n\nSuppose you're building a developer tool.\n\nYou don't necessarily need to send every request to a large proprietary model.\n\nYou might use:\n\n```\nSmall local model\n        ↓\nsimple classification\n        ↓\nlocal embedding model\n        ↓\nRAG\n        ↓\nlarge model only when necessary\n```\n\nThis is an important inference-engineering pattern:\n\n**Use the smallest system that can reliably solve the task.**\n\nFor local model execution, developers can investigate tools such as:\n\nThe use case differs between them: local experimentation, optimized inference, model serving, fine-tuning, quantization, or production deployment.\n\nThink of the modern development stack as a series of increasingly expensive reasoning tools.\n\n| Problem | Prefer first | AI needed? | \n|---|---|---|\n| Syntax error | Compiler/interpreter | Usually no | \n| Formatting | Formatter | No | \n| Linting | Linter | No | \n| Type error | Type checker | Usually no | \n| Regression | Tests | No | \n| Git history | Git | No | \n| Runtime state | Debugger | Usually no | \n| Performance | Profiler | Usually no | \n| API behavior | Official docs | Usually no | \n| Unknown error | Search/docs | Sometimes | \n| Complex debugging | AI | Often useful | \n| Architecture exploration | AI + human | Useful | \n| Novel implementation | AI + engineer | Useful | \n| Large refactoring | AI agent + tests | Useful | \n| Model optimization | Benchmarks + profiling + AI | Useful | \n\nThe point isn't that AI is bad.\n\nThe point is that **AI shouldn't be the first tool for every problem.**\n\nYou don't need hundreds.\n\nA compact engineering stack can cover most repetitive work.\n\nHugging Face provides tooling for model and inference workflows, including [Inference Providers](https://huggingface.co/docs/inference-providers/?utm_source=chatgpt.com) and [Inference Endpoints](https://huggingface.co/docs/inference-endpoints/?utm_source=chatgpt.com).\n\nYou don't need every tool.\n\nYou need the right tool for the problem.\n\nEvery AI interaction has a hidden cost.\n\nNot necessarily money.\n\nThere is also:\n\nYou stop remembering how systems work.\n\nYou have to check generated code.\n\nYou need to explain your project to the model.\n\nYou wait for responses.\n\nSensitive information may leave your environment depending on the service and configuration.\n\nYour workflow becomes dependent on an external model or provider.\n\nIf AI constantly solves the problem before you understand it, your debugging ability may stagnate.\n\nTherefore:\n\n**The cheapest AI request is sometimes the request you never had to make.**\n\nModern software systems are enormous.\n\nDevelopers cannot memorize:\n\nAI can dramatically reduce search and implementation time.\n\nThe official [GitHub Copilot documentation](https://docs.github.com/en/copilot?utm_source=chatgpt.com) describes its use across software-development workflows, including coding assistance and agentic workflows.\n\nSo the objective isn't:\n\n\"Developers should use less AI.\"\n\nA better objective is:\n\n**Developers should use less unnecessary AI.**\n\nThat's a completely different idea.\n\nThis sounds contradictory.\n\nIt isn't.\n\nConsider an inference engineer who builds:\n\n```\nDeveloper\n    │\n    ├── Git\n    ├── Tests\n    ├── Profiler\n    ├── Benchmarks\n    ├── Documentation\n    ├── Local LLM\n    │      └── Unsloth\n    │\n    ├── Inference engine\n    │      └── vLLM / llama.cpp / Ollama\n    │\n    └── Cloud LLM\n           └── Used only when necessary\n```\n\nThey may actually use **more AI models** than the average developer.\n\nBut they don't ask an AI model to do everything.\n\nThey build systems where:\n\ndeterministic software handles deterministic work,\n\nand:\n\nprobabilistic models handle problems where probabilistic reasoning is valuable.\n\nThat's the real engineering advantage.\n\nA strong workflow looks like this:\n\n```\n             PROBLEM\n                │\n                ▼\n       Can a deterministic\n        tool answer it?\n          /           \\\n        YES            NO\n        │               │\n        ▼               ▼\n   Use the tool      Read docs\n                        │\n                        ▼\n                 Search existing\n                    solutions\n                        │\n                        ▼\n                 Build minimal\n                    example\n                        │\n                        ▼\n                  Test/measure\n                        │\n                        ▼\n                Still blocked?\n                    /      \\\n                  NO        YES\n                  │          │\n                  ▼          ▼\n                 Done        AI\n                              │\n                              ▼\n                       Verify output\n                              │\n                              ▼\n                         Tests/benchmarks\n```\n\nThis workflow produces a subtle but important benefit:\n\n**AI becomes a force multiplier rather than a crutch.**\n\nBefore asking AI to solve something, ask five questions:\n\nIf yes, compile it.\n\nIf yes, test it.\n\nIf yes, read it.\n\nIf yes, benchmark or profile it.\n\nIf yes:\n\n**Use AI.**\n\nAnd then verify the result.\n\nThe strongest developers of the AI era won't necessarily be the people who generate the most code with AI.\n\nThey may be the people who know **when not to generate code at all**.\n\nGit can answer questions about history.\n\nCompilers can find syntax errors.\n\nType checkers can find type problems.\n\nTests can verify behavior.\n\nDebuggers can expose program state.\n\nProfilers can identify bottlenecks.\n\nBenchmarks can measure inference performance.\n\nDocumentation can define APIs.\n\nLocal AI stacks such as [Unsloth](https://unsloth.ai/?utm_source=chatgpt.com) can let engineers run and customize models themselves.\n\nAnd when all of those tools reach their limits, AI becomes extremely valuable.\n\nThe mature workflow is therefore not:\n\n**Human → AI → code**\n\nIt is:\n\n**Human → tools → evidence → AI when useful → verification**\n\nAI doesn't have to replace the developer's tools.\n\n**AI works best when the developer already has tools that can prove whether the AI is right.**\n\nThat is how we get developers who are AI-assisted without becoming AI-dependent.", "url": "https://wpnews.pro/news/when-developers-should-not-use-ai", "canonical_source": "https://dev.to/sumit0rn/when-developers-should-not-use-ai-3e3d", "published_at": "2026-09-17 01:08:16+00:00", "updated_at": "2026-09-17 01:53:16.868895+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products"], "entities": ["Git", "GitHub", "GitHub Copilot", "Docker", "Ollama", "vLLM", "Hugging Face", "FastAPI"], "alternates": {"html": "https://wpnews.pro/news/when-developers-should-not-use-ai", "markdown": "https://wpnews.pro/news/when-developers-should-not-use-ai.md", "text": "https://wpnews.pro/news/when-developers-should-not-use-ai.txt", "jsonld": "https://wpnews.pro/news/when-developers-should-not-use-ai.jsonld"}}