Here is the uncomfortable truth they are papering over: you are a price taker. You always were. You always will be.

The cost curve belongs to someone else

Token costs have fallen dramatically and will continue to fall. The frontier models that cost a small fortune per million tokens in 2023 are already being undercut by distilled successors. The providers are in a race with no finish line, and their pricing reflects infrastructure economics you have zero visibility into. What costs you ten units today might cost one unit in eighteen months. Or it might not.

A new modality, a new architecture, a regulatory burden, a compute shortage, none of these are in your model. You don’t own the model, it now owns you.

And yet here you are, coupling your retrieval logic to your summarisation logic to your classification logic all stuffed into one sprawling system prompt, because you convinced yourself you were being economical.

This is the architectural equivalent of designing a building around the spot price of steel on the day you drew the plans. Except at least steel has a futures market. Token pricing has a blog post.

What you actually destroyed

When you packed everything into a single call to save tokens, you also threw away testability. You threw away the ability to swap providers. You made debugging a matter of staring at a 4,000-token prompt and wondering which bit is lying to you. You made prompt iteration a full-stack event. You made your system fragile in direct proportion to how clever you were.

Separation of concerns is not a nice-to-have. It is the foundational discipline that made software engineering a profession rather than a craft. It exists because concerns change at different rates, for different reasons, controlled by different people. That principle does not dissolve because the runtime happens to charge by the token.

The cost you are not counting

Token costs are visible. They are on your invoice. They feel controllable, because they respond to effort you compress the prompt, the number goes down, dopamine is released.

The cost of architectural coupling is invisible until it is not. It lives in the engineer-hours spent making a change that should have been simple. In the incident where one mutated prompt broke three downstream features simultaneously. In the moment you try to switch models and discover that your prompts are load-bearing walls.

These costs don’t appear on an invoice.

They appear on a Tuesday afternoon, three months from now, when the person who wrote the original prompt is no longer at the company.

What to do instead

Design your system as if token costs were zero and you were optimising for clarity, testability, and modularity. Then profile. Then optimise the calls that actually hurt, with evidence.

Separate prompts for separate concerns. One job per call, where possible. Named, versioned, independently testable. If a prompt is too expensive, you can cache it, compress it, or replace the model underneath it because you kept it separate. If you didn’t, you can’t do any of those things cleanly.

The providers will adjust their pricing. They will change their context window limits, their rate limits, their model availability.

You are at their mercy and their pricing.

The spaghetti of services relying on core models. You create front ends on Loveable, that uses Claude’s Opus 4.6 model, which they don’t own.

The only hedge you have against all of that is a system with clean seams.

If not then your startup is built on a bet where the odds are already against you.

Share

This pitch has been made, with minor variations, to manufacturing firms, hospital systems, city planners, energy companies, and militaries. The market analysts have assigned it a number with nine zeroes. The consulting firms have built practices around it. The vendors have given it a name that implies science fiction levels of fidelity: a twin. Not a model, not a simulation, not a dashboard. A twin. A perfect double.

There is a word for what most deployed digital twins actually are. That word is model. And models, as any engineer who has spent time with them knows, are wrong. The question is not whether your model is wrong. It is how wrong, in which directions, and whether anyone is accounting for that when they make decisions based on it.

The digital twin industry has largely decided not to engage with this question. That decision is costing buyers real money for capabilities that are, in the precise technical sense, not what was advertised.

What a digital twin actually is

Ask ten vendors what a digital twin is and you will get ten answers. This is not because the concept is subtle. It is because the term has been deliberately kept vague enough to apply to almost anything, which maximises the addressable market.

The original definition, from Grieves at the University of Michigan in 2002, was specific: a digital twin is a virtual representation of a physical object or system, connected to that object via data, updated continuously, and used to understand and predict the behaviour of the physical counterpart. The connection and the continuity were load-bearing. Without them, you have a model. With them, you have something potentially more useful.

What the market has since defined as a digital twin includes: static 3D CAD models with a live dashboard bolted on. BIM files for buildings that were last updated at construction. Simulation models that run periodically, not continuously. Dashboards that aggregate sensor data into visualisations without any underlying physics model at all. In several high-profile cases, what a vendor called a digital twin was, on inspection, a database with a 3D viewer.

The definitional collapse is not accidental. Once you allow “digital representation of a physical thing” to count as a twin, the installed base explodes overnight. Every CAD file ever created becomes a digital twin. Every BMS system in every office building becomes a digital twin. The market is large because the definition has been made large to fit it.

The actual thing, a continuously updated, data-connected representation that meaningfully tracks a physical system is much rarer, much harder, and much more expensive than the market narrative suggests.

The model drift problem

A digital twin is only useful if it reflects the current state of its physical counterpart. The moment it diverges, it stops being a twin and starts being a historical record. Keeping it synchronised requires continuous data ingestion, model updating, and crucially, a mechanism for detecting and correcting when the digital and physical have come apart.

This is a Kalman filter problem. The Kalman filter is the standard tool for maintaining a running estimate of a system’s state given noisy measurements. It has two steps: predict the next state using the model, then update that prediction using the actual measurement. The update weight -- how much you trust the measurement versus the model -- is determined by the relative uncertainty of each.

import numpy as np

def kalman_update(x_est, P_est, measurement, H, R, F, Q):
    """
    One step of a Kalman filter.

    x_est:       current state estimate           (n,)
    P_est:       current state covariance          (n, n)
    measurement: observed sensor reading           (m,)
    H:           observation matrix                (m, n)  maps state to measurement space
    R:           measurement noise covariance      (m, m)  how much we trust sensors
    F:           state transition matrix           (n, n)  the physics model
    Q:           process noise covariance          (n, n)  how much the model drifts

    The critical ratio: Q / R
    High Q, low R: trust the sensors, distrust the model  (model is bad)
    Low Q, high R: trust the model, distrust the sensors  (sensors are bad)
    """

    # Predict step: where does the model say we'll be?
    x_pred = F @ x_est
    P_pred = F @ P_est @ F.T + Q

    # Kalman gain: how much to correct toward the measurement
    S = H @ P_pred @ H.T + R          # innovation covariance
    K = P_pred @ H.T @ np.linalg.inv(S)

    # Update step: correct the prediction with the measurement
    innovation = measurement - H @ x_pred    # how wrong was the model?
    x_updated  = x_pred + K @ innovation
    P_updated  = (np.eye(len(x_est)) - K @ H) @ P_pred

    return x_updated, P_updated, innovation

# Concrete example: tracking a turbine bearing temperature
# State: [temperature, rate_of_change]
# Measurement: raw thermocouple reading

n_steps = 100
np.random.seed(42)

# True system: temperature rising slowly with noise
true_temp  = 80.0
true_state = np.array([true_temp, 0.1])   # [temp, rate]

# Model parameters (what the digital twin thinks the physics is)
F = np.array([[1.0, 1.0],   # temp += rate * dt
              [0.0, 1.0]])  # rate stays constant (simplified)

H = np.array([[1.0, 0.0]])  # we only measure temperature, not rate

