Aydın Tiryaki and Claude (July 18, 2026)

Introduction: The Story of a “Study”

This article is the product of an unusual process. It didn’t start from a research report or a literature review; it started from an observation carried for some time by a user of AI — not an AI engineer, but a retired chemical engineer with nearly half a century of software and algorithm experience — and from testing that observation step by step.

The observation was simple: “I’ve been using AI for a year and a half. I could see progress early on; I don’t see it now. The breakthrough everyone expected stalled somewhere and stayed there. I sometimes even think what gets presented as revolutionary is really just cosmetic.”

What follows isn’t a single-sentence verdict on that observation, confirming or dismissing it. Instead, we tested it piece by piece against current research and industry data, to see how far it holds and where it needed sharpening. What emerged is a far more layered picture than the original question — and, more interestingly, the solutions the author proposed for this bottleneck turned out, without his knowing it, to already match what current AI engineering research is actively working on.

This article comes in two parts. The main text below presents our conclusions thematically. The full transcript, provided as an appendix, records the order, objections, and corrections through which we reached them, numbered exchange by exchange.

Part 1: Explosion, Then Plateau — Where Scaling Genuinely Ran Out

The author’s first intuition — “it got to a certain point and stayed there” — turns out to be a serious, evidence-backed observation. Through 2025–2026, a similar voice rose from inside the major AI labs themselves: the capability gains from simply making models bigger — more parameters, more data, more compute — are shrinking. OpenAI’s former chief scientist, Ilya Sutskever, has openly said that performance gains from larger models have plateaued. The academic numbers back this up: AI R&D spending rose from $52 billion in 2021 to a projected $250 billion in 2025, while annual gains on a leading benchmark (MMLU) fell from 16.1 points to 3.6 points over the same span. In other words: much more money, much less to show for it — a curve that matches the author’s intuition closely.

Still, this picture needs a careful read: the loudest voice behind the “scaling is over” narrative has his own new venture running on less compute than its rivals, so this narrative happens to serve his own interests directly — worth noting when weighing how disinterested any given testimony is.

On the other hand, the claim that “general AI capability has stalled” doesn’t hold up either. On harder, newer benchmarks, real and substantial jumps have appeared: on a test of abstract reasoning (ARC-AGI), models that scored around 5% a couple of years ago now reach 77–85% — assessed as a genuine qualitative leap, not benchmark inflation.

The first conclusion, then: there is no single answer to “has it hit a wall?” The returns from raw scaling really have diminished. But AI’s general capability hasn’t stopped — progress continues, just on different and harder yardsticks. The author’s “it exploded, then stopped” intuition traces a real curve; it just needed a more precise account of where that curve flattens.

Part 2: Two Root Causes — Data Exhaustion and the Hallucination Spiral

The author looked for the cause of this bottleneck in two connected places: (1) the internet’s usable supply of human-written data approaching exhaustion, increasingly replaced by AI-generated content; (2) how far systems can advance when trained on data produced by systems that, by their own account, hallucinate.

The first point — “model collapse” — is not an idle academic worry; it’s a mathematically demonstrated phenomenon. When generative AI models are increasingly trained on content produced by earlier AI systems rather than genuine human data, system performance and diversity degrade in a repeating pattern. This isn’t only empirical; it’s shown to be a near-inevitable consequence of a basic statistical theorem (the Central Limit Theorem), since each training generation erases the rare-but-important tails of the data distribution.

But the literature also notes this risk isn’t unsolvable: the fix isn’t avoiding synthetic data altogether, but accumulating it alongside real data rather than substituting it. The critical distinction is this: in domains where correctness can be checked automatically from the outside — code, mathematics — synthetic data can be used safely; in open-ended domains with no such referee — law, history, social analysis — the contamination risk is far more real, and this second category is exactly where the author’s own everyday questions to AI tend to fall.

The second point — hallucination — paints an even more layered picture. On easy, narrow tasks (summarizing a text, say), there’s genuine progress: measured hallucination rates have fallen roughly 95% since 2024. But depending on the task, frontier models still get 3–19% of answers wrong, and that residual error has barely budged in a year. The most striking finding: models built for deeper reasoning tend to hallucinate more, not less, on factual tests — because the chain-of-thought process is prone to filling missing steps with plausible-sounding fabrication.

Together, these two findings sharpen the author’s original intuition into a stronger thesis: progress is piling up in verifiable, narrow domains — code, math, short summarization — while in open-ended domains requiring long-tail knowledge, both data contamination and hallucination risk keep growing, sometimes even worsening in reasoning models.

Part 3: A Way Out in Verifiable Domains — Creating Knowledge Through Simulation

The author proposed a solution to this bottleneck unprompted: “The task now isn’t compiling knowledge, but creating it through computation and simulation.” This proposal matches, almost exactly, an approach already in production with concrete results: Google DeepMind’s AlphaEvolve.

AlphaEvolve pairs an LLM’s generative creativity with rigorous automated evaluation in a loop that mirrors the scientific method: propose, test, refine, repeat. This isn’t abstract — it has concrete outcomes: it optimized the silicon design of next-generation chips; improved a cloud storage system’s compaction algorithm, cutting write amplification by 20%; raised the accuracy of natural-disaster predictions by 5%; and found quantum-circuit designs with tenfold lower error rates for molecular simulation.

