TL;DR

As scaling laws fade and LLM performance stabilizes, the era of waiting for a smarter model to save us is over. 2026 is the year of operational sobriety: it is time to engineer around limitations and make imperfect models useful today. Doing that requires a strategy.

This article breaks down the practical playbook for the next phase of enterprise AI:

• The "Software Factory" Revolution: Why AI coding agents exploded due to the perfect data integrity of code repositories, and how this "disposable software" model is erasing the poverty line for automation—even in risk-averse sectors like government.
• The T-Shaped Strategy: A framework for adoption that combines broad organizational uplift (breaking the addiction to certainty) with deep vertical breakthroughs (specialized agentic workflows).
• Engineering the Last Mile: Why success in 2026 relies on Context Engineering (controlling what the model sees) rather than just prompting, and how to identify high-ROI use cases where failure is reversible.
• The GenAI Data Flywheel: We explain why the old ‘behavioral data’ moat (what users did) is no longer enough. The new moat is decision-trace data: the full problem-solving trajectory plus the feedback signals that distinguish good from bad. We reveal how to capture the invisible ladder of decision-making to build a proprietary engine that compounds over time.

If you are tired of demos and ready to build systems that survive production, this is your blueprint.

Before We Begin: Know the Boundaries

Understanding the model layer defines what today's LLMs can do, what they cannot, and which gaps can be bridged by engineering. Without these boundaries, application strategy devolves into "see problem, throw AI at it." For background, see the companion piece on the model layer AI’s 2026 Pivot (The Model Layer).

The Era of Disenchantment

In 2026, LLM pre-training gains are shrinking, and reinforcement learning has not provided an infinite scaling loop. Progress continues, but no longer compounds. We have moved from step changes to incremental work. DeepMind's Demis Hassabis and former OpenAI chief scientist Ilya Sutskever suggest we are still one or two Transformer-magnitude breakthroughs away from AGI, gaps measured in years or decades. This plateau is a strategic gift. It gives teams time to engineer reliability out of imperfect tools. We are no longer waiting for a smarter model; we are engineering systems that make current ones work.

Construction offers a parallel. We have finished erecting the steel frame of a skyscraper at record speed. Now the vertical growth stops, and the slow, invisible work of wiring, plumbing, and drywall begins. The skyline isn't changing anymore, but this is the only phase where the building actually becomes habitable and valuable.

This plateau is not bad news. It is a strategic gift. It gives society time to adapt and teams time to engineer reliability out of imperfect tools. If the last year left you thinking "benchmarks up, value flat", this explains why. We are no longer waiting for a smarter model to save us; we are engineering the systems that make the current ones work.

The "Software Factory" Opportunity

The most certain incremental value in 2025 and 2026 does not lie in chatbots or image generation. It lies in coding.

This dominance is not accidental; it is structural. Coding is one of the few scenarios that is naturally optimised for both pre-training and post-training. If coding agents had not emerged as the leader last year, that would have been the true anomaly.

The Pre-Training Advantage: The Full Problem-Solving Record

What makes coding data uniquely valuable is that it captures the entire arc of problem-solving, not just the final answer. GitHub archives nearly twenty years of this complete process: the failed attempts, the bad logic that was rejected, the specific lines that broke the build, and the precise edits that fixed it.

The Post-Training Advantage: Perfect Feedback

The feedback loop in coding is binary and incredibly dense. Code compiles or it fails. Tests pass, or they break. Deployment succeeds, or the system crashes.

For an AI model, this is an ideal learning environment because the reward signal is unambiguous. There is no nuance or "maybe", just functional reality.

With both massive historical data and instant, objective feedback, the explosion of coding agents was inevitable. It is simply gravity taking effect.

The "Software Poverty Line" Disappears

But if you only understand this as "programmers just got more efficient", you are underestimating what is happening. The more important shift is this: large numbers of people who never wrote code and never understood engineering now possess the ability to produce software for the first time.

For decades, many problems could have been solved with software (not necessarily AI software, just traditional software). But developing software was prohibitively expensive. You needed highly paid engineers, documentation, testing, and maintenance. This created an invisible "poverty line" for software production. Only high-frequency, high-value, sufficiently generic business processes (like bank transaction systems, e-commerce platforms, or investment research tools) justified the cost of dedicated development teams.

Below that line sat an enormous volume of unmet demand. A district office's statistics dashboard. A temporary project's collaboration workflow. A one-time data migration task. These needs could not justify hiring developers because the ROI was negative. So organizations resorted to inefficient manual workarounds: Excel spreadsheets, paper forms, human labor stacked on human labor.