# The critical question: how wrong is the model?
Q_good  = np.diag([0.1, 0.01])   # model is trusted: low process noise
Q_bad   = np.diag([2.0, 0.5])    # model is not trusted: high process noise

R = np.array([[1.5]])              # sensor noise covariance (thermocouples are noisy)

# Run both scenarios
x_est_good = np.array([80.0, 0.0])
x_est_bad  = np.array([80.0, 0.0])
P           = np.eye(2)

drift_good, drift_bad = [], []

for step in range(n_steps):
    # Simulate physical system drifting from model assumptions
    true_state[1] += 0.005 * step / n_steps   # rate is actually accelerating
    true_state[0] += true_state[1]
    measurement = np.array([true_state[0] + np.random.randn() * 1.2])

    x_est_good, P, innov_good = kalman_update(
        x_est_good, P, measurement, H, R, F, Q_good)
    x_est_bad,  P, innov_bad  = kalman_update(
        x_est_bad,  P, measurement, H, R, F, Q_bad)

    drift_good.append(abs(x_est_good[0] - true_state[0]))
    drift_bad.append(abs(x_est_bad[0]  - true_state[0]))

print(f"After {n_steps} steps:")
print(f"  Twin with trusted (but wrong) model -- mean drift: {np.mean(drift_good):.2f} deg C")
print(f"  Twin with distrusted model          -- mean drift: {np.mean(drift_bad):.2f} deg C")
print(f"")
print(f"  The twin that trusted its model drifted {np.mean(drift_good)/np.mean(drift_bad):.1f}x more.")
print(f"  This is the core problem: vendors tune Q to make demos look good.")
print(f"  In production, the model is always wrong in ways the demo didn't include.")

# Typical output:
# After 100 steps:
#   Twin with trusted (but wrong) model -- mean drift: 4.73 deg C
#   Twin with distrusted model          -- mean drift: 1.21 deg C
#   The twin that trusted its model drifted 3.9x more.

The Q matrix is where digital twin projects go to die. Q encodes how much you trust your own physics model. Set it too low, we trust the model too much, and when the physical system drifts from the model’s assumptions, the twin lags behind and eventually diverges. Set it too high, distrust the model, and you are essentially just filtering the sensor data, and there is no need for the physics model at all.

Most vendors set Q in their demos by tuning it to match their demo dataset. In production, the physical system behaves differently than the demo. The model is wrong in new directions. The twin drifts. The maintenance team stops looking at the twin dashboard because it is wrong too often to trust. This is not a hypothetical. It is the modal outcome of digital twin deployments in discrete manufacturing.

The sensor data problem nobody prices in

The Kalman filter above assumes you have measurements. Good measurements, arriving on time, from sensors that are working. This assumption is doing a remarkable amount of heavy lifting in every digital twin business case I have ever seen.

def assess_sensor_quality(sensor_readings, expected_range, max_gap_seconds):
    """
    The data quality audit that should precede every digital twin business case.
    Almost never actually done before signing the contract.
    """
    readings = np.array(sensor_readings)
    timestamps = readings[:, 0]
    values     = readings[:, 1]

    # 1. Completeness: what fraction of expected readings actually arrived?
    gaps          = np.diff(timestamps)
    missing_pct   = (gaps[gaps > max_gap_seconds] / max_gap_seconds - 1).sum()
    completeness  = max(0, 1 - missing_pct / len(gaps))

    # 2. Range validity: sensors fail in characteristic ways
    in_range      = ((values >= expected_range[0]) & (values <= expected_range[1]))
    range_valid   = in_range.mean()

    # 3. Stuck sensor detection: a common failure mode where sensor reads same value
    diffs         = np.diff(values)
    stuck_windows = (np.abs(diffs) < 0.001).sum()
    stuck_pct     = stuck_windows / len(diffs)

    # 4. Latency: is the data arriving fast enough to be useful?
    # For a fast-moving system, 30-second old data is not "real time"
    median_latency = np.median(np.diff(timestamps))

    print(f"Sensor data quality report:")
    print(f"  Completeness:         {completeness:.1%}")
    print(f"  Range validity:       {range_valid:.1%}")
    print(f"  Stuck sensor windows: {stuck_pct:.1%} of readings")
    print(f"  Median update rate:   {median_latency:.1f}s")
    print(f"")

    if completeness < 0.95:
        print(f"  WARNING: {(1-completeness):.1%} of readings missing.")
        print(f"  The twin will interpolate or hold-last-value.")
        print(f"  Neither is the physical system. It is a guess.")

    if stuck_pct > 0.02:
        print(f"  WARNING: {stuck_pct:.1%} of readings look stuck.")
        print(f"  Stuck sensors read healthy while the system degrades.")
        print(f"  The twin will show green. The asset is not green.")

    total_quality = completeness * range_valid * (1 - stuck_pct)
    print(f"  Combined data quality index: {total_quality:.1%}")
    print(f"  Your twin is {total_quality:.1%} of a twin. The rest is fiction.")
    return total_quality

Real industrial sensor estates are not what the demo shows. They are accumulated over years, from multiple vendors, using different protocols, with varying calibration histories. Sensors fail silently: they stick at a value, they drift slowly, they develop intermittent faults that look like signal noise. The PLC that aggregates readings was not designed for the latency requirements of a real-time digital twin. The historian database that stores readings was set up to log at one-minute intervals, and nobody budgeted for upgrading it.

In 2017 a study of industrial IoT deployments by Cisco found that 74% of IoT projects fail or stall. The leading cause is not the software. It is data: missing data, bad data, data that arrives too slowly, data from sensors that have not been calibrated in three years. The digital twin sits downstream of all of this. It gets the data last, after it has been through the PLC, the historian, the network, and the middleware layer that converts it from the proprietary format the sensor vendor uses. By the time the twin sees a reading, it can be seconds to minutes old.

For a slow-moving system like a building, this is fine. For a fast-moving system like a turbine, a compressor, or a robot cell, it is not fine. “Real time” in most digital twin deployments means “real time relative to the historian update frequency,” which is not the same thing as real time.

The model fidelity trap

Suppose you solve the data problem. Sensors are good, data is clean, latency is acceptable. Now you need the physics model, the part that turns sensor readings into predictions about future states and failure modes. This is the part the vendors call “the digital twin” in their marketing materials, because it is the part that justifies the premium pricing.

Physics models exist on a spectrum from empirical (curve-fit to historical data) to first-principles (derived from governing equations). Both have problems.