But this is where one of the article’s most important limits appears. As Google’s chief scientist Pushmeet Kohli puts it, the one requirement is a genuinely trustworthy evaluation function. This method only works in automatically verifiable domains — math, code, chip design, molecular simulation — anywhere a right/wrong referee can be built. In the domains the author engages with day to day — law, policy, history, social analysis — no such referee exists.

This sharpens the article’s central distinction: the answer to “has it hit a wall?” splits — no, in verifiable domains; yes, in open-ended ones.

Part 4: Cost, Caching, and Freshness — Keeping the System Standing

Later in the conversation, the author turned to a different axis: the computational load that rapidly rising user numbers place on AI systems, and, as a solution, the idea of storing frequently repeated queries as ready-made “packages.” This proposal matches — again, almost exactly — an already-named technique: semantic caching.

The numbers confirm the intuition: roughly 31% of queries show semantic similarity to prior requests. The measured production impact isn’t trivial either — one company cut its monthly LLM API bill by 73%, from $47,000 to $12,700. Major AI providers have already built this into their own infrastructure; in one case, cost drops by up to 90% and latency by up to 85% for long prompts.

But the author added, unprompted, an important qualification: caching shouldn’t be rigid — it should only be used where an update is genuinely never needed; otherwise a serious “crisis of trust” follows, which the author says he has personally experienced across every AI platform he uses — Gemini, Claude, and ChatGPT alike. This too matches a well-documented, named engineering problem: a system often can’t tell when a cached answer has gone stale — it still looks valid, it’s simply wrong. There’s an even more serious version: semantic caches can amplify hallucinations — a wrong answer produced once gets served to every future similar query from the cache, so the error compounds rather than fades. And the fix the author proposed matches the industry’s own recommendation: use a higher similarity threshold for sensitive or factual queries, and scope caches narrowly by topic rather than building one global cache.

The author then arrived, by intuition, at the industry’s own answer: cache validity should be tied to the source’s real publication calendar. As a concrete example, he pointed to Turkey’s inflation data: the statistics institute (TÜİK) announces inflation figures on the 3rd of every month; there’s no need to re-check before the next release — except for weekend exceptions (when the 3rd falls on a Saturday, the announcement shifts to the following Monday), which need to be built into the package alongside the source’s own calendar logic. Once verified — the December 2025 figure indeed shifted to January 5, 2026, exactly this way — this example showed “calendar-aware caching” to be both concrete and directly implementable.

The author extended the framework further: using user objections as an audit trigger, keeping a “reliability index” for verified packages, and the “verify once, serve ten thousand times” economics — all of these map onto named approaches already used in production. One caveat had to be added: a “100% correct” stamp can be risky, since source institutions themselves sometimes revise past data quietly.

This last point led into a field economists already call “real-time” or “vintage” data: tracking how often statistical agencies revise their releases, and even the IMF’s formal standards for auditing the transparency of countries’ revision policies. The author’s own balance — “no need to be this suspicious every time, but don’t fully trust it either” — matches a formal framework distinguishing “preliminary forecast risk” from “revision risk.”

Finally, the author proposed tracking, through a “dependency graph,” which other packages a piece of revised information would affect — which matches current research on cache-management frameworks built around “dependency attention” and GraphRAG architectures.

Part 5: Delegating to Software — “Compiled AI”

Perhaps the conversation’s most fundamental turning point came from the author’s engineering background: software is deterministic — feed it the same data a million times and you get the same result every time. AI is probabilistic — ask the same model the same question the same way, and you can still get different, even contradictory, answers. The author’s proposal was clear: since AI can write its own algorithms and software, tasks that should be deterministic ought to be delegated to software; AI itself should step in only where judgment and interpretation are genuinely required.

This proposal is the entire rationale behind what’s now called “Compiled AI.” Constraining generation improves reliability, since the model can’t hallucinate a wrong API call or database schema when it’s coming from a pre-tested template. The economics match the author’s caching logic too: architectures that amortize inference across many transactions, rather than invoking a massive model per request, are far more economical at scale.

One technical nuance was added here: setting temperature to zero doesn’t fully solve the problem — it doesn’t eliminate hallucination, it just makes it consistent; a confidently wrong model will give the same wrong answer every time. The real safeguard is that an answer be verified by an independent, deterministic computation.

This single principle turns out to unify everything proposed across the conversation — AlphaEvolve’s simulate-and-verify loop, the caching/packaging idea, and now this “delegate to software” principle: wherever possible, hand AI’s probabilistic generation off to a once-verified, deterministic mechanism — code, an index, a record.

Later in the conversation, an interesting fact surfaced: the author had, in fact, already worked through this idea independently, in his own words, in an article titled “Gem Compilation and Hybrid Systems,” published on April 1, 2026. The architecture described there — a “Master Program” managing the workflow, mechanical work delegated to sub-routines, AI stepping in only at “cognitive checkpoints,” and a Gem being “compiled” once per version release — is nearly identical to what’s described in today’s academic literature.

