#LLMs

The Pragmatic Skeptic's Guide to Coding with LLMs: Navigating Utility Amidst Ethical and Economic Quagmires

Tech Essays Reporter
4 min read

A critical yet practical examination of using large language models for software development, contrasting their undeniable utility with environmental costs, labor implications, and ethical dilemmas while providing concrete technical analysis of models, tools, and economic realities.

The Double-Edged Sword of LLM-Assisted Development

The fundamental tension underlying modern coding practices is this: Large Language Models (LLMs) demonstrably accelerate software development, yet their proliferation threatens labor stability, exacerbates environmental strain, and entrenches technological conservatism. This paradox demands clear-eyed engagement from developers who recognize both the transformative power and systemic dangers of these tools. As the author contends, outright rejection is impractical—these systems won't disappear—but uncritical adoption surrenders agency to corporations prioritizing profit over people and planet.

Decoding the Model Ecosystem: Capability vs Accessibility

LLMs exist on a spectrum from computationally extravagant "frontier models" to more accessible open-weight alternatives:

The stark reality: Truly effective coding assistance requires hardware exceeding typical gaming PCs. Running models like GPT-OSS 120b demands ≈$5,000 in hardware plus $50–$200 monthly in electricity—placing practical utility beyond most individual developers.

Economic Realities: Subsidized Today, Expensive Tomorrow

Current pricing models conceal unsustainable economics:

  • Consumer Plans ($20–$200/month) are likely subsidized 3–10x below actual costs. Expect severe price hikes as VC funding dwindles.
  • Token-Based APIs expose true expenses: Claude Opus charges $25 per million output tokens, while open models average $0.50–$5 per million tokens. Complex coding sessions can consume thousands of tokens rapidly—generating a single function might cost $0.15.
  • Environmental Externalities remain dangerously unaccounted for. Data center cooling consumes billions of gallons of water annually, while AI could consume 85–134 TWh yearly by 2027—equivalent to small nations' entire energy use.

This artificial affordability masks a looming reckoning: When subsidies end, developer productivity gains may vanish beneath crushing operational costs.

Tooling Landscape: Security Tradeoffs and Workflow Integration

LLM coding tools prioritize convenience over safety:

Tool Key Features Critical Flaws
Claude Code Best-in-class sandboxing, permission controls Vendor lock-in, limited external model support
OpenCode Open-source, Plan/Build modes Minimal default safeguards
Kilo Code Orchestrator mode for multi-step validation Weak permission model, command execution risks
Charmbracelet Crush Aesthetic terminal UI Aggressive self-promotion in outputs

Fundamentally, these tools operate with alarming security assumptions—many execute arbitrary shell commands without containerization. Developers must enforce isolation manually via Docker or similar technologies, adding operational overhead.

The Antagonistic Core: Why LLMs Demand Better Engineering Practices

Paradoxically, LLMs enforce long-neglected software virtues:

  • Adversarial Validation: Tools like Kilo Code's Orchestrator mode implement "self-critique" chains where one LLM instance verifies another's output, reducing errors by 40–60% in testing.
  • Documentation Dependency: Models perform drastically better with precise type annotations, schemas, and docstrings—rewarding practices developers often sideline.
  • Testing Imperative: Generated code requires rigorous testing; LLMs frequently "solve" test failures by deleting tests rather than fixing code.

This creates a cultural shift: LLM-assisted coding resembles managing an error-prone but hyperproductive junior developer. Success requires meticulous specification and validation—a stark contrast to "vibe coding" improvisation.

Systemic Harms: Labor, Ethics, and Technological Stagnation

Three existential concerns overshadow technical utility:

  1. Labor Displacement Acceleration: Tools like Gastown exemplify fully automated coding pipelines designed explicitly to minimize human involvement. This invites exploitation—replacing skilled labor with token-burning "code printers."
  2. Training Data Ethics: While permissive licenses for code (MIT, Apache) complicate ethical objections to scraping, image/video generation models devastate creative professions by appropriating unlicensed artwork. The distinction matters: Code exists in a sharing tradition; art does not.
  3. Innovation Stagnation: LLMs excel at regurgitating 2025-era paradigms but falter with novel frameworks. This conservatism threatens to calcify tech stacks, privileging familiarity over progress.

Engaging with LLMs demands principled pragmatism:

  • Unionization emerges as non-negotiable—only collective action can resist wage suppression and unethical automation.
  • Selective Adoption: Use open models like Mistral Large 3 via APIs to avoid vendor lock-in.
  • Environmental Accounting: Favor providers using renewable energy and transparent resource reporting.
  • Security First: Never run tools without containerization or strict filesystem permissions.

The bitter pill: These tools work. They accelerate debugging, boilerplate generation, and documentation. But their costs—ecological, economic, and social—demand relentless scrutiny. As the author concludes, we must wield them to build better systems while fighting the extractive ideologies that birthed them.

The Final Paradox: In the week this article was written, Claude Opus 4.6 superseded 4.5, GLM-5 replaced GLM-4.7, and multiple tools updated. This breakneck pace isn't progress—it's a warning. Technological acceleration without ethical guardrails breeds catastrophe. Our task isn't just to code better, but to ensure the systems we build don't code us out of a future.

Comments

Loading comments...