def model_fidelity_tradeoffs():
    """
    The three model types used in digital twins, and what each actually buys you.
    """

    models = {
        "Empirical (data-driven)": {
            "build_cost":       "Low -- fit a model to historical data",
            "physics_required": "None",
            "extrapolation":    "POOR -- fails outside training distribution",
            "calibration":      "Automatic, but retraining needed as system ages",
            "failure_modes":    "Confidently wrong on novel operating conditions",
            "honest_name":      "Glorified regression",
        },
        "Physics-based (first principles)": {
            "build_cost":       "Very high -- requires domain experts, months of work",
            "physics_required": "Complete governing equations",
            "extrapolation":    "Good within physical assumptions",
            "calibration":      "Manual, expensive, degrades as system wears",
            "failure_modes":    "Assumes ideal conditions that do not exist in production",
            "honest_name":      "Simulation that was calibrated once and then drifted",
        },
        "Hybrid": {
            "build_cost":       "Highest -- requires both expertise types",
            "physics_required": "Partial",
            "extrapolation":    "Moderate",
            "calibration":      "Ongoing, requires both data and engineering review",
            "failure_modes":    "Inherits worst-case failure modes of both approaches",
            "honest_name":      "What vendors promise; rarely what is delivered",
        },
    }

    for model_type, props in models.items():
        print(f"\n{model_type}")
        print(f"  Honest name:      {props['honest_name']}")
        print(f"  Extrapolation:    {props['extrapolation']}")
        print(f"  Primary failure:  {props['failure_modes']}")

    print(f"""
The trap:
  Vendors sell the hybrid vision.
  They deliver empirical models because they are fast and cheap to build.
  Empirical models fail outside their training distribution.
  Industrial systems constantly operate outside their historical distribution
  (new operators, new products, new wear patterns, new ambient conditions).
  The twin fails precisely when you need it most: novel conditions.
""")

model_fidelity_tradeoffs()

The first-principles physics model has its own problem: it was calibrated on a new machine, or a reference machine in a laboratory. The machine you actually have is not new. It has worn components, fouled heat exchangers, slightly misaligned shafts, and operating patterns that were not in the original design envelope. The physics model describes a platonic version of your asset. Your asset is not that.

Calibrating the model to your actual asset is a significant piece of engineering work, and it degrades over time as the asset changes. Most digital twin projects include an initial calibration. Almost none include a systematic recalibration process. Within 12 to 24 months, the model has drifted from the physical asset in ways that are not visible to the dashboard user.

This is the failure mode that never appears in case studies. Nobody publishes a paper titled “Our digital twin was accurate for 18 months and then quietly became useless.” The vendors move on to the next sale. The operations team keeps the dashboard on the wall because removing it would require admitting the project did not work.

What “predictive maintenance” actually predicts

The headline use case for digital twins in industrial settings is predictive maintenance: catch failures before they happen, reduce unplanned downtime, extend asset life. This is real. Condition monitoring and predictive maintenance genuinely work when implemented well.

The question is whether you need a digital twin to do it.

import numpy as np
from scipy import stats

def predictive_maintenance_reality_check(
    sensor_history,
    failure_events,
    twin_predictions,
    threshold=0.7
):
    """
    Evaluate what a digital twin's predictive maintenance is actually doing
    versus what simpler approaches would achieve.
    """

    sensor_history   = np.array(sensor_history)
    failure_events   = np.array(failure_events)    # 1 = failure in next 30 days
    twin_predictions = np.array(twin_predictions)  # model's failure probability

    # What the digital twin vendor reports: precision and recall at threshold
    predicted_positive = twin_predictions >= threshold
    true_positive      = (predicted_positive & (failure_events == 1)).sum()
    false_positive     = (predicted_positive & (failure_events == 0)).sum()
    false_negative     = (~predicted_positive & (failure_events == 1)).sum()

    twin_precision = true_positive / (true_positive + false_positive + 1e-9)
    twin_recall    = true_positive / (true_positive + false_negative + 1e-9)

    # What a simple statistical rule gets you: flag when reading exceeds 2 std devs
    mu, sigma         = sensor_history.mean(), sensor_history.std()
    simple_flag       = sensor_history > (mu + 2 * sigma)
    tp_simple         = (simple_flag & (failure_events == 1)).sum()
    fp_simple         = (simple_flag & (failure_events == 0)).sum()
    fn_simple         = (~simple_flag & (failure_events == 1)).sum()

    simple_precision  = tp_simple / (tp_simple + fp_simple + 1e-9)
    simple_recall     = tp_simple / (tp_simple + fn_simple + 1e-9)

    print(f"Predictive maintenance comparison:")
    print(f"{'Method':<30} {'Precision':>10} {'Recall':>10}")
    print("-" * 52)
    print(f"{'Digital twin':< 30} {twin_precision:>10.1%} {twin_recall:>10.1%}")
    print(f"{'Simple statistical rule':< 30} {simple_precision:>10.1%} {simple_recall:>10.1%}")
    print(f"")
    print(f"  The question to ask your vendor:")
    print(f"  What is the marginal improvement over a simple threshold rule?")
    print(f"  And does that margin justify the implementation and maintenance cost?")
    print(f"  In most published evaluations, the margin is single-digit percentage points.")
    print(f"  The cost difference is an order of magnitude.")

The published literature on digital twin predictive maintenance is full of precision and recall numbers that look impressive in isolation. They are rarely shown against the correct baseline, which is: what does a simple statistical threshold on the same sensor data achieve? In most cases, the answer is within a few percentage points of the twin’s performance. In some cases, the simple rule beats it.

This matters because the simple rule costs almost nothing to implement and maintain. The digital twin costs millions to build, requires specialist skills to maintain, and degrades silently when the underlying model drifts. The ROI case, which almost always computes the benefit of predictive maintenance against the cost of unplanned downtime, uses the twin’s performance numbers in the numerator. It rarely subtracts the cost of the wrong alerts, the staff time spent investigating false positives, or the gradual erosion of trust in the system that leads operations teams to ignore it.

The coordination problem nobody mentions

There is a failure mode that is not technical at all, and it is the most common reason digital twin projects deliver nothing.

A digital twin produces predictions. Those predictions are only valuable if someone acts on them. Acting on them requires: a workflow that delivers the prediction to the right person, authority to act on the prediction, spare parts if the prediction calls for maintenance, maintenance staff with the right skills, a maintenance window that does not conflict with production commitments, and a feedback loop that records whether the action was taken and whether it was correct.

None of this is in scope for the typical digital twin implementation. The vendor builds the model, integrates the data, deploys the dashboard, runs the pilot, shows the predictions are accurate, and hands over. The operational changes required to act on those predictions are left as an exercise for the buyer.

The result is a dashboard that accurately predicts failures that nobody has the workflow to prevent. The twin is technically working. The benefit is zero.

This is not a criticism of any specific vendor. It is a structural feature of how the market is organised. The digital twin is a software product. The operational transformation required to extract value from it is a change management programme. They are priced and sold separately, delivered by different teams, and the connection between them is treated as the buyer’s problem.

What you should actually buy

None of this means that the underlying technologies are useless. Sensor networks, condition monitoring, physics simulation, and state estimation are all valuable. They have been valuable for decades, deployed under less glamorous names: SCADA, historian systems, FEA models, Kalman filters, process control. They work when implemented with realistic expectations about what they can and cannot do.

The question to ask any digital twin vendor is not “can you build a twin of my asset?” The answer to that question is always yes, because the definition of twin has been made expansive enough to guarantee it. The questions to ask are:

• What is your model type, and how does it perform outside the training distribution?

• What is your assumed sensor data quality, and what happens when the actual data quality is lower?

• What is the recalibration process when the model drifts, and who pays for it?

• What operational workflow changes are required to act on the twin’s outputs, and are those in scope?