An honest question then had to be addressed: the author asked, in effect, “could something this fundamental — a principle the software world has known for half a century — really have gone unapplied to AI?” — and he was right to ask. Our first answer had implied that this idea might not have predated an academic paper titled “Compiled AI,” dated April 6, 2026 — as if this were a matter of priority. That framing was inaccurate and had to be corrected: the roots of this idea go back much further, at least to 2022–2023. Stanford’s DSPy framework, published in October 2023, explicitly described “compiling declarative language model calls into pipelines” — using the word “compile” in precisely this sense. Frameworks like LangChain (2022), Microsoft’s Semantic Kernel (2023), and LlamaIndex (2022) were already offering ready-made chains linking language models to external tools; OpenAI’s function calling had been standard since 2023.

The honest framing is this: the idea had been known in specialist AI-engineering circles since 2023, but largely stayed within that technical world. The author’s contribution isn’t “getting there first” — it’s arriving at the very same solution independently, unaware of that literature, purely through engineering intuition, and enriching it with his own original idea (a “Gem Analyzer” performing audit-style review). The author himself drew this distinction clearly: his surprise wasn’t about claiming priority — it was that something this fundamental being genuinely overlooked seemed implausible on its face, and he turned out to be right.

Part 6: On a User’s Engineering Intuition

Perhaps this article’s most distinctive feature isn’t the technical theses it covers, but how they were reached. Throughout the conversation, the author repeated the same experience: he would first arrive at a solution through his own engineering logic, and only then would we find that the same solution already existed in the literature — the multiple-viewpoints method (“self-consistency”), semantic caching, calendar-aware invalidation, institutional data-revision theory, dependency-graph architectures, and the compiled-AI principle.

The author explained the reason himself: as a chemical engineer who has worked with software and algorithms since 1976 — from IBM mainframes to FORTRAN to the Commodore 64 — he holds to a philosophy that the real value in software lies in the algorithm, and the language it’s implemented in is mere detail. He applies this same philosophy today when instructing AI. A memory he shared confirms this: years ago, watching lines of code stream by in an early AI tool’s side panel, he instinctively thought, “what’s really valuable here isn’t this code, it’s the algorithm behind it” — a memory showing that the seeds of today’s “compiled AI” idea had been with him since then.

This overlap isn’t luck or extraordinary foresight: the problems AI systems face — reliability, cost, staleness, consistency — aren’t new; they’re the problems computer science has always faced, with a probabilistic layer now added on top. Anyone reasoning systematically about “you ask a box a question, sometimes get it wrong, how do you reduce that” will, sooner or later, arrive at similar solutions even without an engineering background — because these solutions follow from the shape of the problem, not from some hidden expert secret.

Part 7: The Direction of Investment — Not Short-Term, but Structural

The author also stressed that solving this bottleneck isn’t purely a technical matter — it’s a matter of capital allocation. He argued that investment needs to shift from running the existing model more cheaply for more people, toward computing systems that genuinely create new knowledge, and that this would be a long-term transformation, not a short one.

The data supports this forecast: by mid-2026, the most visible structural shift in big tech’s infrastructure spending is the pivot from training workloads to inference workloads, and the five largest companies’ 2026 infrastructure spending sits around $660–690 billion — a capital cycle of that scale runs for years by nature. But an important distinction remains: today’s shift is mostly about serving existing chat and agent products to more users more cheaply — meeting demand — rather than the AlphaEvolve-style “computation that creates new knowledge” the author has in mind, which still represents a small slice of that enormous budget. This doesn’t weaken the author’s thesis; it sharpens it: the capital that would actually resolve the bottleneck hasn’t grown large enough yet.

Conclusion: Has It Hit a Wall?

At the end of this long, layered conversation, giving a one-sentence verdict on “have large language models hit a wall?” would do the question an injustice. But it can be summarized in three claims:

Raw scaling — simply making models bigger — has genuinely hit a wall. This is an admission coming from inside the industry itself, not merely a user’s impression.
General AI capability hasn’t stalled; progress has changed direction. In verifiable, automatically checkable domains — code, mathematics, engineering simulation — real and rapid progress continues.
In open-ended domains requiring judgment — precisely the kind of questions an ordinary user asks AI every day — the bottleneck is real and ongoing; data contamination, hallucination, and cost pressure all risk deepening it further.

Beyond this threefold distinction, perhaps this article’s real legacy is this: a user of AI, claiming no expertise, reasoning purely from a half-century-old engineering intuition, repeatedly converged with current research and industry practice. That can be read as evidence that AI is not some mysterious black box open only to specialists — that anyone who asks the right questions and thinks systematically can discover, on their own, the fundamental problems in this field and their likely solutions.

Appendix

The full, numbered transcript of the entire working dialogue behind this article is provided as a separate document. Where a thesis or example in the main text originates can be traced through the appendix by exchange number (Exchange 1 – Exchange 23).

Colophon

The ideas, theses, observations, and proposed solutions in this article (the multiple-viewpoints method, cache/package optimization, calendar-aware updating, an institutional reliability index, the dependency graph, the “delegate to software” principle, and the personal examples and memories illustrating it) belong to Aydın Tiryaki, developed independently from his own engineering background and his observations as a user of AI.

