Coding is not solved
Claims that “coding is solved” by large language models draw sharp pushback from engineers who point out that writing snippets or porting code is very different from designing, verifying, and maintaining complex systems. Commenters describe AI as an extremely powerful accelerator for boilerplate, refactoring, and bug-finding, but say agentic coding often produces fragile, bloated, or opaque codebases that still demand experienced humans for architecture, testing strategy, and accountability. The emerging consensus is that AI has radically changed how code is produced, especially for routine tasks, but has not eliminated the hard parts of software engineering or the need for human judgment.
Is “coding” solved? Divergent positions
- One camp claims “coding is solved today”: frontier LLMs can write, read, port, and optimize code in most languages at or above typical human level, especially for CRUD, algorithms, and refactors.
- Others argue this is overstated: LLM code is still worse than good human code, especially on architecture, long‑term maintainability, and non‑functional requirements (NFRs).
- Several distinguish “coding in the small” (functions, endpoints, ports) as largely solved vs. “software engineering” (requirements, design, tradeoffs, lifecycle) as far from solved.
Capabilities vs. limits of current models
- Success stories: large ports (e.g., hundreds of thousands of LOC TypeScript→Rust), heavy Agentic workflows, board‑game implementations, major productivity gains (10×+ claimed).
- Critics note these are often constrained problems with strong oracles (existing behavior, test suites) and don’t prove end‑to‑end greenfield system design is solved.
- Long‑term planning, global architecture, and future‑proof API/type design are repeatedly cited as weak spots.
Quality, slop, and code review at scale
- Many report AI empowers weak developers to produce much larger quantities of poorly understood code, overwhelming human review (tens to hundreds of thousands of LOC per week).
- AI code reviewers frequently nitpick style while missing deep design flaws; “AI reviewing AI” is seen as dangerous without strong human oversight.
- Some organizations already treat AI‑generated PRs as essentially unreviewed, leading to regressions, lost observability, and subtle correctness/performance issues.
Testing, determinism, and “understanding”
- Pro‑AI side: if you have strong specs and massive automated tests, it matters less who/what wrote the code; tests and fuzzers can also be AI‑generated.
- Skeptical side: you still need humans to define what to test, interpret requirements, and notice behaviors that weren’t specified; otherwise agents optimize only what’s in tests and let everything else drift.
- Debate over “non‑determinism”: some say LLM stochasticity is no worse than human error; others stress that opaque, non‑repeatable generation is not analogous to compilers or proven libraries.
Accountability, risk, and domains
- Broad agreement that accountability remains human/organizational; AI can’t be punished or held liable.
- Some argue most enterprise software is low‑risk and AI slop is “good enough”; others note even mundane systems (payments, logistics, healthcare admin) can cause real‑world harm when they fail.
Impact on roles and skills
- New “skill”: orchestrating agents, writing AGENTS.md and architecture docs, designing specs and tests, and gating merges rather than hand‑coding.
- Worries about “AI overdose” and deskilling: juniors may never develop deep problem‑solving ability; seniors feel decades of coding expertise are devalued.
- Many foresee fewer “code monkey” roles but continued demand for people who can reason about systems, requirements, and tradeoffs.