• What is the performance of your system against a simple statistical baseline on the same data?

If the vendor cannot answer all five questions with specifics, you are not buying a digital twin.

You are buying a 3D dashboard with aspirational pricing.

The technology is not the problem. The framing is the problem. “Twin” implies a fidelity that the physics of model drift, sensor noise, and data latency make impossible to sustain. A model that starts accurate and degrades silently is not a twin. It is a liability, because it creates the conditions for confident decisions made on stale information.

The industry built a business on a word. The word implies a guarantee the physics will not allow. And the gap between the word and the reality is, reliably and consistently, your problem.

Share

This is not a technology problem. The technology exists and largely works. This is an architecture problem, a collision between how agentic AI reasons about tasks and how aviation yield management systems are actually designed to respond to demand. They are not compatible. They are adversarial. And yield management will win.

The Incognito Fallacy, Scaled Up

For years, a folk belief persisted that searching for flights in incognito mode would prevent airlines from detecting repeat searches and raising prices. This belief is wrong at a fundamental architectural level. Yield management systems do not track individual cookies. They track aggregate route demand across all sessions simultaneously.

Your individual browser state is noise. The signal that moves prices is the sum of every search on that route, weighted by time-to-departure, load factor, and competitor availability. Whether you are in incognito or not, you receive the same price as everyone else in your demand microsegment at that moment in time.

Technical Clarification

Yield management engines such as PROS Revenue Management and Amadeus Revenue Management System process aggregate booking curves, not individual session tracking. The misconception that clearing cookies affects pricing conflates client-side personalisation (which does exist for ancillary upselling) with core fare pricing logic (which is segment-level and server-side).

The reason this matters is that every proposed fix for agentic AI aviation booking carries the same misconception scaled to millions of agents. The assumption is that if an agent behaves differently to a human, masking its identity, rotating IPs, varying its search patterns, it can avoid triggering price increases. It cannot. Because price is not a response to who you are. It is a response to how many people want what you want, right now.

The Demand Signal Problem Is Not Fixable

A well-designed agentic booking agent will, by its nature, do the following: search broadly across dates and route alternatives to find the optimal option; re-query to confirm availability hasn’t changed; compare across multiple carriers; and verify price stability before committing. Each of these steps is a search event. Each search event is a demand signal.

Aviation yield management systems — PROS, Amadeus RMS, Sabre AirVision — are trained on decades of human booking behaviour. They interpret search volume as a proxy for intent. High search volume on a route in a given time window means high demand. High demand means price should rise. This is not a bug. It is the entire design.

Now scale this. If ten million travellers deploy AI agents simultaneously on a popular route, the search volume against that route’s inventory multiplies by a factor of ten or more — before a single additional seat is actually sold. The yield engine interprets this as a demand surge. It raises prices autonomously. The agents re-search at the higher price, some switching to alternatives, generating more signals on adjacent routes. Those prices rise too.

This is not a theoretical scenario. It is the mechanical consequence of deploying demand-signal-dependent pricing systems against agents that generate more signals per intent than humans do. The outcome is not cheaper flights. The outcome is a market-wide inflation event caused by phantom demand.

The yield management system was never calibrated for agentic search behaviour. Deploying agents at scale is not outsmarting the pricing engine, it is overfeeding it.

The Distribution Architecture Is Not Accessible

Even before the demand signal problem, agentic AI booking faces a more fundamental obstacle: there is no clean, legal, scalable path to the inventory it needs to compare.

Live airline pricing and availability sits behind three decades of commercial infrastructure. The Global Distribution Systems such as Sabre, Amadeus, Travelport are the only route to real-time inventory across carriers. Accessing them requires commercial agreements, per-segment transaction fees, and contractual data licensing arrangements that cost operators hundreds of thousands of dollars annually before a single booking is made.

The airlines that have moved to NDC (New Distribution Capability) have not opened their inventory, they have reasserted their own gatekeeping, requiring individual commercial agreements with each carrier. An agent that wants to compare British Airways, Lufthansa, and Emirates in real time needs three separate commercial relationships, three separate API integrations, and three separate legal agreements.

Bot Detection Is Not The Agent’s Friend

For agents that attempt to bypass the GDS layer through browser automation — using Playwright, Puppeteer, or computer vision approaches — the infrastructure they encounter is not passive. Airlines and OTAs deploy active bot detection through Cloudflare, DataDome, and proprietary fingerprinting systems specifically designed to identify and throttle non-human traffic.

The response to increased agent traffic will not be capitulation. It will be escalation. Airlines will detect the behavioural signatures of agent search, the systematic date iteration, the non-human dwell times, the API call patterns and throttle or block it. At which point the agent either fails to complete the booking or is forced to present worse, less current pricing than a human searching directly.

The Tragedy of the Commons at Thirty Thousand Feet

This is not a problem that a better agent solves. It is a structural consequence of deploying signal-generating systems against signal-dependent pricing infrastructure at scale. The individual agent acting in the user’s interest, searching diligently, re-verifying prices, comparing alternatives, produces collective harm by inflating the demand signals that make everyone’s flight more expensive.

The yield management engine does not know or care that the search volume is agentic. It knows only that demand for a given route in a given window has increased sharply. Its job is to extract maximum revenue from that demand. It will do its job.

Historically, yield management systems were calibrated on human search behaviour, a known quantity with predictable look-to-book ratios. The introduction of millions of agents with look-to-book ratios an order of magnitude higher than human norms will require those systems to recalibrate. The recalibration will not produce lower prices. It will produce higher baseline prices that account for agentic noise in the demand signal.

The Demo Is Not the Architecture

The agentic AI travel demos work because they run against sandboxed environments, pre-agreed API partners, and synthetic inventory. They do not run against the actual commercial infrastructure that prices real seats on real flights.

The real infrastructure is not neutral. It is actively adversarial to agent access, commercially motivated to maintain information asymmetry, technically designed to respond to demand signals, and legally structured to prevent the kind of open inventory comparison that agents require to function.

The outcome of deploying agentic AI at scale against this architecture is not cheaper flights. It is a market-wide demand signal inflation event that raises prices for every traveller, agentic or otherwise, on the routes where adoption is highest.

Understanding this requires looking past the demo layer to the distribution architecture beneath it. The yield management engine has been optimising against human behaviour for fifty years. It will not lose to a system that generates more signals per intent than humans do. It will profit from it.

Share

But here’s the twist nobody in 2014 saw coming clearly enough: AI arrived and blew the doors off.

The New Bimbo, Hair Colour TBC

In 2014 I said Silicon Valley was a “personified blonde bimbo actress with a serious complex”. I’d extend that now to AI itself and the mythology being constructed around it.

The playbook is identical. Before, the message was: get funded, move fast, break things, disrupt. Now it’s: wrap AI around it, ship in a weekend, become a one-person billion-dollar company. The dream has been re-skinned. The underlying psychology hasn’t moved an inch.

The record label became the VC became the accelerator. Now add the AI platform provider to that chain. OpenAI, Anthropic, Google they sit in the middle of you and your dream, just as surely as any VC ever did. You’re building on their infrastructure, paying their API bills, subject to their pricing changes, their deprecations, their terms of service.

