AI Skeptic Friends

AI-assisted coding is drawing both hype and backlash, but the most consistent through-line is a split between “faster coding” and “free coding.” One side treats LLMs as a fancy autocomplete that can accelerate output while still leaving developers responsible for correctness, security, and long-term maintainability. The other side argues that modern progress comes less from raw model brilliance and more from agents—systems that can inspect a codebase, run tools, compile, test, and iterate—turning language models into practical engineering workflows.

A central skepticism targets the idea that LLMs will erase engineering jobs quickly. The argument isn’t that automation is impossible; it’s that software work is liability-heavy: every line of code creates risk, and generating more code doesn’t automatically create a strategic moat. Even if hardware and models improve dramatically, the work of building secure, reliable systems still demands judgment. The discussion also pushes back on “AI will take over everything” narratives, suggesting that the real timeline is tied to practical constraints—security, testing, integration, and the messy realities of production systems.

Where the conversation becomes concrete is in how serious LLM coding is actually done today. Instead of pasting prompts into a chat window and manually copying results, the more effective approach uses agents that can poke around a repository, author files, run Unix tools, interact with git, and call linters/formatters/model checkers via tooling such as MCP. The key claim: hallucinations become less dangerous when the agent has guardrails—tests, compilers, and feedback loops—so invented details get caught and corrected. Examples include an agent attempting a nonexistent API method (a chessboard “config” call), then revising after checking official documentation.

Still, the skepticism doesn’t vanish. Participants warn that “practical solved” doesn’t mean “solved,” especially for complex UI testing and production incidents where LLMs lack direct access to live systems. There’s also a recurring concern about security and compliance as code generation scales: session integrity, cryptographic tampering resistance, and the likelihood of subtle vulnerabilities increase when teams ship faster. Another major friction point is intellectual property and licensing. Developers worry that LLMs ingest code and snippets from public repositories, potentially creating downstream licensing obligations (e.g., GPL-style requirements) that teams may ignore until it becomes a legal or architectural problem.

The debate also turns philosophical: some argue that LLMs will reduce tedious boilerplate work (like OAuth/OpenID flows or repetitive login plumbing), freeing humans to focus on higher-level architecture. Others counter that speed can erode craftsmanship, pushing teams toward “initification”—more abstraction, more automation, and less understanding. Even so, the mood is not purely anti-LLM. Many participants say they’re actively using tools like Cursor and experimenting with agent modes, while insisting that developers must still curate, review, and enforce standards. The emerging consensus is pragmatic: agents can reduce drudgery and catch certain classes of errors, but software engineering remains a discipline of judgment, verification, and responsibility—especially when security, testing, and licensing enter the picture.