AI coding has erased that expensive poverty line.

The "Disposable Software" Era

We can call this new environment the era of "disposable software".

In the past, if you built software, you expected to use it for years to justify the investment. In 2026, now that code has become cheap, you can have AI write a tool for a one-week project or even a one-hour task this afternoon. When the task is done, you throw the software away without regret.

The software AI produced does not need to contain AI functionality. It might not even qualify as "real software" by traditional definitions. It could be a few hundred lines of Python, a simple format converter, but it pulls you out of wasted time and gives you back control.

Whether at work or in daily life, you have likely faced moments where you were doing something mechanical and mind-numbing, cursing under your breath: "It's 2026, and I'm still doing this manually?"

That frustration defines what we call "long-tail demand". In the past, these needs were too fragmented, too personal, and too low-value to justify custom software. But now, if you can work with AI, many of those tasks that made you want to smash your laptop can be solved with a few dozen lines of script.

This is AI coding's biggest social contribution. It is not making elite programmers write code in their sleep. It is bringing automation, order, and efficiency to countless corners of work that previously could not afford software at all.

From "Personal Liberation" to "Organisational Nightmare"

This sounds like progress. The last mile of "software eating the world" has finally been paved.

But (there is always a "but") when "everyone is a programmer" becomes reality, new problems emerge. In a flexible startup, employees writing scripts to improve their own workflows is a net positive. In a highly regulated enterprise with strict compliance requirements, it becomes a liability.

Picture this: An intern wants to automate a task. They do not understand permission controls. They accidentally sent a notification to every user in the database. Or consider unintentional data deletion, unauthorized access to sensitive systems, or any number of risks that used to be confined to engineering teams. These risks now exist across the entire organization because anyone can ask AI to write code, but you cannot expect every code author to simultaneously understand engineering practices, security protocols, access controls, and compliance frameworks.

Once software production scales up across an organization, relying on manual reviews, manual testing, and manual coordination is unsustainable. The only path forward is to industrialize the entire software production pipeline so that rules, permissions, testing, and auditing all happen automatically.

I was surprised to discover that government agencies are even further ahead on this particular challenge.

The Radical Government: Decoding the "AI Factory"

Last month, I attended the Alberta government's AI Retrospective. They are building an "AI Factory" that automates software development at scale, treating it as a serious, long-term engineering initiative.

Why Government Software Was Always Slow and Expensive

The problem was never incompetent people. It was three structural choke points.

• Reading compliance rules (data sovereignty, privacy laws) takes longer than writing code
• Manual development with requirements in memory leads to "this isn't what I wanted" feedback loops
• Security audits and compliance checks pile up at the end, stalling projects for months

How the AI Factory Works

Step 1: Embed the Rules Upfront

The hardest part of building software used to be locating the invisible landmines (privacy limits, security protocols, compliant processes). The AI Factory bakes these rules directly into the system constraints. When a requirement is submitted, the AI immediately filters out non-compliant approaches. Errors are blocked at the source, ensuring the direction is correct before a single line of code is written.

Step 2: AI Orchestrates the Code

This mirrors the "planning mode" of modern coding agents. You define the goal; the AI scans reference docs and generates a complete project plan, breaking down modules and sequencing. Once approved, it executes step-by-step. It builds the UI, logic, and tests simultaneously. If you need a change, it adjusts at the planning layer and re-executes. Crucially, unlike generic agents, it operates strictly within the pre-defined templates and compliance boundaries. It is like working with a disciplined project assistant, not a rogue coder.

Step 3: Automated Acceptance

Manual reviews (security, compliance, architecture) used to drag on for weeks. Now, the AI handles them instantly. As soon as code is written, the system scans for vulnerabilities, checks configurations, and verifies documentation. If it passes, it proceeds; if not, issues are flagged immediately. The process compresses weeks of bureaucratic lag into minutes of automated verification

Beyond the production line, there is a dedicated "Digital HR System" for the AI agents themselves.

Every agent is assigned an identity, strict permissions, and an activity log. Who is authorized to view specific data? Who is allowed to modify a specific segment of logic? Every input and output is fully traceable. We are already seeing major cloud vendors building this type of infrastructure, such as Microsoft's M365 Agent SDK.

When I first heard about this AI Factory, it sounded slightly idealistic. However, they plan to open-source the framework early this year. When it is released, we will examine it immediately to verify its practical viability.