The puppet strings are thinner now. Still there though.

What AI Actually Changed

To be fair and I’m always fair, even when I’m being unpleasant about it some things did shift.

The cost to build collapsed. What needed a team of eight engineers in 2014 needs one person with good prompting skills and a subscription today. That part is real. The barriers to making something exist are lower than they have ever been.

The problem is that the barriers dropped for everyone simultaneously. So the market is now flooded not with more professional wedding photographers, as I put it before, it’s flooded with fully-functioning products that took a weekend to clone. Your moat evaporated before you even dug it. Defensibility in software is a harder argument to make than it was twelve years ago.

What AI didn’t change: distribution, trust, customer acquisition, and the relentless difficulty of getting people to pay for things. Those problems remain stubbornly human.

The VC Reckoning

The funding winter shook out a lot of what needed shaking. Firms that were throwing term sheets at anyone with a Notion doc and a deck full of TAM slides got burned. LPs got impatient. Management fees on underperforming funds became a talking point. The 90% failure rate I mentioned in 2014 didn’t improve, by some measures in the AI gold rush cohort, it got worse because the speed of build meant the speed of ship something nobody wants also accelerated dramatically. I’ve been caught out with that myself, now I’m far more measured.

The “captives” pool didn’t go away. It just rebranded. Now it’s often framed as “AI-native portfolio companies”, same dynamic, much gloss shiny language.

Accelerators and hubs are still running the numbers game. Many of them now mandate “AI integration” as a condition of entry, which is about as meaningful as mandating you have a LinkedIn page. It’s a checkbox, not a strategy.

The Quiet Counter-Movement

Here’s what I didn’t see coming in 2014, and what genuinely gives me some optimism. I know, me Jase, optimistic.

The tools of the trade being democratised by AI have created a genuine micro-startup class. Small, profitable, un-funded, often solo or two-person operations building specific things for specific people and actually making money. No pitch deck. No investor relations. No 409A valuations. Revenue from customers, radical concept.

This isn’t the Silicon Valley model. It’s closer to the old-school small business model, except the margins can be software margins. That’s interesting. That’s actually new.

The irony is that AI, the thing being used to sell the latest version of the startup dream, is also quietly enabling the antithesis of that dream: small, independent, sustainable, and beholden to nobody. Now that I like because I’ve preached that for years.

Every Startup Is Still A Marilyn

The core of what I wrote in 2014 holds. You’ll still go to all the networking events, now they’re called demo days and AI summits. You’ll talk to all the right people, apply for all the programmes, and at some point someone will suggest you just “pivot the model slightly” and then the money might flow.

And in that moment, the first puppet string connects.

What I’d add now: the AI hype cycle is a particularly seductive version of this trap, because it comes dressed as empowerment. You don’t need anyone, you can build anything, the tools are there all true, to a point. If your entire strategy rests on a foundation owned by someone else’s model, someone else’s API, someone else’s infrastructure, you are still auditioning. You’ve just moved the casting couch.

K.I.S.S. - Keep It Separate, Stupid.

My advice from 2014 stands. You need honest people around you, not cheerleaders. You need to understand your numbers, not your narrative. And you need to know who’s actually in the middle of you and your customer because there’s always someone in the middle now, and in 2026 it might be a model provider you’re paying per token.

I’m still grumpy, still 100% equity where possible, still suspicious of anyone who tells you it’s easy.

The dream is still the same dream. The costume changed. The complex didn’t.

Share

This distinction matters enormously. When a model says something false, when it invents a citation, misremembers a date, or confabulates a biography, it is not lying. It is doing exactly what it was designed to do: pick the statistically likely next token.

The problem is that statistical likelihood and factual truth are not the same thing.

The AI industry has decided to call this gap a “hallucination.”

That word choice is not neutral. It implies a failure of perception, a momentary lapse, something that happens to an otherwise sound mind. It is the perfect term for an industry that wants to acknowledge the problem just enough to seem responsible, while obscuring what’s actually going on.

Welcome to the inside of the world’s most elaborate magic trick which is really just numbers.

The softmax: where all tokens compete

Before a model produces any word, it converts raw logit scores into a probability distribution using the softmax function. Every token in the vocabulary gets a probability, and those probabilities sum to exactly 1. Nothing is ever ruled out entirely some tokens are just astronomically unlikely.

# Softmax: converts raw scores → probabilities
# P(token_i) = exp(z_i) / Σ exp(z_j)   for all j in vocabulary

import numpy as np

def softmax(logits):
    e = np.exp(logits - np.max(logits))  # subtract max for numerical stability
    return e / e.sum()

logits = np.array([4.2, 2.1, 1.8, 0.5, -0.3])
probs  = softmax(logits)
# → [0.723, 0.097, 0.073, 0.032, 0.015]  ← sums to ~1.0

# The top token wins 72% of the time.
# But 28% of the time, something else comes out. Every single generation.

This is the foundation. The model never decides anything. It draws from a distribution. On factual questions where the training data is rich and consistent, the correct answer sits at 0.95+ probability and almost always wins. On questions at the edge of its training like obscure facts, recent events, niche domains for example, the distribution flattens, and the gap between the right answer and a plausible-sounding wrong answer narrows to nothing.

Entropy: measuring what the model doesn’t know

Information theory gives us a precise way to measure how uncertain a distribution is. Shannon entropy quantifies exactly how “spread out” the probability mass is and therefore how likely the model is to produce something unexpected.

# Shannon entropy of a discrete distribution
# H(P) = -Σ P(x) · log₂ P(x)   for all x with P(x) > 0

def entropy(probs):
    probs = np.array(probs)
    probs = probs[probs > 0]  # avoid log(0)
    return -np.sum(probs * np.log2(probs))

# A deterministic distribution — the model is certain:
entropy([1.0, 0.0, 0.0])           # → 0.0 bits  (no uncertainty)

# A fully uniform distribution — the model has no idea:
entropy([0.25, 0.25, 0.25, 0.25])  # → 2.0 bits  (maximum uncertainty)

# A realistic model output on a well-known fact:
entropy([0.72, 0.10, 0.08, 0.06, 0.04])  # → 1.34 bits

High entropy doesn’t mean the model is broken. It means the model is genuinely uncertain, which is often the correct epistemic state. The problem arises when a model generates confidently despite high entropy in its internal distribution. Think about all those research papers that look right but are nowhere near reality.

That gap between expressed certainty and internal uncertainty is where hallucinations live.

And here is the first thing the industry doesn’t want to say plainly: the model always has the information it needs to flag its own uncertainty. It just isn’t trained to use it.

The chain rule: how small errors become confident nonsense

Language models generate text one token at a time, each conditioned on all prior tokens. This means probabilities multiply. A sequence of individually plausible tokens can produce a collectively improbable and factually wrong sentence.

I usually get a hard time when I call any LLM a “stochastic plausibility engine” but that’s exactly what it is.

# Joint probability of a sequence via the chain rule:
# P(w₁, w₂, ..., wₙ) = P(w₁) · P(w₂|w₁) · P(w₃|w₁,w₂) · ... · P(wₙ|w₁,...,wₙ₋₁)