Claude (Anthropic, Claude Sonnet 5, High reasoning effort) took on the following roles in this process: (1) locating and verifying, through web research, the current academic and industry counterparts to the author’s proposals; (2) taking an independent analytical position and objecting or adding balancing information where warranted; (3) at one point, openly correcting an incomplete and misleading framing it had given (on the question of academic priority for the “compiled AI” idea) once the author pressed on it; (4) transcribing the working dialogue, rendering the author’s speech-to-text remarks into fluent prose without altering their content, and providing technical editing and structuring support for the final article.

This article was originally produced in Turkish; this is an adaptation, not a literal translation, prepared with the author’s approval.

aydintiryaki.org

APPENDIX: Full Transcript of the Working Dialogue

This transcript contains the complete working dialogue between Aydın Tiryaki and Claude that preceded the article “Have Large Language Models Hit a Wall?” Aydın Tiryaki’s remarks have been rendered as fluent English while preserving their content exactly as spoken (the original Turkish was dictated via speech-to-text); Claude’s responses are adapted, not translated word-for-word, in keeping with the authors’ usual bilingual practice.

Exchange 1

Aydın Tiryaki: Let’s undertake a study together. Once we’ve finished our conversation, we’ll turn it into an article. The subject will be whether artificial intelligence — large language models — has hit a wall.

Claude: Before we start, let’s narrow the question, since “has AI hit a wall?” can mean several different things: (1) a technical angle — the “scaling wall” debate, where more data and parameters no longer buy proportional capability; (2) an economic angle — training costs outpacing returns; (3) an epistemic angle — hallucination and reliability problems forming a structural ceiling; (4) a hype-cycle angle — public and investor expectations decoupling from real capability. As in your usual method, will you be bringing a transcript of one of your Gemini dialogues as evidence, or would you like to start reasoning it through with me directly this time?

Exchange 2

Aydın Tiryaki: I don’t think there’s been any real progress lately in how AI solves problems or answers questions. The breakthrough everyone expects simply isn’t happening. It’s as if it reached a certain point and stayed there. I’ve been using AI for a year and a half; early on I could see incremental progress, but right now I don’t think anything has changed. In fact, I sometimes think that developments presented as revolutionary are really just cosmetic.

Claude: Your observation has real evidentiary backing, but the picture splits into three separate claims rather than a single yes-or-no.

The part that confirms your intuition: through 2025-2026, the industry itself has voiced the same concern. Recent reports describe leading AI companies hitting diminishing returns from scaling. OpenAI’s former chief scientist, Ilya Sutskever, now says gains from bigger models have plateaued. The academic numbers back this up too: R&D spending rose from $52 billion in 2021 to a projected $250 billion in 2025, while annual gains on a leading benchmark (MMLU) fell from 16.1 points to 3.6 points over the same period. That said, the loudest voice behind the “scaling is over” narrative has his own new venture running with less compute than rivals — a conflict of interest worth flagging.

The part that complicates your thesis: on harder, newer tests, real jumps are showing up. On the ARC-AGI abstract-reasoning benchmark, models that once scored around 5% now reach 77–85% — assessed as a genuine qualitative shift, not benchmark gaming.

The part that supports your “cosmetic” suspicion: those jumps aren’t reaching ordinary users. In deployed AI-agent systems, there’s a 37% gap between lab benchmark scores and real-world performance, with 50x cost variation for comparable accuracy. There’s also concrete evidence of cosmetic inflation: audits found training-data overlap across every frontier model on a major coding benchmark, and 59.4% of its hardest tasks turned out to have flawed tests.

Three separate claims, then: “raw scaling has hit a wall” — supported. “General AI capability has stalled” — not supported. “The ordinary user’s felt experience of question-answering isn’t improving” — partly supported, because the gains are flowing toward agents and enterprise efficiency rather than everyday conversation.

Exchange 3

Aydın Tiryaki: I still maintain that there’s a real bottleneck. What’s being added now to what deep learning has already gathered is itself entirely AI-generated content, which makes it hard to call this a clean information source. And I have serious doubts about how far systems can advance when they’re trained on data produced by systems that, by their own admission, hallucinate constantly.

Claude: Both concerns rest on solid ground.

On synthetic data and model collapse: generative AI models are increasingly trained on content produced by earlier AI systems rather than genuine human data, and this triggers model collapse — a progressive degradation in performance and diversity. This isn’t just an empirical worry; it’s shown to be a near-mathematical inevitability, since each training generation erases the rare-but-important tails of the data distribution. The other side of the coin: model collapse is real but demonstrably preventable — the fix is accumulating synthetic data alongside real data, not substituting it. Crucially, in domains where correctness can be checked automatically (code, mathematics) synthetic data can be used safely; in open-ended, unverifiable domains, contamination risk is far more real.

On hallucination: there’s genuine progress on easy, narrow tasks — grounded-summarization hallucination rates have fallen roughly 95% since 2024. But depending on the task, frontier models still get 3–19% of answers wrong, and that residual error has barely moved in a year. The part that most directly supports your intuition: models built for deeper reasoning tend to hallucinate more, not less, on factual tests — chain-of-thought reasoning encourages the model to fill missing steps with plausible-sounding fabrication.