Regardless of the execution, the signal is unmistakable. The government is not simply trying to help people write code faster. They are attempting to compress the entire painful cycle (design, development, and acceptance) into a highly automated production line.

This is not just a government story. It is likely the recurring paradigm that all enterprises (including traditional industries) will adopt to finally solve the complex, scattered long-tail problems they have ignored for years.

The Bottleneck is People

LLMs will still need better infrastructure to fully unleash its power (reliable workflows, access controls, testing, audit trails), but right now the biggest bottleneck is human readiness: org design, work habits, and comfort with uncertainty.

Given what today’s LLMs can already do, the GDP impact should be obvious, yet it is still muted in many places. The main constraint is not model capability; it is that most organizations are still operating on the previous management and delivery system.

Broad Uplift

One useful approach the government shared is a T-shaped strategy, starting with broad uplift through recurring cohorts. The point is not to turn everyone into technical specialists, but to break a deeply rooted dependence on certainty and linear returns. I was discussing this recently with one of my clients. Encouraging AI adoption is not as simple as sending a memo saying, "Please use AI more". The real blocker is not a lack of skill, but a need for a mental shift.

Most professionals are trained on a reliable exchange rate: put in two hours, close two tickets, show clean output. It is safe, predictable, and emotionally reassuring. AI adoption breaks that exchange rate because early exploration is non-linear and often looks unproductive before it clicks.

What this looks like in practice:

• You spend time iterating prompts, and the first stretch can produce mostly unusable output.
• You research tools, hit dead ends, then still have to learn and troubleshoot the one that finally fits.
• You ask AI to build a small internal tool, and it runs, but not reliably, or it fails in a way that requires diagnosis.

That uncertainty triggers a quiet fear of looking incompetent, and that self-protection is a larger brake on adoption than a lack of training.

Safety Plus Small Wins

If the goal is organic growth of AI use inside teams, the organization has to supply psychological safety and room for small experiments. Small failures must be safe, curiosity cannot be crushed by scheduling pressure, and experimentation cannot require people to bet their reputation. At the same time, teams need repeated small wins, because frequent modest payoffs create momentum more reliably than betting everything on one big initiative.

There is a real balancing act here: execution on core projects must stay tight, but AI adoption cannot be treated as an optional hobby for “when things slow down.” The reason is structural: as AI becomes embedded into broader infrastructure, more routine work gets automated, and humans get pushed up the stack into judgment, trade-offs, and creation.

Uncertainty is the Career Moat

In the AI era, tolerance for uncertainty is not just an entrepreneur trait, it becomes a durable professional advantage. Linear effort-for-linear output becomes less differentiated, while the ability to define problems and make decisions in ambiguity becomes more valuable. Anything deterministic and procedural trends toward automation, leaving humans the messy territory where judgment matters.

This is why I now prioritize two questions when evaluating talent:

1. What upgrades have you made to your work habits recently?
2. When you find a new tool that might be useful but requires upfront learning, how do you decide whether to invest the time?

The first question identifies people who are stuck in execution mode without looking up. The second tests for an "investor mindset": the willingness to endure the non-linear pain of learning today for the sake of exponential efficiency tomorrow.

If someone cannot answer these clearly, they may be highly skilled, but they are likely optimized for the previous era, not this one.

Vertical Breakthroughs

In the T-shaped strategy, this vertical line represents "Deep Agentic Use Cases". The goal is to identify high-ROI workflows, deploy a specialized technical team, and master that specific vertical, transforming it into a professional Agentic Workflow. The aim is not incremental gain, but a leap in efficiency of several multiples.

However, this layer is also bottlenecked by people. Observing the technical community, I see three distinct camps.

• Camp #1 tries a tutorial, builds two agents, sees no disruption, and declares AI dead. The failure is not the AI; it is stopping before reaching the stage where serious engineering begins.
• Camp #2 believes AI will disrupt everything immediately. The problem is false confidence. A 90% complete demo is trivially easy, but production requires 10x the effort of the initial setup.
• Camp #3 understands AI is not magic, but it does not need to be. They acknowledge flaws, engineer around limitations, and design workflows that constrain AI where it is weak and let it shine where it is strong. This is the winning approach.

The hype might be a bubble, but the technology is not. The bottlenecks are human: non-technical staff need a mindset shift, technical staff need strategic rationality, and everyone needs to skill up.

The Shift from "Solving" to "Defining"

