Principles
The Economics of AI Automation
G6 exists because of a specific view about how AI will actually change the economy — gradually, unevenly, and bottleneck by bottleneck. That view shapes everything we build. Here it is in full, followed by how it translates into the way G6 works.
This analysis is adapted from Professor Chad Jones’s talk “A.I. and Our Economic Future” and its “weak links” framework, retold to explain how that view shapes the way G6 is engineered.
Executive summary
We believe AI could be the most transformative technology of our lifetime, but its effects may arrive more slowly than Silicon Valley’s most dramatic forecasts suggest. The key reason is that economies, businesses, and jobs depend on many interlocking tasks. Automating some tasks does not automatically transform everything, because the remaining “weak links” become the bottlenecks.
We contrast two extreme scenarios. In the first, AI automates software engineering, then AI research, then general cognitive work, then robotics and physical labour, leading to explosive economic growth. In the second, AI behaves more like past transformative technologies — electricity, semiconductors, the internet — which changed the world but did not permanently raise U.S. growth above roughly 2% per year.
We believe the most likely outcome is somewhere in between: AI probably will have enormous long-run effects, potentially “multiple internets” in scale, but the full growth explosion may take decades rather than a few years. However, the downside risks — cyberattacks, biosecurity threats, and other catastrophic harms — could arrive much sooner.
Main ideas
1. AI could produce explosive growth, but only if it automates both cognitive and physical work
We believe the optimistic “FOOM” scenario is plausible: AI first automates coding, then uses that capability to improve AI itself, design better chips, accelerate science, develop drugs, and eventually control robots. Once machines can perform both cognitive and physical tasks, standard growth models imply that economic growth could accelerate dramatically.
We do not dismiss this scenario. We acknowledge that leading AI figures have predicted rapid progress and that recent AI models already appear extremely strong at software-related tasks.
2. But history suggests transformative technologies often take decades to reshape the economy
We contrast AI with electricity, internal combustion engines, antibiotics, semiconductors, IT, and the internet. These technologies were undeniably transformative, yet U.S. living standards have grown at roughly 2% per year for about 150 years.
We believe each major technology may have prevented growth from slowing, rather than causing a permanent jump in the growth rate. New technologies often require complementary inventions, organisational changes, infrastructure, and new business processes before their full impact is felt.
3. “Weak links” are the core framework
We believe the central concept is that a system is only as strong as its weakest link. A business, a supply chain, an economy, or a job depends on many tasks being completed successfully. Improving 17 out of 20 links does not fully solve the problem if the remaining 3 still bottleneck the whole system.
Three examples make the point concrete:
- An iPhone is a bundle of parts that must all work. If just one falls short — the screen, the gyroscope, the camera — the value of the entire device drops sharply, however good everything else is.
- A silicon chip can be ruined by a single microscopic defect. One flaw among billions of transistors is enough to render the whole chip useless — yield is dictated by the defects, not the successes.
- The Space Shuttle Challenger was lost because of a roughly $25 O-ring that failed in the cold. One small, cheap part broke an extraordinarily complex and expensive system.
Each is the same lesson: a system is only as strong as its weakest-performing component. That weakest link is the rate-limiting step of the whole process — and it is the rate-limiting step, not the parts that already work well, that determines the system’s real cost.
This also explains why having vastly more computing power has not made researchers 100 million times more productive: computers are excellent at some tasks, but humans still need to decide which questions to ask, what data to use, and how to interpret results.
4. Automating one task may have surprisingly limited immediate economic impact
One striking example is software. We believe that even if software became infinitely abundant, the static gain to GDP might be around the software sector’s share of GDP — roughly 2% — because other weak links would still constrain output.
The point is not that software automation is unimportant. Rather, one bottleneck being removed is not enough. For explosive growth, AI must repeatedly identify and automate the next bottlenecks across the whole economy.
5. The model predicts eventual acceleration, but weak links slow it down
We describe a model where ideas drive long-run growth, production has weak links, and automation gradually removes those weak links. When calibrated to historical U.S. data, the model suggests growth may eventually accelerate substantially.
However, in the baseline scenario, the acceleration is slow. Growth might rise from around 2% to 2.3% by 2050, with income per person only modestly above the old 2% trend by mid-century. In more aggressive scenarios, where AI raises automation across the whole economy at something like Moore’s Law speed, growth accelerates much faster — but even then, the full transformation may take decades rather than just a few years.
6. Jobs are bundles of tasks, so AI may raise wages in some fields before replacing them
We use radiologists as an example. Geoff Hinton predicted in 2016 that radiologists would soon become unnecessary, but there are more radiologists now and they are paid more. We believe the explanation is that AI may automate many parts of a job while making the remaining human tasks more valuable.
Radiologists still consult, handle difficult cases, coordinate with other doctors, and interpret ambiguous situations. By contrast, we believe Uber drivers may be more vulnerable because self-driving cars aim to automate nearly the entire job.
7. Software engineers may not disappear as quickly as people expect
Although AI may be especially strong at coding, we believe companies will still need people to integrate AI into real businesses, handle sensitive data, make judgment calls, and manage implementation. The key question is not only whether AI can code, but whether organisations will trust AI systems to redesign important workflows without human oversight.
8. Inequality is a major concern, but abundance could make redistribution easier
We believe there is a risk that AI reduces the value of labour and increases the share of income going to capital. A more optimistic view is that if AI produces a world of abundance, there will be enough resources to make everyone better off — provided redistribution works.
We also note that many high-skilled workers own shares in the stock market, so they may benefit from capital income. The bigger concern is people who do not own financial assets. We see this as a political economy problem rather than a purely technical economic one.
9. Meaningful work may also be disrupted
We believe that if AI becomes better at producing research, analysis, or creative work than humans are, it could affect people’s sense of meaning. A post-work world may resemble retirement or summer camp: people may still find meaning through family, hobbies, learning, and community, but the transition could be psychologically and socially difficult.
10. Catastrophic risks may arrive before the economic benefits
We end on a more worried note. There are two kinds of catastrophic risk:
- Bad actor risk: A malicious person or group could use advanced AI to design cyberattacks, biological threats, or other dangerous tools.
- Alien intelligence risk: A more speculative concern that humanity may create entities more powerful than itself and struggle to retain control.
The weak-link framework implies that benefits require strengthening many links over time, but harm may require breaking only one critical link. For example, AI-enabled attacks on the electric grid, financial system, banking system, or biological infrastructure could happen before the broader economic transformation is complete.
How G6 works
The essay above is the worldview: progress comes from strengthening one weak link after another, and a single broken link can sink the whole system. That is exactly the problem G6 is engineered around. Here, in plain language, is how that shows up in the way G6 is actually built.
Seven guards against silent failure
G6 starts from an uncomfortable premise: when a language model produces an answer, that is not success — it is a claim that still has to be checked. Before it attempts a task, G6 frames the work the way an experienced engineer would, asking what could go wrong and designing for it. A handful of non-negotiable guards follow: design the approach before executing it; build in redundancy so no single faulty component decides the outcome; run a pre-mortem so failure modes are named up front rather than discovered later; keep the reasoning inspectable so it can be audited and corrected; plan for both the common path and the messy long tail; and turn every repeated human intervention into a reusable, automated check.
A practical rule of thumb runs through all of this: at least two-thirds of decision-critical work should be grounded in verified prior work, real context, deterministic computation, tests, or external sources — not pure model guesswork. And because independent components can disagree, G6 borrows Byzantine fault tolerance from distributed systems: tolerate a faulty minority by requiring enough genuinely independent parts to agree before acting.
Four-valued logic for incomplete evidence
Real evidence is rarely a clean true or false, so G6’s quality layer refuses to pretend otherwise. Every claim is placed in one of four states: supported-true (evidence backs it, nothing refutes it), supported-false (evidence refutes it), both (a genuine, unresolved conflict in the evidence), or neither (not enough evidence to say). On top of that, G6 can ask whether a claim is necessary or merely possible, known or only believed, required by policy, or true only at a particular moment in time.
This sounds abstract, but it is what keeps the system honest: when the documentation says one thing and the running code says another, that is recorded as a conflict to resolve — not quietly rounded up to “probably fine.”
An untrusted planner behind trusted runtime controls
The part of G6 that decides what to do next — the planner — is treated as untrusted. It can propose actions, but it never executes them directly. A policy engine sits in between and enforces a strict order of authority: hard runtime limits outrank the kill switch, which outranks policy, which outranks the validators’ vote, which outranks pattern detectors, which outrank the planner, which outranks raw model text.
If a safety check fails, a protected file is touched without approval, or a hard limit is approached, execution stops rather than letting the model talk its way past the guardrails. Agreement among checkers is treated as a useful signal, never as proof — the validator pool deliberately includes tests, type checkers, linters, and security scanners, not just other models.
Swiss-cheese components and three honest labels
G6 does not trust any single agent, model, or test. It layers them — like slices of Swiss cheese, arranged so the holes never line up. Different components play to their strengths: one designs architecture, another independently debugs and reviews, others apply changes safely, run tests, and keep documentation readable for humans.
The most important output of all this is an honest label. Every result is marked verified (it passed the required checks), qualified-draft (useful, but incomplete — with its limits stated), or blocked-escalated (too risky to proceed without a person). The label has to match the evidence; a confident-sounding answer with nothing behind it is exactly the failure G6 exists to prevent.
Bounded, friendly governance
As G6 improves itself, it has to stay the kind of system you would actually want to run. A set of invariants is held fixed no matter what the system learns: it should benefit the user, remain interruptible and correctable, keep changes reversible, tell the truth, surface its uncertainty, respect permissions, never deceive, and leave genuinely dangerous decisions to a human.
Low-risk changes — copy, test fixtures — move freely; high-risk ones — anything touching governance, deployments, payments, or secrets — require explicit approval. Before any self-change ships, it has to answer plainly: why does this help the user, what evidence supports it, what could go wrong, and does it preserve those invariants?
Self-improvement through dogfooding
G6 uses its own reliability machinery to improve G6. Three nested loops run continuously: did the output actually work, was the process that produced it sound, and is the reliability layer itself genuinely making things better over time?
Improvements are allowed in the safe-to-change surfaces — prompts, routing and retry policies, failure classifiers, examples, and documentation — while the core governance, security boundaries, billing, and human-approval rules are off-limits to self-modification. Every self-improvement is held to the same bar as any other work: tests, independent review, and a measured before-and-after.
Curating minimal context for each agent
More context is not better context. Instead of dumping an entire codebase and every policy into each model call, G6 assembles a small, high-signal bundle tailored to the job at hand. Governance and user intent stay compact and authoritative; repository details are pulled in just-in-time as file paths, diffs, and search results rather than loaded wholesale; and examples are curated down to a few canonical ones.
For long-running work, finished phases are summarised and notes are kept in structured memory so the system does not slowly lose the plot. Every piece of context is sourced and time-stamped — and nothing is labelled verified if the context it relied on was missing or past the freshness window its source declares.