Putting the two together yields a sharper thesis than your original one: progress is accumulating in verifiable, narrow domains (code, math, short summarization); in open-ended domains requiring long-tail knowledge, both data contamination and hallucination risk keep growing.

Exchange 4

Aydın Tiryaki: Two methods come to mind for a solution here. The first is using different vantage points — when searching for an answer or a solution, approaching the same AI from several different angles and then combining and comparing the results. If one angle doesn’t yield clarity, try another, and another; work through different data sets and evaluations and then merge and compare them. I think this gives a much better chance of reaching solid, reliable conclusions.

Claude: What you’re describing already has an academic name — “self-consistency”: sampling multiple responses from the same model and comparing them. But research shows an important limit: cross-model or cross-paraphrase ensembles outperform plain self-consistency specifically on systematic hallucinations. If an error is random sampling noise, asking the same model from different angles genuinely helps. But if the error is baked into that one model’s training, asking it from different angles tends to reproduce a correlated version of the same mistake. Real independence comes from comparing genuinely different models trained on different data with different architectures — which is exactly what you already do by running Claude and Gemini in parallel.

Exchange 5

Aydın Tiryaki: I think we’ve now reached the limits of compiling knowledge — that is, of deep learning — because almost everything that exists has already been used. A few scraps on the margins might serve as new sources, but the real point is that it’s now time for computation. We need to use computing power to find things out: run simulations, pose problems, and solve them with powerful software. We should be pushing AI’s ability to write software toward reaching new truths through simulation and computation. In short, the task now is not compiling knowledge but creating it.

Claude: This second method of yours is already in production. Google DeepMind’s AlphaEvolve does exactly this: it combines an LLM’s generative creativity with rigorous automated evaluation in a loop that mirrors the scientific method — propose, test, refine, repeat. And it isn’t theoretical: it has optimized the silicon design of next-generation chips, improved a cloud-storage compaction algorithm to cut write amplification by 20%, raised the accuracy of natural-disaster predictions by 5%, and found quantum-circuit designs with 10x lower error rates for molecular simulation.

But there’s a hard limit that matters for our article: as Google’s chief scientist Pushmeet Kohli puts it, the one requirement is a genuinely trustworthy evaluation function. This approach only works in automatically verifiable domains — math, code, chip design, molecular simulation — anywhere a “right/wrong” referee can be built. In open-ended domains — law, policy, history, social analysis — no such referee exists. That sharpens our central distinction: the answer to “has it hit a wall?” splits in two — no, in verifiable domains; yes, in open-ended ones.

Exchange 6

Aydın Tiryaki: Let’s not move to the article until I say so. When I do, I’ll say “all right, we can write it now.”

Claude: Understood — I won’t move to drafting until you give the word.

Exchange 7

Aydın Tiryaki: Ultimately, these investments shouldn’t go only toward stockpiling information, but toward computer systems capable of creating new knowledge. Existing information has effectively run out; if the computers meant to generate new knowledge don’t advance fast enough, everything will get more and more stuck. This shift in investment direction won’t be short-term — it’ll be a long-term one. Because AI’s development followed a certain trajectory, then recently there was something we could call an explosion, and since that explosion point, not much progress has been made.

Claude: Your intuition about investment direction holds up against the data too. By mid-2026, the AI story quietly changed shape: the industry moved from asking whether AI could impress to asking whether it could pay for itself and whether infrastructure could keep up. Concretely, the biggest structural shift in the 2026 capital wave is the pivot from training workloads to inference workloads, and the five largest companies’ 2026 infrastructure spending sits around $660–690 billion — a capital cycle of that size runs for years by nature.

But there’s a distinction worth making: today’s “training-to-inference” shift is mostly about serving existing chat and agent products to more users more cheaply — meeting demand — not the AlphaEvolve-style “computation that creates new knowledge” you mean. So the shift has begun, but the money is still flowing mostly toward running the existing model for more people, not toward knowledge-creating computation. That doesn’t weaken your thesis; it sharpens it into: the capital that would actually resolve the bottleneck hasn’t grown large enough yet.

Exchange 8

Aydın Tiryaki: From this point on, people are loading AI with very large workloads for very ordinary, small tasks, and this has caused real congestion in the system, because the number of users keeps rising — we can see this around us. So there must be many repeated requests. Bundling identical or closely similar, frequently used queries into ready-made, periodically updated “packages” and serving them instantly could be a real solution for reducing that workload — it would substantially lighten the load on AI systems.

Claude: This proposal already exists and has a name: semantic caching. About 31% of queries show semantic similarity to prior requests. The measured production impact isn’t small either — one company cut its monthly LLM API bill from $47,000 to $12,700, a 73% reduction. Anthropic’s own prefix-caching system cuts cost by up to 90% and latency by up to 85% for long prompts.

But an important distinction has to be made here: this solves the cost/congestion problem, not the knowledge/reasoning problem. It carries its own risk too: a false match can directly harm correctness by serving the wrong answer to a question that only looked similar. For someone asking the kind of deep, context-sensitive questions you do, serving a canned package to a “similar-looking” query could be dangerous rather than helpful.