Once AI enters production, individual capability shifts from "problem-solving" to "problem-definition". Execution becomes cheap; direction becomes valuable.

If you can clearly articulate the goal, boundaries, constraints, and evaluation criteria, you have won. The same model produces vastly different quality outputs based on the quality of the task definition.

Execution details (tech stacks, regex, data sourcing) will be handled by LLMs. We will stop memorizing APIs and syntax and focus on: What do I want to achieve, and how do I verify it?

The future differentiator will be who develops the muscle memory for clear problem definition soonest. AI's dividends will release slowly, giving society a window to adapt: learn to define the problem, then outsource the execution.

The Engineering Dividend Begins

We have covered the certain value of coding agents and the macro strategy for adoption (the T-shaped approach with horizontal breadth and vertical depth). The vertical axis requires planning for deep, high-ROI use cases where the upside is not 10% efficiency, but 10x to 50x impact.

This is where enterprise work gets real. The difference between a demo and an industrial system lies in execution quality. Reliability, control, auditability, and safe operating boundaries matter as much as the model itself because the workflow is what actually touches production systems and risk.

2026 is pivotal for this vertical layer because large models are shifting from the "frenzy phase" to the "plateau phase".

During the frenzy, engineering often felt futile. You might spend weeks patching a model's weakness, only for a new release to fix it natively the next day, rendering your effort obsolete.

In 2026, the marginal gains in raw reasoning capability are shrinking. Engineering efforts (fine-tuning, RAG, agent orchestration, and system controls) are becoming genuine moats. They are no longer at risk of being instantly overwritten by a model update. Whether you are building AI products or driving internal efficiency, 2026 is the year to fully commit to engineering without fear of obsolescence.

Method: Accept Imperfection, Engineer the Last Mile

How do we succeed in 2026? By admitting that models are imperfect and using engineering to close the gap. Three layers:

1. Problem Definition: Which tasks fit the LLM's pulse?
2. Engineering Tactics: Given LLM limitations, what makes a system actually work?
3. Commercial Judgment: Which enterprises are positioned to capture this value?

Layer 1: Task Selection

Balancing Automation With Human Oversight

We are discussing enterprise-level implementation here—how to land industrial-grade AI in production. The core principle of "finding the pulse" is simple: humans and LLMs have different strengths. The parts humans are bad at, but LLMs excel at should be outsourced.

A practical division of labor:

• LLM Fit: Rules are clear, inputs/outputs are defined, tasks are decomposable, verifiable, and reversible.
• LLM Misfit: Rules change daily, context is fluid, risk appetite shifts, judgment relies on intuition, and long-tail decisions require accountability.

The question you are really asking is: Does this task rely on "smartness" or on "process and standardization"?

Three Screening Questions

Use these to filter tasks. They do not all need to be "yes", but the more you satisfy, the higher the success rate.

1. Can the acceptance criteria be written in one sentence? "Extract invoice data with 99% accuracy" is verifiable. "Does this analysis look solid?" is not.
2. Can failure be safely rolled back? If yes, the system can be given more autonomy and has a greater chance to yield value. If no, you need a Human-in-the-Loop (HITL) for final review. This increases cost, making it less ideal for pure automation, but if the business value is high enough, it is still worth doing.
3. Can it be broken into small, verifiable steps? This determines if you are building "controlled automation" or letting a model "improvise in an open world". For enterprise scenarios, always choose the former.

Two Examples to Build Intuition

• Receipt Recognition (Good Fit): You photograph a receipt, and the system extracts structured fields. This is not "intelligence"; it is repetitive labor. The acceptance standard is clear, and errors are easily correctable.
• Financial Analyst Workflow (Mixed Fit): The true value of an analyst is not reading documents, but non-standard judgment (spotting anomalies, adjusting risk conservatism, making the final call). These judgments are rarely documented, so the model sees the input and the conclusion but misses the messy reasoning in between. The realistic approach is to unbundle the chain: let AI handle information extraction, initial screening, and comparison, while humans retain the final risk assessment and accountability.

Summary: In the current phase, the goal is not "omnipotence" but "stable delivery". Rather than chasing a universal agent that improvises everywhere, build a workflow that runs reliably (verifiable, reversible, and auditable). This is the prerequisite for enterprise production.

Taking It Further: Humans Are Not Firefighters, They Are SOP Writers

The companies that will pull ahead are not those who can "put out fires" on long-tail problems, but those who can "distill the firefighting experience".

The ideal closed loop is:

