LLMs for Coding: A Practical Case for Saying No

Why might a developer choose not to use LLMs for coding?

Plenty of developers understand machine learning, recognize what's going on behind transformer models, and still choose not to use a hosted coding assistant at work. Technical curiosity and workplace adoption are separate questions. A tool can be impressive and still be the wrong fit - for the task, the team, or the way someone thinks.

A lot of the strongest opt-out reasons are practical, not ideological. An assistant can break your concentration, make it harder to build a real mental model of the system, or add code that takes longer to verify than it took to generate. Another person might simply not want to send proprietary source code or customer data to a third-party service without a clear, approved plan for how that data will be handled.

There's also the question of what the work is actually for. Programming isn't just typing syntax. It's deciding where boundaries are, how data should be structured, how failures should behave, and what it will cost to change later. Writing and reading code are part of how many developers work through those decisions. If a tool removes that thinking without replacing it with understanding, the "productivity gain" can be misleading.

That doesn't mean every use of an LLM weakens skill. The research on cognitive effects is still evolving, and people's experiences vary. Some developers report feeling mentally scattered after extended use. Others say a well-scoped assistant reduces routine friction. Studies like Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task and Microsoft's survey on self-reported cognitive effort raise real questions, but they shouldn't be treated as proof that every coding assistant causes lasting harm.

So an opt-out is best thought of as a boundary - personal or organizational - not a universal verdict. You don't have to prove a tool is harmful to decide it doesn't earn its place. The real test is whether it helps you deliver software that's understandable and reliable, within the constraints you actually live with.

Does AI-generated code create quality and maintenance problems?

AI-generated code can look more complete than it is. You might get detailed comments, a bunch of tests, and a polished explanation - while still picking the wrong abstraction or missing the simplest fix. That "looks done" feeling isn't the same thing as correctness. A plausible patch still deserves the same level of scrutiny as a teammate's change - often more, because you can't easily tell what assumptions shaped it.

One common failure mode is solving the request you asked for instead of understanding the system you're changing. A small schema tweak or migration might handle the real need. With a narrow prompt, an LLM can instead introduce a new service, add framework hooks, create layers of indirection, and write tests for behavior that was never actually in dispute. Every extra moving part becomes future work: reviewers have to understand it, maintainers have to update it, and users will eventually hit the edge cases it quietly introduced.

This isn't unique to AI. Human developers overengineer, misunderstand requirements, and write bad tests all the time. The difference is that AI output can arrive quickly and in large volume, which shifts effort from building to evaluating. If reviewers can't confidently judge the change, the tool hasn't removed the hard part - it just moved it somewhere easier to overlook.

What are the costs beyond the code itself?

An AI coding workflow has costs that never show up in the pull request.

Start with attention. Switching between the problem, your prompt, the response, and the codebase costs time and cognitive bandwidth. For a straightforward task, that overhead might be small. For a tough architectural problem, repeatedly asking a model for "the next step" can fragment the reasoning that would otherwise help a developer understand the system as a whole.

Then there's data governance. A coding assistant might receive source code, error logs, architecture details, or snippets that include personal data. Before using it for professional work, you'll want clarity on what the provider retains, how submitted data is handled, what the applicable plan and settings are, and whether the employer has approved the service. Even if a provider claims data is processed in a certain region, that doesn't automatically answer the real privacy and legal questions.

For organizations subject to GDPR, the questions tend to include what data is involved, the provider's role, contract terms, transfer arrangements, and the safeguards that apply. US-based providers can raise additional questions around the CLOUD Act and the provider's legal obligations. Neither point means "using every US service is automatically unlawful." It does mean teams shouldn't treat a vendor's assurances or a default product setting as a substitute for review by the people responsible for privacy and security.

There are also dependencies. If a core part of development relies on one provider's models, pricing, uptime, acceptable-use policies, and product direction, those become operational variables. That might be a reasonable trade-off - but it's still a dependency. Teams should ask what happens if access changes, prices rise, or the tool behaves differently after an update.

Environmental impact is another factor - real, but hard to quantify per feature. Large-scale AI services run on energy and infrastructure, and the impact varies by model, workload, and the energy mix of data centers. One developer usually can't calculate the full footprint of each prompt. But a company using these tools at scale can still ask for credible information and weigh resource use against measurable benefit, instead of assuming "because it's software, it has no physical cost."

Finally, consider the professional value of the work. Some developers genuinely enjoy coding as a way to explore a problem and build understanding. If you delegate more of that process to an assistant, you may shrink the part of the job you actually find meaningful. That isn't a productivity metric - but it matters when you're designing a sustainable role and workflow.

When can AI coding tools still be useful?

Choosing not to use LLMs broadly doesn't mean pretending they never help. A constrained assistant can be useful when you're stuck, need a second way to describe a problem, or just want a starting point for a routine task. It might help you make sense of an unfamiliar error message, outline likely debugging steps, or draft a small snippet whose behavior is easy to verify.

The best use cases tend to share three traits: the context can be shared safely, the output is bounded, and a human can verify it quickly. Suggesting likely causes of a compiler error is usually easier to evaluate than asking for a full redesign. Drafting a repetitive test fixture is often easier to check than implementing a new authorization system. The point isn't that one category is always safe. It's that narrower tasks make assumptions and mistakes harder to hide.

How should a team decide whether to adopt them?

Treat adoption like a workflow decision, not like a referendum on whether AI is "inevitable." Just because a tool is available, popular, or subsidized doesn't mean it belongs in your engineering process. Start with a specific problem: slow test scaffolding, repetitive documentation, difficulty navigating a large codebase, or delays diagnosing common build failures. If there's no defined problem, there's no real way to tell whether the tool helped.

A practical evaluation can be broken into five steps:

1. Choose a bounded use case. Don't test "AI coding" as a whole. Pick a task with a known baseline and clear completion criteria.
2. Set data boundaries first. Decide what may be submitted, which service is approved, and who has reviewed the retention and privacy terms.
3. Measure the full cycle. Track time spent prompting, reviewing, correcting, testing, and maintaining - not just time to first output.
4. Check quality and ownership. Have reviewers assess correctness, unnecessary complexity, test usefulness, and whether the maintainer can explain the change.
5. Keep a non-AI path viable. Make sure the team can keep working if the provider is unavailable, access changes, or a developer opts out.

A pilot shouldn't only include the most enthusiastic early adopters. Include the people who will review and maintain the code, because their workload is part of the result. Compare similar tasks where possible, and look for regressions too - more review comments, bigger diffs, security concerns, or reduced understanding of the changed code.