Ask HN: Where is the programming profession going?
Large language models are rapidly reshaping software work, shifting much of the value from hand-writing code to defining architecture, constraints, and intent while supervising AI-generated implementations. Commenters describe gains in speed and prototyping but warn of “cognitive debt,” brittle systems, and declining code quality when teams treat agents as infallible or skip careful review and testing. Many expect low-skill and routine programming roles to be automated away, with demand concentrating on a smaller number of highly skilled engineers who can manage AI tools responsibly and translate real-world problems into robust software.
Overall sentiment
- Broad agreement that LLMs have already changed software work, but sharp disagreement on how far this goes and how fast.
- Thread mixes excitement about massive productivity gains with anxiety about quality, accountability, job shrinkage, and “vibe coding.”
Shifting role of programmers
- Many see “writing code” becoming the easy/mechanical part; the remaining value is in:
- Understanding problems, users, and domains.
- Architecture, system design, constraints, trade-offs.
- Managing AI agents and reviewing their output.
- Some argue the role is evolving from “programmer” to “engineer/architect/agent manager,” similar to historical “analyst + programmer” merging into “software engineer.”
- Others fear that not typing code personally weakens understanding, like students trying to do math after only reading the textbook.
Quality, complexity, and ‘cognitive debt’
- Concern that LLMs default to:
- Over-engineered solutions, unnecessary abstractions, and big scopes.
- Large volumes of mediocre PRs and partial migrations.
- New idea of “cognitive debt”: when the source of truth becomes prompts, plans, and opaque agents rather than deterministic code.
- Some teams report burnout from:
- Heavy up-front planning for agents.
- Large review loads for AI-generated PRs.
- Feeling they’re “fighting the tools” without net productivity gains.
LLM capabilities, limits, and workflows
- Strong adopters claim frontier models can implement most tasks, even in large legacy codebases, if:
- Work is decomposed into small units.
- There are detailed specs, plans, and tests.
- Critics report:
- Basic design/logic mistakes and hallucinated APIs/docs.
- Poor performance/robustness unless heavily supervised.
- Debate over whether such failures are inherent or “skill/usage” issues.
- Some treat code as “assembly”: they review high-level intent, generated docs, diagrams, and tests instead of source.
Adoption patterns and industry split
- Small/fast companies: more pressure to use LLMs aggressively; “vibe coding” common.
- Large/regulated firms: slower adoption, human-owned code, mandatory reviews; AI allowed but not forced.
- Likely split discussed:
- High-end, safety/performance-critical work: fewer but more skilled engineers using AI as power tools.
- Mid/low-end coding, prototypes, and simple business apps: heavily automated or replaced.
Long-term outlook and uncertainty
- Some predict programming will resemble operating CNC machines: fewer humans, more commoditized skills.
- Others expect AI to settle into better IDE-like assistants (local models, visual/code maps) rather than full “dark factories.”
- Many emphasize: nobody really knows; pace of model and tooling evolution makes any confident forecast suspect.