1. A human solves a long-tail problem once.
2. The process is crystallized into an SOP, template, a few-shot example, or a validation rule.
3. The next time, this "unique" problem becomes a "routine" problem.
4. The routine problem is handed off to AI automation.

Humans constantly flatten the long tail, expanding the zone of routine automation. This is how productivity compounds like a snowball.

Layer 2: Context Engineering (Make the System Run)

Once you have selected the right vertical and defined the task, the next step is engineering. In the zero-to-one phase, the critical factor is not teaching the model to be smarter, but controlling what it sees, what constraints it operates under, and what ground truth it relies on every time it acts.

This is the core problem Context Engineering solves.

The Eye of the Model

In our model layer discussion, we noted that LLMs struggle with enterprise reality: rules change, states shift, and responsibilities evolve. LLMs cannot update their worldview in real-time.

Context Engineering ensures that every time the model acts, it does so within the correct context. We are not modifying the model's brain; we are modifying the world it sees. This is not about "prompting better". It is the only engineering answer that pulls the system back onto a controllable track until AGI arrives.

The Spectrum of Autonomy

A common mistake is treating the "AI Agent" as a universal solution. The better question is not "Should I build an agent?" but "How agentic should my system be?"

Think of it as a spectrum:

• Absolute Reliability: Trading desks and compliance chains need zero ambiguity. These require hard-coded workflows.
• Exploration: Research and insight generation warrant giving the model a looser rein.

Many "model failures" are actually instances of being Underfed or Misfed. At critical decision points, if the model lacks key background information, it fills the gap with confident hallucination. The goal is to control its eyes: ensure it sees exactly what it should.

Retrieval as Backbone, Not Search Bar

In an enterprise, retrieval determines whether the facts the model sees are current, compliant, and authorized. You are not asking "Find relevant documents". You are asking "Find policies applicable to this region and product line, effective today, and only return what I am authorized to see".

Ambiguity must be locked down before retrieval. A letter like "U" can mean "User" or "Unity Software" depending on the task. If the system does not resolve this upfront, all subsequent reasoning is built on sand.

The winning system is not the one that mimics a human, but the one that is more agentic: it knows when to delegate, when to restrict, and locks the output into a governable track.

Case Study: Four Traps We Hit in AI Search

Last year, we built an enterprise AI search system for a financial platform client. We were essentially using engineering to turn "context" into replicable, governable infrastructure.

The core challenge was a massive disconnect: the "literal meaning" the system understood vs. the "implicit logic" in industry experts' heads.

Here are four specific traps we encountered and how we engineered around them (For a deeper technical dive, you can read our full case study):

Entity Ambiguity (When "U" is just a letter)

• Trap: Searching "Client's view on U" yielded nothing because the model saw "U" as "User" or "University". To a trader, "U" is deterministically Unity Software, not a probabilistic guess.
• Fix: Pre-retrieval Hook. We injected a domain dictionary. A rule triggers before retrieval: U -> Unity Software. We collapsed a probability problem into a certainty problem before the model ever touched it.

The "Distance Trap" (Missing the Alpha)

• Trap: Searching "Is U a buy?" surfaced gaming revenue (semantic match) but missed "Industrial Digital Twin" (the real growth story). Vector search favors semantic closeness, pushing the high-value but semantically distant "alpha" out of view.
• Fix: Cascading Rewrite. We mapped "Unity" to a concept cluster: {Game Engine, Digital Twin, Metaverse}. The system searches the term and its logical implications simultaneously, eliminating the blind spot.

The Structured Data Blindspot

• Trap: Searching "Recent NVIDIA transactions" failed because transaction logs are structured data, not semantic text. Using semantic search here is like reciting poetry to a calculator.
• Fix: Text-to-Query. We bypassed embedding search. The system detects "data intent", calls an API (get_transactions), and translates the JSON result back into natural language.

Intent Mismatch (Doing vs. Finding)

• Trap: Searching "How to subscribe" returned articles when the user wanted to act.
• Fix: Intent Router. A routing layer classifies the input. Informational? Go to Vector DB. Navigational? Redirect to the subscription page. The search bar becomes a "Do-What-I-Mean" command line.

We faced a dozen more issues like these. Building the scaffold is easy; making it land in production requires engineering depth far exceeding the initial setup.

The "Dispatch System" for Uncertainty

Context Engineering is not making the model "speak better"; it is turning a task into an executable production process where every step, resource, and risk is predefined.