import functools, operator

# If each token has 90% "correct" probability over 10 tokens:
token_probs = [0.90] * 10
joint_prob  = functools.reduce(operator.mul, token_probs, 1)
# → 0.349  (only 35% chance the full sentence is "correct")

# At 80% per token over 20 tokens:
joint_prob_20 = 0.80 ** 20
# → 0.012  (1.2% chance — almost certainly contains an error)

# At a seemingly-generous 95% per token over 200 tokens:
joint_prob_200 = 0.95 ** 200
# → 0.000035  (0.004% — virtually guaranteed to contain an error)

This is why longer answers are more likely to contain errors. It is not sloppiness. It is arithmetic. Every sentence you add to a prompt response is another multiplication by a number less than one. The joint probability of a perfectly accurate 200-token paragraph approaches zero regardless of how good the model is on any individual token.

The industry presents this as a problem of model capability something that will be solved with more parameters, more data, more compute. It will not. The chain rule is not a training artifact, it is mathematics.

Perplexity: the model’s own uncertainty score

Perplexity is the standard metric for how “surprised” a model is by a sequence. It is the exponentiated cross-entropy and it maps directly onto how probable the model considers the text to be.

# Perplexity of a sequence
# PPL = exp(-1/N · Σ log P(wᵢ | w₁,...,wᵢ₋₁))

def perplexity(probs):
    """probs: list of per-token probabilities assigned by model"""
    N = len(probs)
    log_sum = sum(np.log(p) for p in probs)
    return np.exp(-log_sum / N)

# A confident model on familiar text:
perplexity([0.92, 0.88, 0.91, 0.87, 0.90])  # → ~1.12  (very low)

# Model generating a fabricated citation:
perplexity([0.71, 0.43, 0.38, 0.52, 0.29])  # → ~2.54  (higher, but not dramatic)

# The crucial insight: hallucinated text often has LOW perplexity.
# The model generates fabrications smoothly, confidently, without hesitation —
# because they fit the statistical patterns of training data perfectly,
# even if no such fact exists in reality.

This last point deserves to be said slowly. The most dangerous hallucinations are the ones the model is most confident about. A model that fabricates a plausible-sounding paper title in the style of an academic citation will assign that fabrication a lower perplexity than an awkward but accurate paraphrase of reality. Statistical fluency and factual accuracy are not just different things they are sometimes in direct tension.

Temperature scaling: the knob nobody explains honestly

Modern models use temperature scaling to control the shape of the output distribution. This is presented to users as a creativity dial. “Low temperature for factual tasks, high temperature for creative ones.” That framing is true but incomplete and the part that gets omitted is revealing. And the Linkedin experts get really upset when I point it out.

# Temperature scaling: reshape the logit distribution
# P_T(token_i) = softmax(z_i / T)
#
# T < 1.0 → sharper (model becomes more deterministic)
# T = 1.0 → standard distribution
# T > 1.0 → flatter (more creative / more hallucinatory)

# Nucleus (top-p) sampling: only sample from top probability mass
def top_p_sample(probs, p=0.9):
    sorted_idx   = np.argsort(probs)[::-1]
    sorted_probs = probs[sorted_idx]
    cumsum       = np.cumsum(sorted_probs)
    nucleus      = sorted_idx[cumsum <= p]
    nucleus_probs = sorted_probs[:len(nucleus)]
    nucleus_probs /= nucleus_probs.sum()     # renormalize
    return np.random.choice(nucleus, p=nucleus_probs)

What temperature actually controls is the hallucination rate. At temperature 0.1, the model almost always picks the top token. At temperature 1.5, the fifth or sixth most likely token wins regularly. The creative outputs users get at high temperature come at a direct cost: the probability mass is no longer concentrated on factually accurate tokens.

The API defaults used by most applications, temperatures around 0.7 to 1.0, top-p around 0.9 are not chosen because they minimise errors. They are chosen because they produce text that reads well. Fluent text, as it turns out, is not the same as accurate text.

The industry has largely optimised for the former while marketing the latter.

What this actually means and what won’t fix it

The standard narrative is that hallucinations are a bug on the path to a fixed product. Train on more data. Scale the model. Apply RLHF. Add retrieval. The problem will shrink until it’s negligible.

This narrative is wrong in a specific and important way.

More training data sharpens the distribution on things that are well-represented in the training corpus. It does nothing for the obscure facts, the niche domains, the things that happened after the cutoff date, the things that were never written down at all. The distribution will always have a long tail. The chain rule will always turn small per-token error rates into large sentence-level error rates. Perplexity and accuracy will always be different things.

What can change, and what the serious research is actually about, is whether models communicate their uncertainty honestly. Calibration research asks: when a model says it is 90% confident, is it right 90% of the time? For most current models the answer is no. They are systematically overconfident. RLHF, which trains models on human preference, makes this worse, because humans prefer confident-sounding answers to hedged ones, and the training signal rewards confidence regardless of accuracy.

Retrieval-augmented generation helps, but it relocates the problem rather than solving it. The model still has to decide when to retrieve, what to retrieve, and whether the retrieved content is relevant. Each of those decisions is a probabilistic one.

The honest version of where we are: these systems will always produce statistically likely outputs, and statistically likely outputs will sometimes be wrong. The question is whether the output signals when it might be wrong, and right now, for the most part, it doesn’t. The model has access to its own entropy at every token. It knows, in a mathematical sense, when it is uncertain. It is almost never trained to tell you.

That gap, between what the model knows about its own uncertainty and what it communicates to you, is not a technical limitation. It is a product decision. And it is the decision that makes hallucinations genuinely dangerous, rather than merely occasionally inconvenient.

The word “hallucination” was always a category error. A hallucination implies a mind that has temporarily lost contact with reality.

What’s actually happening is simpler and more tractable: a probability distribution being sampled in a region where it isn’t reliable, by a system that was never properly incentivised to say so.

Rename it and the problem becomes clearer. It’s not a hallucination. It’s an uncalibrated sample from a high-entropy distribution, presented without the uncertainty estimate it was always carrying.

Fix the incentive. Require the uncertainty estimate. The rest is arithmetic.

Subscribe now

Share

Interesting in Machine Learning and Java?

The new pressure on early-stage startups

If you’re a non-technical founder in 2026, you are almost certainly being told to build with AI tools before hiring engineers. The logic is seductive: reduce burn, move fast, validate before you invest in “real” infrastructure. Lovable, Bolt, v0, Cursor, the ecosystem of AI-assisted and AI-generated app builders has exploded, and the implicit message from investors and accelerators is that reaching for one of these tools is simply what a smart, capital-efficient founder does now.

Some of that pressure is well-meaning. Some of it is investors pattern-matching on a trend without having used the tools themselves, “If I can do it, you can too!”. Either way, the startups at the end of that advice are discovering a gap between the pitch and the reality and it’s costing them in ways that don’t show up in the original sales comparison.

How the credits model hides what you’re actually spending

