Why LLMs Love Code, and What That Means for Everyone Else

There is a reason every LLM demo you have seen in the last two years defaults to a coding task. Ask a large language model to write a Python function, refactor a React component, or debug a Terraform module, and you get something close to a working senior engineer sitting next to you. Ask the same model to close your books, draft a contract, resolve a benefits dispute, or triage a patient, and the results are noticeably shakier. This is not a coincidence, and it is not simply a matter of “the models will catch up eventually.” Coding is structurally different from almost every other kind of knowledge work, and that structural difference explains both the enthusiasm currently sweeping the software industry and the much cooler reception LLMs have gotten everywhere else. Understanding why is the starting point for The Smarter Project, and it shapes almost every design decision we make.

Start with the plain fact that code is language. An LLM is, at bottom, a next-token predictor trained on enormous quantities of text, and code is some of the most abundant, most structured, most consistently formatted text that exists on the public internet. GitHub alone represents hundreds of millions of repositories of freely licensed, syntactically rigorous, semantically dense material, almost all of it accompanied by comments, commit messages, issues, and pull request discussions that explain intent. No other profession has anything like this. There is no public GitHub for legal contracts, tax returns, HR performance reviews, or clinical charts, both because such material is confidential and because it was never produced in a form designed for reuse and recombination the way source code is.

Second, and more importantly, code has an almost unique property among human-produced artifacts: it can be mechanically verified. A function either compiles or it does not. A test suite either passes or it fails. A type checker either accepts the change or rejects it. This gives coding a tight, cheap, automatable feedback loop that barely exists anywhere else in professional life. When an LLM proposes a change to a codebase, you can run the existing test suite in seconds and get an objective, non-negotiable signal about whether the change is safe. That signal can be fed straight back into a training or agentic loop, which is exactly what has powered the recent generation of coding agents. Contrast this with a contract redline, a marketing plan, or a clinical assessment, where “correct” is a matter of professional judgment, context, and often genuine ambiguity, and where the cost of finding out you were wrong is measured in months, not milliseconds.

Third, software engineering has spent three decades building an entire toolchain around exactly this kind of machine-checkable correctness: linters, static analyzers, type systems, continuous integration pipelines, containerized reproducible environments, version control with full audit trails of every change. None of this was built with AI in mind, but it turns out to be precisely the scaffolding an autonomous agent needs to operate safely and to have its work checked. A coding agent can open a sandboxed branch, make a change, run the pipeline, read the failure output, and iterate, all without a human in the loop, because the guardrails already existed. Try to construct the equivalent scaffolding for a general ledger or an HR investigation and you will find there is far less to build on.

There is a fourth property worth naming separately, because it is easy to miss: code is modular and composable in a way most professional work is not. A function, a class, a module, an API endpoint, these are all designed from the outset to be understood, tested, and modified in isolation from the rest of the system. That modularity means an LLM does not need to hold an entire enterprise codebase in its head to make a useful, bounded contribution; it can be handed a well-defined slice of the problem, with clear inputs and outputs, and reasoned about locally. Most other professional work resists this kind of decomposition. A contract clause cannot be fully understood without the rest of the agreement and the deal history behind it. A clinical decision cannot be isolated from the patient’s full history. An HR judgment call cannot be separated from months of context about a team’s dynamics. Software’s decades-long investment in modularity, originally adopted for entirely different reasons, turns out to be a second, independent gift to LLM automation, layered on top of the abundant data and the cheap verification.

Put these four properties together, abundant public training data, cheap and objective verification, mature automated tooling, and modular, decomposable work products, and you get a profession that is unusually well suited to being handed off to a model. It is no surprise, then, that the software industry has responded with a level of enthusiasm that borders on euphoria. Engineering teams are racing to automate code generation, code review, test writing, bug triage, dependency upgrades, and increasingly entire feature branches, with a fervor that looks less like adopting a new tool and more like the discovery of a new labor supply. That enthusiasm is not misplaced. It is a rational response to the fact that coding sits closer than almost any other profession to the sweet spot LLMs are actually good at.

But it is worth being precise about the boundary of that sweet spot, because it is narrower than “software engineering” as a whole. The moment you step just slightly outside of writing and modifying code, the advantage erodes fast. Writing a specification requires reconciling conflicting stakeholder intent, something no compiler will ever validate for you. Quality assurance in its fullest sense is not “does the code pass its own tests” but “does the product behave the way a real, unpredictable human expects it to,” which is an open-ended, exploratory, adversarial exercise that resists automation precisely because there is no fixed ground truth to check against. Continuous integration and deployment pipelines look automatable on paper, but in practice they are full of flaky infrastructure, environment drift, and judgment calls about when it is safe to ship, all of which carry real consequences if a model gets them wrong with too much autonomy. End-user support demands empathy, de-escalation, and the ability to sense when a rule should be broken, none of which shows up in a training corpus of resolved tickets. Vetting which new features are actually worth building is a product and business judgment problem, not a text completion problem. And infrastructure management, provisioning, scaling, securing, and recovering production systems, is exactly the kind of high-blast-radius, low-tolerance-for-error work where a confidently wrong model output can take down a system in a way a failed unit test never could. LLMs still help meaningfully in all of these areas, but the leverage is a fraction of what it is for the core task of writing code itself.

