AI can code, but it can't build software

Can AI “build software” or just code?

• Many agree LLMs are very good at producing code snippets, small utilities, CRUD APIs, wrappers, and test scaffolding.
• Several argue that “building software” entails product discovery, tradeoffs, architecture, evolution over time, and non‑functional “ilities” (reliability, maintainability, security, scalability) — areas where current LLMs are weak.
• Some note this critique also applies to humans: many can code but can’t engineer robust systems.

Experiences with coding agents and vibe coding

• People report impressive successes: scientific simulations with full test suites, permission systems refactors, cloud infrastructure templates, and near‑production MVPs built largely by agents.
• Others describe painful failures: duplicated logic, spaghetti React/JS, misused libraries, invented API methods, broken logging setups, and subtle framework mistakes.
• “Pure vibe coding” (not reading the diff, letting agents run wild) is widely described as unpleasant and fragile; best results come when humans stay in the loop.

Architecture, maintainability, and technical debt

• Common theme: LLMs default to copy‑paste, avoid abstraction, and don’t “decide to refactor” proactively. They optimize for local fixes, not coherent design.
• Some use tests, strict linters, AST tools, and language‑specific analyzers (e.g. Roslyn, import‑linter) to enforce architecture and shape LLM output.
• There’s concern that vibe‑coded MVPs are harder to harden than systems designed well from the start, echoing earlier low‑code/no‑code disappointments.
• A minority speculate about a future where disposable, single‑use software makes traditional notions of technical debt less relevant for some apps.

Roles, skills, and organization

• Many see LLMs as “super interns”: great at typing and boilerplate, poor at deep debugging and novel design.
• Strong consensus that domain experts and engineers with deep system knowledge become more valuable, not less.
• Worry about the junior→senior pipeline: if juniors mostly prompt or aren’t hired, who gains the hard‑won experience needed later?

Limits of current models and future trajectories

• Constraints cited: small effective context, “context rot,” lack of training data on real messy internal code, weak long‑chain reasoning, and poor high‑level decision‑making.
• Optimists expect continuous tooling and model improvements (agents with monitoring, analytics, autonomous iteration) to approach “effective engineer” status for narrow products; skeptics think truly replacing software engineers is decades away, if ever.