Humans deliver reliably because we have an internal "dispatch system": we tighten up when anxious (high penalty for error) and explore when curious (low penalty). LLMs lack this layer. They just predict the next token.

Until AGI arrives, we cannot rely on the model to "become a super-individual". We must engineer this "dispatch system" externally and bake it into the workflow: cage the uncertainty to make the output controllable and governable.

Think of it as... Hiring a teacher. The "AI Agent" approach is like hiring a genius, dumping all the textbooks on their desk, and saying, "Make the students succeed", then walking away. You are betting everything on their individual brilliance. The "Agentic Workflow" approach is building a proven curriculum. You define the process: Entrance exam -> Sorting -> Targeted lessons -> Evaluation. You then assign specific models to specific steps (one writes the exam, one grades it, one generates feedback). Even if no single model is a "genius", the system guarantees the educational outcome because the process is engineered for success.

Layer 3: The GenAI Data Flywheel (From 1 to 100)

We all understand the classic data flywheel.

At the dawn of the internet, every company did the same thing: built a webpage. Just having a site meant you were "online". But a small subset of companies (like Google and Amazon) did something extra: they aggressively collected user behavioral data. Data tells product managers: users hover over this button but hesitate to click, so the design is flawed (fix it). Users search for a product that does not exist, signaling new demand (build it).

If you buy a plaid shirt on Amazon, the algorithm infers you might be a programmer; next time, before you even search, it pushes mechanical keyboards and graphics cards to your homepage.

This is the flywheel:

• Data improves the product experience (better recommendations, smoother design).
• Better experience attracts more users (higher retention, better reputation).
• More users generate more data, which further improves the product. This cycle spins faster and faster, leaving competitors behind.

The Rules Have Changed for the LLM Era

Knowing "what you did" is no longer enough. GenAI is not doing recommendation; it is doing generation. It is not guessing what you will buy; it is attempting to think and work like an expert.

Therefore, the fuel for the GenAI era is not behavioral data alone, but decision-trace data. This records what happened end-to-end, including the intermediate steps, corrections, and the feedback signals that show what was accepted, rejected, safe, or risky.

In 2026, which companies will build the new flywheel?

It will be those who can capture the full end-to-end trace of solving a specific vertical problem, plus the feedback that separates good from bad. Sometimes that requires translating expert intuition into explicit rules, but often it is enough to reliably record the steps, the edits, and the outcomes.

To explain this clearly, we must understand the concept of the "Data Ladder".

The Data Ladder

I spoke with a financial analyst whose husband is a programmer. He believes "AI will soon replace all jobs". But as a financial analyst, her own experience is starkly different: she feels AI is not helping much.

Why is there such a massive "temperature difference" in perception? The root cause is that the information density in the programming world is on a completely different magnitude than in the financial world.

Data in the programming world possesses a perfect "invisible ladder".

A programmer's world records almost every step. When writing code, every commit contains a granular ledger:

• This line was deleted.
• That line was rewritten.
• Two new lines were added to bypass a previous bug. Every acceptance and every rejection leaves a trace.

For human developers, this is just daily collaboration. For a model, it is a crystal-clear learning trajectory. AI does not just see the "final good code". It sees:

• What the immature version looked like.
• Why it was rejected.
• How the better version evolved.
• The reasoning humans used to change A to B.

This is the "invisible ladder": moving from novice to expert is not a single leap but thousands of tiny steps. Each step is only slightly harder than the last, and every step is documented.

Another critical factor: rewards in the programming world are dense and unambiguous.

• Does the code compile? Reward.
• Do the unit tests pass? Reward.
• Did it deploy without errors or performance regression? Another reward.

These signals are incredibly friendly to models. They are not vague feelings of "this seems okay". They are hard binary signals: True/False, Pass/Fail. This is Frequent, Unambiguous Reward.

The Financial Analyst's "Black Box Disaster"

Now consider a financial analyst's workflow. What does your work data look like?

• Input: Hundreds of earnings reports, call transcripts, and news articles.
• Output: A final "Buy" report.

What happens in the middle? It is a black box. Why did the analyst read ten reports but discard seven? Was it because management's tone was evasive? Because a line in the cash flow statement "looked off"? Because it reminded them of a company that imploded five years ago?

These critical moments of "negation", "doubt", and "trade-off" flash through the analyst's brain and vanish. They are never recorded.

The model sees none of this. It is like a student who sees the exam question and the answer key but never sees the teacher's scratchpad. It has no idea how the derivation happened. Consequently, the reports it generates have the "form" but not the "spirit" (perfect formatting, terrible logic, written like someone who has never done the job).