Most of these platforms charge on a credit or token basis, you buy a bundle, and each generation, each edit, each debugging attempt burns through it. This model is clever, because it decouples the cost from any intuitive sense of value. You’re not paying per feature. You’re paying per attempt.

And attempts multiply fast. Well done if you get it right first time, chances are though you won’t. And that, therefore, will cost you.

Here’s what a typical session actually looks like. You describe a feature. The tool generates something close but not quite right. You iterate. It fixes one thing and breaks another. You try a different prompt. It regresses further. You revert. You try again. By the time you have something working, you’ve burned through credits on six or eight generations that produced nothing you’ll ship. The cost of the feature you actually wanted is buried in the cost of all the features you didn’t.

You’ve run out of credits for today, come back tomorrow. It’s an addition, it’s like Pavlov’s dog. It’s the companies who are ringing the bell.

This isn’t a flaw in the tools, it’s the nature of generative, probabilistic systems. But it’s also not what gets communicated when an accelerator tells you to “just spin something up on Lovable.”

The debugging trap

The dirty secret of AI-generated code is that it’s often easy to generate and expensive to debug. Not because the code is obviously bad, it frequently looks clean and plausible, but because it’s optimised for appearing correct rather than being maintainable. Edge cases get papered over. Dependencies get pulled in for convenience. Architectural decisions get made implicitly that you’d never make explicitly.

This is fine for a prototype that you’re going to throw away. It becomes a serious problem when investors see the prototype and say “great, now just build the real thing on top of this.”

The moment you need to extend beyond what the AI tool generates cleanly, custom integrations, complex business logic, performance at scale and you’re either burning more credits on increasingly speculative generations, or you’re bringing in a human developer to work with a codebase they didn’t write, can’t fully trust, and often can’t easily modify without risking unravelling something upstream.

Experienced developers have a word for this kind of codebase. Several words, in fact, and most of them aren’t printable.

The scaling cliff

There’s a point that almost every AI-built startup hits, and it usually arrives faster than expected. Call it the scaling cliff: the moment when the tool that served you well at prototype stage becomes an active liability.

The economics of these platforms don’t improve at scale, they worsen. More users means more edge cases the generated code didn’t anticipate. More features means more surface area for the architectural shortcuts to cause problems. And the credit costs, which felt manageable when you were building, start to look alarming when you’re running a live product and every bug fix is a credit spend with an uncertain outcome.

At this point, the choice is unpleasant: continue burning money on a platform that’s increasingly fighting you, or bring in engineers to rebuild, not from scratch, which is demoralising and expensive but from a foundation that someone else’s AI laid without any particular knowledge of your business requirements.

Rebuilding from AI-generated foundations is becoming a genuine category of consulting work. That should tell you something.

What investors aren’t accounting for

The “build with AI tools” advice optimises for one metric: time to MVP. That’s a legitimate thing to optimise for, especially early. But it creates a hidden liability on the balance sheet that doesn’t show up until later, at which point it’s someone else’s problem often the founder’s.

The costs that don’t get discussed:

Credit burn on failed iterations. Not just the final product, but every attempt along the way. Heavy users of these platforms report spending 3–5x their original estimate once you account for the exploratory, non-productive generations.

Technical debt at an accelerated rate. AI-generated codebases accrue debt faster than human-written ones, because the “author” has no memory of past decisions and no stake in future maintainability.

Developer remediation costs. When you eventually hire engineers, and you will, budget for them spending significant time understanding and stabilising what the AI built, before they can build anything new. This is billable time that produces no visible output.

Platform dependency risk. Your application is often deeply coupled to the platform’s assumptions, infrastructure choices, and sometimes its proprietary abstractions. If pricing changes or the platform pivots or shuts down, your migration path is non-trivial.

Founder time. This one is underrated. Wrestling with an AI tool that’s producing the wrong thing is not a zero-cost activity. It’s founder time that isn’t being spent on customers, fundraising, or product thinking the things that actually determine whether the company survives.

The tool isn’t the problem. The advice is.

To be clear: these tools are genuinely impressive and genuinely useful. For the right use case rapid prototyping, internal tooling, validating an idea before investing in proper engineering they’re remarkable. The problem isn’t the technology. The problem is the framing.

When an investor says “just use Lovable,” they’re rarely thinking about what happens six months later. They’re thinking about burn rate and demo-readiness. Those are real concerns. But they’re not the only concerns, and founders who take the advice at face value without modelling the downstream costs are making a financial decision based on incomplete information.

The honest version of the advice would sound more like: “These tools can get you to a demo fast, and that’s worth a lot. But go in with eyes open about the credit model, plan for a remediation phase when you hire your first engineer, and don’t let the prototype become the foundation unless you’re prepared for what that costs.”

That advice is longer and less punchy. Which is probably why it doesn’t get given.

Subscribe now

Share

Interest in Machine Learning and Java?

Watching it converge after a few hundred epochs is quietly satisfying. Why? Well, why not? There ain’t nothing wrong with learning.

The accuracy after 100,000 training iterations was pretty good.

FINAL NETWORK TESTING

============================================================

Input: [0.0, 0.0] → Prediction: 0.0074, Expected: 0

Input: [0.0, 1.0] → Prediction: 0.9902, Expected: 1

Input: [1.0, 0.0] → Prediction: 0.9906, Expected: 1

Input: [1.0, 1.0] → Prediction: 0.0131, Expected: 0

Is this really any different from what’s inside a large language model? The answer is both yes and no, the “no” part is more profound than most people realise.

The XOR problem and why it matters

XOR (exclusive OR) is the classic benchmark because it’s not linearly separable. A single neuron with a straight-line decision boundary can’t solve it. You need at least one hidden layer to create the non-linear mapping.

Solving XOR forces you to build a Multi-Layer Perceptron (MLP), the same architectural primitive at the heart of every modern AI model.

What the Java implementation looks like

The core training loop in my implementation follows the standard forward-pass → loss → backprop cycle, here’s the general pseudocode:

// Forward pass

double[] hidden = activate(multiply(weights1, input));

double output = activate(dot(weights2, hidden));

// Backprop — compute deltas and update weights

double outputError = target - output;

double outputDelta = outputError * sigmoidDerivative(output);

for (int i = 0; i < hidden.length; i++) {

double hiddenError = outputDelta * weights2[i];

double hiddenDelta = hiddenError * sigmoidDerivative(hidden[i]);

weights1[i] += learningRate * hiddenDelta * input[i];

}

weights2 += learningRate * outputDelta;

Three ingredients: weighted sums, an activation function (sigmoid here), and gradient descent via backpropagation. That’s the whole recipe.

A minimal MLP: 2 inputs → 3 hidden neurons → 1 output

Now scale that up, welcome to WebScale GenAI!

Here’s where it gets interesting. Modern large language models like GPT-4, Llama 3, or Claude are built on the Transformer architecture. But inside every Transformer block, there’s a component called the Feed-Forward Network (FFN) and it is, structurally, a MLP.

In a Transformer, each attention layer is followed by a two-layer MLP with a non-linear activation. This is where the model “stores” knowledge and applies reasoning not in the attention heads alone.

Well when I say reasoning…. it can’t reason. It’s just a numerical context of what reasoning is.

