Introduction
AI tools are everywhere right now, and for good reason. But manual coding — writing without AI assistants or automation — still has a real place in professional development. It’s not nostalgia. There are specific situations where writing plain code, without frameworks or AI shortcuts, produces better results than anything automated.
This article covers what manual coding actually means, where it wins over AI-assisted approaches, and one area that doesn’t get discussed enough: the security problems that come with handing your codebase over to a language model.
What is non-AI programming?
Non-AI programming means writing code without leaning on AI-generated suggestions, automation layers, or framework magic. Some people call it vanilla coding. You use the language directly, figure out the logic yourself, and own every line of the result.
This matters because there’s a difference between understanding your codebase and trusting your codebase. Manual coding forces the former.
Benefits of manual coding
You know what’s in there
AI-generated code can produce results that work without being legible. That’s fine until something breaks at 2am and you’re reading through output you didn’t write and can’t follow. When you wrote every line, there’s nothing to reverse-engineer.
Debugging is straightforward
Tracing a bug through code you wrote is just tracing a bug. You know what each part is supposed to do and why it’s structured that way. With AI-generated code, debugging often means decoding another system’s logic under pressure.
No complexity you didn’t ask for
AI tools pull patterns from their training data. Those patterns don’t always fit your situation, and sometimes they don’t fit badly enough to catch immediately. Vanilla code is only as complex as your actual problem.
Real flexibility
Predefined models and templates have edges. If a project needs something unusual, you can build it without fighting the tool’s assumptions or working around what it thinks you probably want.
Stronger fundamentals
Developers who write code by hand tend to understand what’s happening at a lower level. That pays off when you’re debugging a tricky system, estimating performance, or onboarding someone new to a codebase.
Security problems with AI coding tools
This is the part that doesn’t get enough attention. AI coding assistants are trained to produce code that looks correct. Security is harder to train for, because insecure code often works fine until it doesn’t.
Insecure patterns from training data
AI models learn from public repositories. Those repositories contain a lot of code that was written quickly, without security in mind, or before a vulnerability was discovered. The model doesn’t know that. It produces what’s statistically common, not what’s safe.
A 2021 study from NYU (published in IEEE S&P 2022) tested GitHub Copilot on security-sensitive coding scenarios and found that around 40% of the generated code contained vulnerabilities. More recent tools have improved, but the core issue hasn’t gone away: the model is optimising for plausibility, not correctness.
Hallucinated dependencies
AI tools sometimes suggest packages that don’t exist or have been abandoned. This is called dependency hallucination. Attackers use it through a technique called typosquatting: they register the hallucinated package name with malicious code and wait for developers to install it.
The risk is real. If a developer copies an npm install or pip install command from an AI suggestion without checking whether the package exists and who maintains it, they can compromise their entire build environment. Manual coding doesn’t eliminate supply chain risk, but it removes one significant source of it.
Developers over-trusting generated output
This is probably the most common problem, and the hardest to quantify. AI tools are fast. They suggest complete, formatted, syntactically correct code. The psychological pressure to accept and move on is real. But accepting code you don’t fully understand means you’re responsible for security properties you haven’t verified.
It’s not that developers are careless. It’s that the tool is designed to reduce friction, and careful security review is friction. Those two things are in tension.
Sending sensitive code to third-party services
Most AI coding tools send your code to external servers. If your codebase includes API keys, credentials, proprietary algorithms, or regulated data (health records, financial data), using a cloud-based AI assistant means that data travels outside your environment. Not all tools are equally clear about how they handle it, how long they retain it, or whether it’s used for future training.
Some organisations have addressed this with self-hosted models or air-gapped environments. Many haven’t thought about it at all.
False confidence in security-critical sections
Authentication, encryption, session management, access control — these are the areas where manual review matters most. They’re also areas where AI tools are particularly likely to produce code that looks authoritative and contains subtle flaws. A developer who knows they don’t understand cryptography is more likely to seek a review than one who got a confident-looking implementation from an AI.
One client came to us after a security audit flagged an authentication bypass in their app. The vulnerability was in code their team had accepted from an AI suggestion six months earlier. It had been in production the whole time, passing all their tests, because the tests were also AI-generated and didn’t cover that edge case. Manual review of that section would have caught it. The AI suggestion was coherent enough that nobody looked closely.
Why choose non-AI programming for your projects?
Not every project needs AI in the toolchain. Lightweight apps with minimal dependencies, performance-sensitive work, projects with strict constraints on what can be included — these often go better with vanilla code. Codebases written manually are also easier to hand off, audit, and revisit months later, because there’s nothing in them that requires explanation.
Security-sensitive projects are the strongest case. When you need to be able to verify every behaviour, AI-generated code is a liability because it introduces logic you didn’t put there and may not fully understand.
A few examples
One client needed a web app with zero third-party dependencies — a hard requirement from their security team, not a preference. Vanilla coding was the only real option. What we delivered was fast and small, and their team could audit every line themselves.
Another client was dealing with unpredictable behaviour in an AI-assisted codebase. Not broken in obvious ways, just inconsistent and hard to reason about. Moving to manual code didn’t magically fix everything, but it made the problems findable.
A startup needed features that didn’t map to any existing pattern or tool. Writing it by hand meant we could match their spec exactly, without bolting workarounds onto something that almost fit.
Conclusion
AI tools and manual coding both have uses. Knowing which fits the project is most of the job.
If you’re working on something that needs tight control, has real security requirements, or needs a codebase your team can fully own — manual coding is worth a serious look. The productivity difference is real, but so are the tradeoffs. Neither choice is always right.
Frequently asked questions
What is vanilla coding?
Vanilla coding means writing code without AI assistants, automation layers, or heavy frameworks. You use the programming language directly, work out the logic yourself, and own every line. The term “vanilla” signals plain and unaugmented — no shortcuts, no generated output.
Is AI-generated code secure?
Not reliably. AI tools are trained on public code repositories, which include a lot of insecure patterns. Research has found that AI assistants suggest vulnerable code in a significant share of security-sensitive contexts — often code that looks correct and compiles cleanly. Manual code review and security audits are still essential regardless of how the code was produced.
What are the biggest security risks of using AI coding tools?
The main risks are: insecure code suggestions drawn from vulnerable training data, hallucinated package names that attackers can exploit via typosquatting, developers over-trusting output they didn’t write, and the risk of sending sensitive code or credentials to third-party AI services. Each is manageable, but each requires a deliberate process to catch.
When should I use manual coding instead of AI tools?
Manual coding tends to be the better choice when your project has strict security requirements, zero-dependency constraints, unusual functionality that doesn’t map to common patterns, or when auditability matters — such as in regulated industries, or for code that needs to be handed off and maintained by a team that didn’t write it.
Does manual coding actually improve debugging?
Yes, in practice. When you wrote every line, tracing a bug is straightforward — you know what the code is supposed to do and why it’s structured the way it is. With AI-generated code, debugging often means reverse-engineering logic you didn’t write, which adds time and uncertainty, especially under pressure.
Can AI-generated code introduce supply chain vulnerabilities?
Yes. AI tools sometimes suggest package names that don’t exist or have been abandoned. Attackers register those names with malicious code — a technique called dependency confusion or typosquatting. If a developer installs a hallucinated dependency without checking, the result can be a supply chain compromise. Manual coding, combined with strict dependency review, reduces this risk considerably.
Is non-AI programming still relevant in 2026?
Yes. AI tools have gotten better, but they haven’t changed the underlying value of understanding what your code does. Manual coding is still the right approach for specific project types, and the skills it builds — debugging, architecture, security awareness — are still what distinguishes developers who can work on anything from ones who depend on their tooling.
Working on something that needs full control?
We’re happy to talk through whether manual coding or a hybrid approach makes sense for your project.