Zoom out further and the pattern sharpens. Compare software engineering to accounting, law, operations, human resources, or medicine, and the gap is stark. Accounting is bound by regulatory frameworks, audit requirements, and a low tolerance for the kind of confident-but-wrong output LLMs are prone to. Legal work turns on precedent, jurisdiction, and adversarial interpretation, where being plausible is not the same as being right, and where the cost of a hallucinated citation is a sanctioned attorney, not a failed build. Operations work is entangled with the physical world and with tacit, undocumented institutional knowledge that never made it into any training set. HR decisions carry legal exposure and require reading people, not patterns. Medicine is the starkest case of all: the stakes of an error are measured in patient outcomes, the training data is locked behind privacy law, and clinical judgment routinely depends on information that never gets written down. None of these fields lack smart people eager to use AI. What they lack is the combination that makes coding special: abundant public data, cheap objective verification, mature automation tooling, and modular work products, all already in place.

It is worth being fair to these fields rather than simply writing them off. Accountants have GAAP and IFRS, bodies of rules every bit as formal as a programming language’s grammar, and in narrow sub-tasks, reconciling transactions, flagging anomalies, drafting footnotes, LLMs already help meaningfully. Lawyers have contract templates and case law databases that are more structured than most people assume, and LLM-assisted discovery and first-draft redlining are already reshaping large parts of that work. The pattern is not that these professions are immune to LLM leverage. It is that the leverage arrives narrower, later, and with a much thinner margin for confident error, because none of them inherited coding’s decades of tooling built specifically for machine verification and modular reuse. The gap is one of degree, not of kind, but the degree is large enough to explain why a lawyer’s experience of an LLM feels categorically different from a developer’s.

This is the observation The Smarter Project starts from, and it shapes what we actually build. If the coding profession is where LLM-driven automation is most mature, then the coding community is, whether it intends to or not, running the world’s largest and most advanced laboratory for how humans and autonomous AI agents can work together productively. Agentic coding tools have already worked out, through painful trial and error, a set of patterns for this collaboration: declarative specifications that separate intent from implementation, version-controlled artifacts with full audit trails, sandboxed execution with human review gates, tight verification loops before anything is trusted, and composable, reusable building blocks rather than monolithic one-off scripts. These patterns were not designed in the abstract. They were forced into existence by engineers trying to keep autonomous agents from making expensive mistakes in production systems.

Our thesis is that these same patterns, stripped of their coding-specific syntax, are exactly what non-technical professions need in order to use LLMs safely and effectively, even though those professions will never have the abundant public data or the compiler-grade verification that coding enjoys. That is why Smarter is built the way it is: Kubernetes-inspired declarative manifests instead of ad hoc prompts, Git-friendly workflows so that every change to an AI resource is versioned and reviewable, reusable plugins instead of bespoke one-off integrations, and a platform architecture that treats connecting AI to private enterprise data as a first-class, auditable operation rather than an afterthought. None of this is a coding tool. It is coding’s operating discipline, translated for the accountant, the HR generalist, the operations manager, and the clinician, none of whom should have to become a software engineer in order to safely delegate work to an AI agent.

The harder and less obvious part of this thesis is timing. It would be easy to chase every new agentic coding pattern the moment it appears and rebuild the platform around it. We deliberately do not do this. The coding community moves fast in large part because its feedback loop is so cheap: a pattern that fails can be discovered and abandoned within days, at negligible cost, because tests run in seconds and a bad idea just breaks the build. Non-technical professions do not have that luxury. A pattern adopted by an HR team or an accounting department cannot be discarded the way a failed npm package can; the cost of building durable workflows and internal trust around the wrong pattern is measured in months of wasted effort and, in regulated fields, real compliance exposure. So The Smarter Project deliberately trails the broader agentic coding community, sometimes by months, sometimes by a year or more, watching which patterns survive contact with real production use and which ones turn out to be fads that looked exciting in a demo and quietly disappeared six months later. Retrieval-augmented generation, agent orchestration frameworks, tool-calling protocols, guardrail architectures: all of these went through a period of hype before the coding world converged on which versions actually held up under real load. We wait for that convergence on purpose, because getting the pattern right matters more to a compliance officer or a clinician than getting it first.

The bet underlying all of this is straightforward. Coding will keep being the profession where LLMs make the fastest, most visible progress, because the structural conditions that favor LLMs, machine-checkable correctness, abundant training data, and mature tooling, are not going away. But the patterns coding professionals are inventing right now to work safely alongside autonomous agents do not have to stay confined to coding. They can be extracted, generalized, and handed to every other profession that will never enjoy coding’s built-in advantages but still needs a disciplined, auditable, trustworthy way to put LLMs to work. That translation, done carefully and on a deliberate delay rather than in a rush, is the work.