The attention mechanism decides what to focus on. The MLP then decides what to do with that information. They work in tandem across potentially hundreds of layers.

In a model like Llama 3 8B, the FFN alone accounts for roughly two-thirds of the total parameters. Your XOR network has ~10 weights. GPT-4 is estimated at ~1.8 trillion. Same structure, vastly different scale.

The gap between XOR and GPT isn’t architecture it’s data, depth, and compute. The mathematics is the same.

Activation functions: from sigmoid to SwiGLU

My Java network uses a sigmoid activation, smooth, bounded between 0 and 1, and the classic choice for learning XOR.

Modern LLMs have moved on. The dominant activation in 2024–2025 FFN layers is SwiGLU, a gated variant of the Swish function. It empirically outperforms ReLU and GELU on large-scale language tasks. But the principle is identical: introduce non-linearity so the network can learn complex mappings.

Here’s the conceptual progression:

Sigmoid (XOR, 1980s) → ReLU (deep learning, 2010s) → GELU (BERT, GPT-2) → SwiGLU (LLaMA, Mistral, Gemma)

Backpropagation hasn’t changed, the hardware has

The algorithm that trains my Java network backpropagation with stochastic gradient descent is the same algorithm used to train every LLM. Rumelhart, Hinton, and Williams described it in 1986. We haven’t replaced it; we’ve just parallelised it across thousands of GPU cores with frameworks like PyTorch and JAX.

What has changed:

Batch size: My XOR network trains on 4 examples. LLMs train on trillions of tokens in massive parallel batches.

Optimiser: Vanilla SGD → AdamW with learning rate schedulers, gradient clipping, and warm-up phases.

Regularisation: Nothing in XOR. LLMs use dropout, weight decay, and layer normalisation throughout.

Why this matters if you’re building with AI

Understanding the MLP as a foundational primitive helps demystify a lot of what GenAI does and doesn’t do. When an LLM “hallucinates”, part of that is the FFN layers retrieving learned associations that don’t generalise correctly to your prompt. When you engineer prompts, you’re influencing which weights get activated through the attention + FFN pipeline.

My thoughts on model hallucinations and the use of the term in LLMs is widely known on Linkedin. It may have caused a bit of a stir.

It also reframes RAG (Retrieval Augmented Generation). You’re essentially compensating for the fixed parametric memory of the MLP layers by injecting external context giving the model facts its weights never learned.

It’s all numbers. That’s it.

If you’ve never trained a neural network from scratch

Do it! In any language, it doesn’t matter about language, whatever works best for you. Even a toy XOR network wires your intuition for what gradient descent, loss curves, and weight initialisation actually mean, the things that matter enormously when evaluating and fine-tuning foundation models.

The XOR gate may be a teaching toy, but the lesson is real: you’re one abstraction layer away from the engines running the most capable AI systems in the world.

That’s not a small thing, and you’ll sound really clever at meetups.

You can take a look at the Java code on my Github Gist.

Subscribe now

Share

A diligent AI agent, doing exactly its job, generates 8–15 search events per booking intention. A human generates 2–3.

At scale, millions of agents searching simultaneously don't outsmart the pricing engine. They overfeed it. The yield system reads amplified demand signals and raises prices autonomously before the booking completes.

The incognito myth, scaled up and automated, doesn't find you cheaper flights. It triggers a market-wide inflation event on the routes where adoption is highest.

I've written a full technical breakdown with architecture diagrams covering:
→ Why yield management pricing is immune to client-side manipulation
→ How agentic search behaviour inflates demand signals structurally
→ The GDS gatekeeping layer that gives agents no clean path to live inventory
→ The feedback loop that makes widespread adoption self-defeating

The demo is not the architecture.

You can read the full article here on jasonbelldata.com.

I Don’t Play Golf - I’ll Stick to Reading and Toasties

When I visit St Andrews in Scotland there are two places I make a beeline for: Toppings and Co Bookshop and the Cheesy Toast Shack. Trust me there’s a few posts about St Andrews local businesses customer service but let’s not get ahead of ourselves, this is all about the toasties.

I’d made it to the shack once before and fell in love with the New Yorker Cheese Toastie.

My commute a few times a year was long, 250+ miles and seven hours door-to-door, so my first port of call was the Shack. One year I saved myself for pizza instead with my daughter, Mozza was chosen as the destination and the pizza was most excellent. The next table was long and had about sixteen people on it. They were all having a great time so I didn’t take much notice. Pizza was consumed and my daughter and I left happy.

The next morning, in preparation for the return trip, I swung by the Toastie Shack. This time the Red Leicester, Chorizo and Rocket (astounding piece of work every time). Behind the window the staff member, rather pale looking, “Did you enjoy your pizza last night?”. I look confused, surprised and then he perked up, “We were the noisy table, hopefully it wasn’t a problem.”, “Not a problem to me, you were all enjoying yourselves.”, I said. Toastie made and a free coffee supplied for the journey home (Amazing customer service surprise #1). With that I drove off.

Three months later….

Back to St Andrews, straight to the Shack. And this time without hesitation (and a different staff member) and with index finger firmly pointed, “YOU’RE THE MAN FROM MOZZA!”. Once again another apology about the noise, it was seriously no problem to me, turns out it might have been to some other patrons. I can neither confirm or deny. It also was brought to my attention that I missed the round of shots that were purchased. I was driving anyway….

Another six months past. Another commute and once again my first port of call is for the lure of the Red Leicester. And every time, “YOU’RE THE MAN FROM MOZZA!”, same shock but different staff member.

For the next four years every visit was the same. Order tickets had #ManFromMozza written on them, then it became first name terms. Every time I visit it’s like a smile from a long lost friend you haven’t seen in years. I’ve had some really interesting conversations with folks in the queue about the weather (it’s Scotland, it’s cold), the food and even jazz. Chick Corea is certainly not boring.

Customers are willing to wait a long time for a toastie, this aspect alone is not lost on me. The Shack has some die hard fans.

I’m a delighted customer and I will shout as loudly as I can to support them. And that’s the whole point.

And how the Toastie Shack just does social media, marketing, events, branding - well it’s all just spot on. Controversy, they can handle it. Charitable giving, just search on Seagull Insurance. It’s perfect.

While I’m no longer doing the “commute” we still keep in touch once in a while. Replacement stickers for a laptop, sent without fuss. Messages about brilliant experiences, I can do that.

What Can We Learn?

Well there’s just a lot to learn here. That hatch on East Sands can only really deal with one person at a time, and that’s where it shines. The customer experience is one-to-one. There’s no online ordering (that I’m aware of) and that’s fine, if you want to experience it then you have to be there.

Kate Carter-Larg, Sam Larg and the rest of the team just ooze service, each and every time. They’ve got the thing down to a fine art in my eyes. Like I’ve already said, marketing for them seems to be natural. Their fanbase is made up of tourists and foodies alike, they’re all willing to shout as loud as I do about how good the Shack is.

Jase, I want to visit!

You can, here’s the location on Google Maps. And if you do go, just tell them that the #ManFromMozza sent you. :)