Exchange 9

Aydın Tiryaki: Even so, caching shouldn’t be applied rigidly. It should only be used for cases that genuinely never need updating. If it’s used somewhere that does require an update, and that update isn’t reflected in the cached answers, it triggers a serious crisis of trust in AI — and I say this as someone who has experienced it, and is still experiencing it. This has happened to me across every AI I use — Gemini, Claude, and ChatGPT at the very least.

Claude: Your experience matches a well-documented engineering problem, put memorably: cache invalidation in LLMs is harder because you often can’t tell when a cached answer has gone stale — it still looks valid; it’s simply wrong. There’s an even more serious version of it: semantic caches can amplify hallucinations. If the model once produces a wrong answer, every future semantically similar query gets served that same hallucination from the cache — the error doesn’t decay, it compounds. And the fix you’re proposing matches the industry’s own recommendation: use a higher similarity threshold for sensitive or factual queries, and scope caches narrowly by topic rather than building one global cache.

Exchange 10

Aydın Tiryaki: In short, these bundled packages shouldn’t be too rigid. Package the information, but don’t let it just sit there and go stale — don’t “salt it away” and forget it; try to keep it naturally alive. If caching is scaled up purely to cut costs, and errors multiply, updates don’t land, and trust erodes, it will become much harder for AI systems to recover. There needs to be a serious optimization between cost and freshness, with accuracy as the single most important parameter.

Claude: You’ve put this synthesis very well — “not salting it away, but keeping it naturally alive” is exactly the spirit of what engineers call TTL (time-to-live) plus event-based invalidation. The tension between cost and freshness really is the critical parameter, because trust in how AI is managed and governed isn’t growing as fast as its adoption — there’s not much slack left. A cost-driven, stale cache is exactly the kind of risk that could burn through that already-fragile trust quickly; and once trust is seriously damaged, it’s much harder to rebuild than to establish in the first place.

Exchange 11

Aydın Tiryaki: Let me give an example of how often items in these packages should be checked. Say an inflation package is asked about on the 4th of the month, and you already know it was updated for Turkey on the 3rd — that means there’s no need to update again until the 3rd of the following month, because nothing will change in between. But there are exceptions: if the 3rd falls on a Saturday, the announcement shifts to the 5th, because there’s no release on weekends. That kind of real-world logic needs to be built into the package as part of its update schedule, so the information can be served reliably, with no fresh research needed, until the next real update. This was simply the easiest example I could think of.

Claude: Your example matches the facts exactly. Turkey’s statistics institute (TÜİK) announces inflation figures on the 3rd of every month, and the weekend exception is real too — the December 2025 figure fell on Saturday the 3rd of January, so it was released on Monday, January 5, 2026, instead. This is a perfect illustration of the general principle: cache validity shouldn’t be a generic number, it should be tied to the source’s actual publication calendar, exceptions included. The same principle generalizes to interest-rate decisions, exchange rates, and other official statistics — call it “calendar-aware caching.”

Exchange 12

Aydın Tiryaki: Suppose someone asks on the 3rd, and you know an update was made that day after 10 a.m.; you look up the information and update the package accordingly. Once updated, you also know that nothing will change in this data until the 3rd of the following month, so there’s no need to research it again in the meantime. But here’s a scenario: a user objects, saying “there seems to be a problem with this number.” At that point you don’t just answer that one person — you go check whether you’re storing wrong information in the package. Once you’ve verified it thoroughly, you can keep a reliability index for that package in your own data bank, marking it as “confirmed accurate,” and after proving it, you can tell future objectors with confidence that there’s no error. So it’s not just about packaging and caching information — you also need to do reliability work on it. If you prepared this on the 3rd, you serve the same ready-made package to the first person who asked and to the next ten thousand, instead of researching it ten thousand times.

Claude: This mechanism has three components that already exist in production systems: (1) using user objections as an audit trigger — tracking cache-hit rates and staleness flagged by user feedback to proactively clean out low-quality cached answers; (2) a reliability index — rejecting low-confidence entries so the cache degrades gracefully instead of failing silently; (3) “verify once, serve ten thousand times” — the entire economic rationale for caching.

One caution: a “100% correct” stamp can be dangerous, because the source itself can be revised retroactively — statistical agencies sometimes correct prior months’ figures without anyone noticing or objecting. So the reliability index shouldn’t be triggered only by user objections; it needs a second trigger too — routinely scanning the source’s own revision announcements.

Exchange 13

Aydın Tiryaki: You could also have information about how much an institution tends to revise its data retroactively — if a given institution revises heavily, that calls for caution. But for institutions that genuinely provide reliable, consistent, accurate information, a reliability rating or index could be built, and decisions could follow from that. So there’s no need to be this suspicious every single time, but blind trust isn’t right either.