Why is "Data Completeness" so critical? Recall our model layer discussion:

• Pre-training teaches the model world knowledge.
• Post-training teaches the model how to apply that knowledge to specific tasks.

If your business line lacks "critical process data", post-training cannot fix it. It is like teaching exam techniques to a student who skipped class; it is just a façade.

Every problem is backed by a tangled web of knowledge points (imagine a connected knowledge graph). When you ask an LLM a question, its job is to find relevant knowledge, reorganize it, and output it. If the data recording the human reasoning process for a problem is incomplete, the knowledge graph for that problem has massive gaps. The model cannot distinguish valid signals from noise. The result is massive noise treated as signal, rendering the final answer useless.

What Did Tesla Get Right?

This explains why autonomous driving, like coding, is one of AI's most successful implementations: Data Integrity.

The entire journey from A to B is recorded. What was your speed? Following distance? Lighting conditions? Road surface? What action did you take? Where did you pass safely? Where was it a near-miss? Where did a crash actually occur? Everything is recorded.

Take a classic example: Tesla sees a car parked on the roadside with its wheels turned sharply outward. It slows down preemptively. This is a powerful prior signal: if a parked car is about to merge, its wheels are often turned left. It is not just "parked"; it is "potentially active".

As human drivers, we often react this way intuitively, even if we cannot articulate, "I slowed down because I saw the wheel angle".

This is the value of Data Integrity. It turns the intuition of a veteran driver into a trainable, reproducible signal.

The Flip Side: What Happens Without Integrity? Imagine if the system only recorded two things: "Did you get from A to B?" and "Did you crash?" but ignored the entire process in between.

The model would be trapped in a state of confusion. It knows the result, but not the cause. It sees thousands of samples: sometimes you crashed, sometimes you didn't. But it misses the critical micro-details in the seconds before the event (wheel angle, relative speed changes, the tap on the brakes, the slight drift of the other car). Without those signals, the model's freedom to hallucinate the cause is too wide.

This mirrors the "Black Box Disaster" in financial analysis. If you only give the model inputs (earnings reports) and outputs (Buy/Sell) without the intermediate judgment process, it will generate a report that sounds authoritative but fails when it matters. It never learned the "process signals" that determine life or death.

In the LLM era, whether you can make these process signals structured and traceable determines whether you can build a system that is stable and controllable.

How to Build a "Data Flywheel" in the GenAI Era

Since data integrity is critical, the question becomes: Which enterprises can actually spin up this flywheel? And how?

First, accept the brutal reality: Not every industry deserves a flywheel. If your business cannot naturally record the "judgment process", the flywheel will not spin.

I have summarized three hard thresholds. Meet all three, and the flywheel spins itself. Meet two, and it spins with effort. Meet zero or one, and do not force it.

Trait 1: Ground Truth or Strong Consensus

In short: You must be able to answer "What is good?" The model needs to know when to be rewarded and when to be punished to converge.

• Positive Example (Coding/Math): Code compiles = correct. Code fails = incorrect.
• Positive Example (Customer Service): There is no single correct answer, but there is a strong consensus on "what was handled well". If you play a recording of an angry call to three supervisors, they will align quickly: Did the customer calm down? Was the issue resolved? Was a secondary complaint avoided? Experienced people rarely disagree on these dimensions.
• Negative Example (Brand Creative/Art): You say it is sophisticated; I say it is tacky. Without a unified standard, AI cannot converge, even with training.

Trait 2: Digital Native Workflow

In short, does the critical decision process naturally happen inside the system where it leaves a trace? Or is the most valuable part happening in brains and over dinner? AI eats "process logs", not just results. If the process is not in the system, there is no trainable data asset.

• Positive Example (AI Customer Service/Legal Search): Every reply, every database query, every operation step happens inside the CRM. These traces are natural, complete "Chains of Thought (CoT)". You do not need to force collection; they are already there.
• Negative Example (Gut-Feeling Expert Work): In many industries, the most valuable step is an expert glancing at something and saying, "That looks off". The problem is this "off" feeling is ten years of experience compressed into a one-second intuition. If you force the expert to write an essay explaining "why I feel it is off" while they work, you are murdering their productivity. Without transforming this workflow, the problem is not "insufficient data" but "data cannot be generated at the source".

Trait 3: Fast & Dense Feedback Loop

In short, a flywheel is called a flywheel because it spins. The faster it spins, the stronger the compounding effect. In the real world, "Concept Drift" and "Data Drift" happen constantly. The system needs continuous feedback to stay relevant.

• Positive Example (AI Coding/Translation): I write a comment, AI gives code. I dislike it, I change it immediately, I run it. This feedback loop is measured in seconds. It spins thousands of times a day.
• Negative Example (Long-Cycle Decisions): You make a judgment today, and you know the result three years later. By then, the world has changed so much that you cannot even tell if your judgment was wrong or if the macro environment shifted. The flywheel takes years to complete one revolution (in engineering terms, it effectively does not move).

The Brutal Reality for Financial Analysis

If we apply these three standards to the "Financial Analysis" industry, we face a cruel reality: we perfectly miss every single correct answer.

Trait 1: Is there consensus on standards? (No Strong Consensus)

• Not only is there no consensus, but the entire market is built on disagreement. Without disagreement, there is no trade. I see "bad news priced in"; you see "falling knife". We call each other idiots and trade. Even returns are a messy standard: If it drops short-term, you say "I'm long-term". If it rises long-term, you say, "I was right", and I say, "That was just macro liquidity". If we cannot define "good result", how do we know when to reward and when to punish the system?

Trait 2: Is the process naturally digital? (Not Digital Native)

• Absolutely not. The core value of analysis is the silent, internal filtering of information. An expert reads a report and their brain silently flags: Credible. Evasive. Suspicious number. Management is spinning. This filtering is the product of years of experience (recognizing patterns from old fraud cases or sensing margin anomalies), but it happens entirely inside the neural pathways of the analyst. The digital system only captures the final "Buy" or "Sell". The critical reasoning (the "why") is never logged. If I asked you to manually type out every fleeting suspicion while you read, the friction would destroy your workflow.

Trait 3: Is feedback fast and dense? (Slow & Sparse Feedback)

• Even worse. Investment feedback is slow, noisy, and hard to attribute. Was the bullish report correct? You might know in months or years. Even then, can you attribute the success to the specific logic you used back then? A flywheel that turns once every few years cannot form a continuous iteration rhythm in an organization.

Conclusion: You cannot build a data flywheel for investment analysis.

Find Your "Gold Mine"

In 2026, the standard for measuring a company's GenAI potential is not how many users you have, nor how many terabytes of logs you store. It is whether you have the ability to record the complete process of solving a specific problem cleanly and completely, and whether you can form a compounding closed loop.

Competitors can buy the same models and the same GPUs. But they cannot buy your ten thousand records of ‘how to rewrite technical jargon into human language.’ That decision-trace data (attempts, edits, approvals, and outcomes) is the true moat in the 1-to-100 phase.

Who Is Sitting on a Gold Mine?

There is another category of fortunate enterprises. Just like the programming sector, during the traditional internet era, they inadvertently accumulated high-quality, complete data simply for the sake of collaboration (like git commits and PR reviews).

They are sitting on a gold mine, ready for an explosion at any moment. They just might not realize it yet. You need to ask yourself: Are you sitting on such a mine without knowing it?

To summarize: In the past decade, the internet built barriers based on "what you did", giving rise to giants like Google and Amazon. In the next decade, vertical industries will build barriers based on how work actually gets done, meaning the trace of decisions and the feedback loops that turn outcomes into repeatable processes.

Conclusion

The biggest incremental gain in 2025 was not the chatbot, but the birth of the "Software Factory". AI Coding transformed long-tail needs that previously "could not afford software" into "disposable scripts" that anyone can write. The true driver behind this was the unique data integrity of the programming field: from commits to PR reviews, every judgment, modification, and comment was fully recorded, forming an "invisible ladder" from zero to one for solving specific problems.

In 2026, models enter a plateau, and the engineering dividend begins to pay out. The true moat is the engineering capability to make systems stable, accurate, and controllable. This year, the core proposition for the application layer is singular: admit the model is imperfect, and use engineering to bridge the last mile.

Under this proposition, we break down a three-layer methodology:

• Layer 1: Task Selection. Find the pulse of the LLM and distinguish between "relying on smarts" and "relying on process". Can the acceptance criteria be stated in one sentence? Is failure safely reversible? Can it be broken into verifiable steps? These questions filter for scenarios where AI can deliver reliably.
• Layer 2: Context Engineering. This controls the world the model sees, caging uncertainty to ensure predictability.
• Layer 3: Data Flywheel. This turns decision-trace data (process plus feedback) into a moat that makes the system better with every use.