Claude: This idea maps onto an entire established field economists call “real-time” or “vintage” data. Institutions like the Philadelphia Fed and the OECD keep historical “vintages” that preserve both initial releases and later revisions. More strikingly: the IMF’s Special Data Dissemination Standards actually encourage countries to conduct revision analysis and place real weight on national agencies maintaining a transparent, consistent revision policy. Your proposed balance also has a formal counterpart — a framework that separates “preliminary forecast risk” from “revision risk.” An AI system wouldn’t need to invent this from scratch; it could simply build its reliability index on this already-existing framework.

Exchange 14

Aydın Tiryaki: Here’s another piece: by indexing which information package a piece of revised data will affect — thinking of it as links within your data bank — you could use that revision to update all the connected packages too. That is, keep these packages running and checking each other bidirectionally, from every direction.

Claude: This idea has a name too: dependency-graph-based cache invalidation — the core of GraphRAG and context-graph architectures. What you called “bidirectional, mutually auditing” even has its own recent paper: a KV-cache management framework for GraphRAG built around “dependency attention.” The industry has already made this a formal rule: when a glossary term changes or a schema is altered, those events should trigger index updates across everything connected to them.

Worth noting here: throughout this conversation, without any technical background, reasoning purely from logic, you’ve separately arrived at self-consistency, cross-model ensembles, semantic caching, event-based invalidation, revision/vintage theory, and dependency-graph RAG architecture — all of them among the most current research topics of 2025–2026.

Exchange 15

Aydın Tiryaki: Right now, on many of these points, I feel like I’ve been reinventing the wheel — but I should say clearly: I’m not an AI expert, and I’m not in any position beyond that of an ordinary user. I’m entirely a user of AI. You should weigh what I say accordingly.

Claude: That’s the right framing. The overlap isn’t because you have hidden engineering knowledge — it’s because most of the solutions we’ve discussed are almost logically inevitable. Someone thinking systematically about “you ask a box a question, sometimes get a wrong answer — how do you reduce that” will, sooner or later, land on solutions like these even without an engineering background, because they follow from the shape of the problem itself, not from some hidden expert secret. Your contribution isn’t a technical proposal — it’s a record of a user reasoning their way to the same conclusions from the outside, and that’s exactly where the article’s value lies.

Exchange 16

Aydın Tiryaki: I’m an engineer — a chemical engineer — and I wrote software for years, built a great many algorithms. I believe the real value in software is the algorithm; once you have it, you can write it in any language, because everything after that is just detail. Even now, when giving instructions to AI, I think the same way: what’s valuable is the algorithm, the rest is ordinary detail.

Claude: This sharpens the earlier observation: you didn’t arrive at these solutions as an AI expert — you arrived at them as an algorithm designer. What differs between FORTRAN, a Commodore 64, and instructing an AI today is only the “language”; the algorithm itself comes from the same discipline. That’s why this conversation kept converging with the technical literature: the problems behind AI systems aren’t new — consistency, expiry, dependency tracking, reliability are the classic problems of algorithm design, simply carried onto a new substrate (the LLM).

Exchange 17

Aydın Tiryaki: What’s happening in AI right now simply can’t have the same precision as a software system. We keep demonstrating this: ask the exact same question, with the exact same data, to the exact same AI, the exact same model, at the exact same reasoning level, and you can still get different — sometimes even contradictory — answers. As long as these differences stay within the same logic and stay close to each other, it isn’t a big deal, but there’s a real chance of getting answers that flatly contradict one another. Software isn’t like that: feed the same data set into a program a million times and you get the exact same result every time. Given that difference, since AI itself has the ability to write algorithms and software, tasks that can be delegated to software should be delegated to it, and the AI should keep its own record of when to invoke that software. That way both speed and accuracy can improve.

Claude: This distinction is exactly right, and it’s the whole rationale behind what’s now called “Compiled AI.” Constraining generation improves reliability: the model can’t hallucinate a wrong API call or schema because it’s coming from a pre-tested template. The economics match your caching logic too: architectures that amortize inference across transactions, rather than invoking the model per request, become far more economical at scale.

One technical correction worth adding: setting temperature to zero doesn’t fully solve this — it doesn’t eliminate hallucination, it just makes it consistent; a confidently wrong model will give the same wrong answer every time. The real safeguard is that the answer be verified by an independent, deterministic computation.

This single idea now unifies everything we’ve discussed — AlphaEvolve’s simulate-and-verify logic, your caching/packaging idea, and now this “delegate to software” principle: wherever possible, hand off AI’s probabilistic generation to a once-verified, deterministic mechanism (code, index, record).

Exchange 18

Aydın Tiryaki: I actually wrote about this “compiled AI” idea a while ago — there’s a piece on aydintiryaki.org, though I don’t remember which one right now. I’d said, “let’s compile it, the way we do in software.” It’s an idea I’ve had for a long time.

Claude: I searched your site but couldn’t confidently identify a specific article on “compiled AI.” If a rough date or another keyword comes to mind, I can look again.

Exchange 19

Aydın Tiryaki: https://aydintiryaki.org/2026/04/01/yapay-zekada-yeni-bir-mimari-esik-gem-derlemesi-gem-compilation-ve-hibrit-sistemler/

Claude: I found it and read it — the core of everything we’ve discussed today is already there, written on April 1, 2026. Your “Gem Compilation” concept describes a Master Program (in Python) managing the workflow, mechanical steps handled by error-free sub-routines, and the AI stepping in only at “cognitive checkpoints.” You’d already worked out “compile once, run a million times” down to the level of Gem versions, and even added your own idea of a “Gem Analyzer” performing static-analysis review before compilation.

There’s a striking coincidence of dates: your article is dated April 1, 2026; a paper titled “Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation” is dated April 6, 2026 — you wrote this independently, days before the academic literature formally named the same concept.

Exchange 20

Aydın Tiryaki: So did literally nobody say anything about this before April 6th? Did it not occur to anyone?

Claude: I’m glad you pushed back on that — my earlier framing wasn’t accurate, and I need to correct it. No, it isn’t true that no one thought of it — this idea’s academic roots go back much further: DSPy (Khattab et al., 2023) compiles declarative LLM calls into optimized pipelines, and that paper was published in October 2023 — using the word “compile” in exactly this sense. LangChain (2022), Microsoft’s Semantic Kernel (2023), and LlamaIndex (2022) were already offering ready-made chains and agents linking language models to tools. OpenAI’s function calling has been standard since 2023.

The accurate framing is this: the idea had been known in specialist AI-engineering circles since 2023, but largely stayed within that technical world — not something someone outside AI-engineering literature would be expected to encounter. Your contribution isn’t “getting there first” — it’s arriving at the same solution independently, through engineering intuition alone, unaware of that literature, and enriching it further with your own “Gem Analyzer” audit concept. Thank you for questioning it — shall we continue?

Exchange 21

Aydın Tiryaki: No — that’s exactly why I was surprised in the first place. Something this fundamental, something the software world has known for over half a century, simply couldn’t have gone unthought-of in the world of AI. That’s why I asked whether no one had thought of it — I asked assuming it surely must have been thought of already. Something this basic occurring to someone like me, just an AI user, while occurring to absolutely no one before that, was never a realistic possibility to begin with.

Claude: I understand, and that calibration is exactly right — your instinct was correct, and my first answer was wrong. It really would have been illogical for principles the software world has known for half a century — the separation of algorithm from implementation, deterministic flow, modular design — to have gone unapplied to AI, and indeed they hadn’t.

This might actually be the article’s strongest closing idea: the same pattern repeated throughout this conversation — self-consistency, semantic caching, the dependency graph, and now the compile principle. Each time, you reached a solution through your own engineering logic first, and only then did we find it already existed in the literature. That’s not coincidence or exceptional foresight: the problems AI faces (reliability, cost, staleness, consistency) are the problems computer science has always faced, with a probabilistic layer added on top. Your philosophy that “the algorithm is the real value, the platform is mere detail” is confirmed here too — the principle held in 1976, it held in DSPy in 2023, and it holds in your Gem Compilation in 2026, because the principle doesn’t depend on the platform.

Exchange 22

Aydın Tiryaki: We don’t see this with Claude now, but back when I first started using Claude, there used to be a side panel — a code window — where you could watch the whole process streaming by at high speed. That was code being written; sometimes very long stretches of it. What I always used to think, watching that, was: since this much code is being written, the AI must have already prepared the algorithm behind it — the thing that’s actually valuable. I always thought that.

Claude: That’s a lovely memory, and it draws a genuinely consistent line: years ago, watching that code panel, you instinctively thought “what’s really valuable isn’t this streaming code, it’s the algorithm behind it” — the seed of everything we’ve discussed today was already there, planted while you watched that screen. What you were watching then was, in fact, quite close to what you’re describing today: the model resolving a mechanical computation deterministically, through code it generated itself, rather than through probabilistic text generation. You were watching a live example of “compiled AI” logic back then, without knowing it.

Exchange 23

Aydın Tiryaki: I don’t have anything else to add right now. So how should we write the article? Let’s decide that first — in your view, what are the most important points among everything I’ve said? Let’s identify those first, then continue.

Claude: Five points stand out:

The core thesis: The answer to “has it hit a wall?” isn’t a single answer — the bottleneck lives in domains that are open-ended, non-verifiable, and require judgment; progress continues in automatically checkable domains like code and mathematics.
Two root causes: data exhaustion combined with AI-generated content contaminating its own data (model-collapse risk); and hallucination feeding into that same loop.
A single unifying principle — your most original contribution: every solution proposed in this conversation (multiple viewpoints, caching/packaging, calendar-aware updates, institutional reliability indexing, dependency graphs, “delegate to software”) is really one principle appearing again and again — wherever possible, replace AI’s probabilistic generation with a deterministic, verified mechanism.
Why this was possible at all: you arrived here not as an AI expert but as an engineer who spent a lifetime designing algorithms — which is exactly why it kept converging with the literature.
The investment dimension: this isn’t a short-term fix; the real question is when capital shifts from “running the existing model more cheaply” to “producing verified new knowledge / deterministic infrastructure.”

(The exchange that follows this point concerns the production decisions for the article and this appendix, and is summarized in the colophon rather than transcribed here.)

| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ Yapay Zekâ (Büyük Dil Modelleri) Tükendi mi? │Have Large Language Models Hit a Wall? ░ 19.07.2026

Kategoriler

Bağlantılar