Enterprise Knowledge Representation: Conceptual Graphs, ISO Common Logic, and SAP Graph Foundations

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part seven: A post by Simon Polovina on the Ontolog Forum in response to the original post by  James Lee Stakelum.

A nicely formatted PDF of the same post is in the resources below.

Resources

References

  • Enterprise Knowledge Representation: Conceptual Graphs, ISO Common Logic, and SAP Graph Foundations, Simon Polovina. August 12, 2026

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Ontolog Forum
  • Home > Handbook > 

Last Updated

24/08/2026

Enterprise Knowledge Representation: Conceptual Graphs, ISO Common Logic, and SAP Graph Foundations

By: Simon Polovina
Ontolog Forum: 12/08/2026

I bring Computer Productivity to Business Creativity by engaging in roles that draw upon my leadership and expertise in Enterprise Architecture and Conceptual Structures, which harmonise computer productivity with human and business creativity. My experience draws on Knowledge Representation and Reasoning, Artificial Intelligence, The Intelligent Enterprise, User Experience (UX), Design Thinking, Cloud, Data Infrastructures, SAP, Web, Service-oriented Architecture (SOA), Object-oriented Analysis and Design, and more. As well as NextGen industrial practice and education, I've published widely, with over 110 learned publications to date.

Abstract

This document presents a comprehensive discussion of the theoretical and practical role of Conceptual Graphs (CGs) in enterprise architectures, their comparative expressivity relative to First-Order Logic (FOL), Description Logics (OWL), and RDF, and their alignment with the ISO/IEC 24707 Common Logic. Additionally, it highlights recent perspectives on trustworthy AI, open vs. closed predicate grammars, and evaluates the comparative landscape of SAP Graph, SAP HANA Knowledge Graph, and SAP Business Data Cloud (BDC) Knowledge Graph across CGIF and CLIF representations.

1 Introduction & Conceptual Graphs Overview

Conceptual Graphs (CGs), developed by John F. Sowa (Sowa 1984), bridge human-readable visual semantics with formal mathematical logic. As introduced in previous foundational work (Polovina 2007), CGs provide a versatile environment for knowledge representation and automated reasoning that directly aligns with enterprise object models.

Key structural advantages of CGs over alternative formalisms include:

  • Visual Syntax with FOL Rigour: CGs use an intuitive visual bipartite graph syntax (concepts and conceptual relations) while maintaining an exact mapping via the -operator to First-Order Logic.
  • Native -ary Relations: Unlike RDF triples (), CGs support -ary relations without artificial reification.
  • Nested Contexts: CGs support nested propositional contexts, allowing clean modal, temporal, and belief representations.
  • Graph-Based Reasoning: Operations such as graph projection, join, and restriction enable sound structural reasoning without requiring resolution theorem provers.

This paper evaluates these theoretical properties within modern enterprise architectures. Specifically, we analyse the trade-offs of RDF-based knowledge foundations in SAP Business Data Cloud (BDC) and demonstrate how ISO/IEC 24707 Common Logic representations (CGIF and CLIF) provide a more robust substrate for neuro-symbolic AI.

2 Trustworthy AI, Common Logic, and Closed Grammars

Recent discussions surrounding multi-agent systems and local-first AI architectures highlight the crucial distinction between open-predicate systems and closed relational grammars (Stakelum 2026). Unconstrained open predicates (found in RDF, OWL, and raw Common Logic) incur an  integration bottleneck (the “Babel Tax”) when federating across independent domains.

By leveraging standardised specifications under ISO/IEC 24707 Common Logic (ISO/IEC 2018), architectures can combine bounded relational primitives with rich, open concept lattices (e.g., via Formal Concept Analysis), enabling sound neuro-symbolic reasoning without hallucination.

3 Comparing SAP Graph Architectures

Enterprise data foundations often combine multiple distinct graph paradigms. Table 1 outlines three core SAP graph technologies.

Comparison of SAP Graph Technologies

Feature/Aspect SAP Graph SAP HANA Knowledge Graph SAP BDC Knowledge Graph
Primary Purpose Unified API graph for cross-SAP integration In-memory graph engine for HANA Cloud analytics Business-context-aware semantic graph for AI
Scope Cross-SAP application data Technical graph database Business processes, roles, and policies
Data Sources S/4HANA, SuccessFactors, etc. Relational, spatial, and vector data in HANA SAP and non-SAP data with embedded context
Deployment SAP BTP SAP HANA Cloud SAP BTP (BDC Architecture)
Query Languages SPARQL, SQL SPARQL, Cypher, SQL SPARQL, SQL
AI Enablement High Medium Very High

Among these paradigms, the SAP BDC Knowledge Graph represents the most context-aware layer for enterprise AI. However, as evaluated in the following section, its technical implementation on an RDF triple-store foundation introduces structural friction that could be mitigated by a Conceptual Graph architecture.

4 Replacing RDF with Conceptual Graphs in Enterprise Data Foundations

Replacing Resource Description Framework (RDF) with Conceptual Graphs (CGs) in enterprise data foundations—such as the SAP Knowledge Graph capability and its technical implementation in SAP Business Data Cloud (BDC)—would fundamentally transform how enterprise AI, multi-agent systems, and business process models interact with underlying ERP data.

While SAP chose RDF for the SAP Knowledge Graph engine in SAP BDC primarily to leverage established SPARQL standards and existing triple-store tech, opting for a Conceptual Graph foundation would have solved several structural challenges inherent to large-scale ERP semantic layers.

4.1         Architectural Impact: RDF vs. Conceptual Graphs in Enterprise Systems
4.1.1     Eliminating -ary Reification in Complex Business Transactions

The RDF Reality: Standard ERP business entities rarely fit neat binary triples (). An SAP purchase order line item involves a vendor, material, quantity, plant, currency, pricing condition, and tax code. In RDF, representing this -ary transaction requires extensive reification or artificial intermediate nodes, bloating the number of triples into the billions and degrading SPARQL join performance.

The CG Advantage: CGs natively support -ary relation nodes linked directly to  concept nodes. A multi-party sales order or supply chain movement remains a single, unfragmented hypergraph node. This drastically reduces graph size, avoids join overhead, and makes the schema mirror actual SAP business objects (BAPIs/IDocs) directly.

4.1.2     Built-in Modal Logic for SAP Business Contexts

The RDF Reality: Enterprise data is deeply contextual. A price isn’t just “100 EUR”; it is valid from date  to , under condition type , within company code , and subject to a pending workflow approval. RDF lacks a native concept of contexts, forcing developers to resort to Named Graphs or  annotations—which break standard triple semantics and fragment reasoning engines.

The CG Advantage: Conceptual Graphs feature nested contexts as a core primitive. A belief state, a temporal validity window, a hypothetical “what-if” planning scenario, or an unapproved workflow step can be cleanly enclosed within a context box. Reasoning rules apply precisely inside specified contexts without leaking state into the broader knowledge base.

4.1.3     Direct Neuro-Symbolic Grounding for AI Agents (Joule & LLM Orchestration)

The RDF Reality: Modern enterprise architectures (like SAP’s Business AI Hub and SAP Knowledge Graph) use Knowledge Graphs to ground LLM agents and prevent hallucinations. However, converting LLM outputs into SPARQL triple patterns is notoriously fragile due to predicate drift, URI matching issues, and rigid triple structures.

The CG Advantage: CGs support graph projection—a sound and complete mechanism for pattern matching. An LLM acting as an abductive engine can propose a tentative solution in Conceptual Graph Linear Form (CGLF/CGIF). The engine uses projection to test if the proposed structure is a valid specialisation of an existing business rule or schema. If the projection fails, the logic engine rejects the hypothesis or pinpoints the exact ungrounded concept.

4.1.4     Convergence with ISO Standards

While RDF is a W3C web recommendation optimised for web-scale linking, CGs align directly with ISO/IEC 24707 Common Logic (ISO/IEC 2018). In enterprise ERP systems where auditability, compliance, and deterministic business rules are non-negotiable, having an underlying representation that translates losslessly into First-Order Logic provides a stronger governance guarantee than triple-store heuristics.

Structural Dimension SAP Knowledge Graph on RDF (in BDC) Conceptual Graph Alternative
Transaction Modelling Fragmented into binary triples via reification Native -ary structures preserving event unity
Business Contexts & Rules Named Graphs / Annotations (Ad-hoc) First-class Nested Contexts
Reasoning Mechanism Tableau-based subsumption / RDFS rules Graph Projection, Join, and Restriction
Agent AI Grounding SPARQL translation (prone to join complexity) Structural graph projection & unification
Schema Complexity Quadratic expansion of edge types (Babel Tax risk) Compact type hierarchies mapped to business objects


4.2 Why Didn’t SAP Do It?

The barrier has never been theoretical superiority—it has been ecosystem momentum. The RDF/SPARQL stack offered off-the-shelf open-source parsers, mature triple-store database engines, and an established developer base familiar with Semantic Web tooling. Implementing CGs natively would have required SAP to build and maintain a commercial-grade ISO Common Logic graph engine from scratch.

However, as enterprise systems pivot toward neuro-symbolic AI and local multi-agent orchestration, the architectural overhead of triple stores is becoming a bottleneck. Systems designed around -ary events, nested contexts, and graph projection are proving far better suited for grounding autonomous agents than legacy triple stores.

5 Formal Logic Representations: CGIF and CLIF
5.1 Conceptual Graph Interchange Format (CGIF)

Below is the linear CG serialisation of the comparison among the three SAP technologies, adhering, through CGIF,  to ISO/IEC 24707 standards (ISO/IEC 2018).

[Comparison: Study_SAP_Graphs] -
   (compares)-> [Technology: SAP_Graph],
   (compares)-> [Technology: SAP_HANA_Knowledge_Graph],
   (compares)-> [Technology: SAP_BDC_Knowledge_Graph].

[Technology: SAP_Graph] -
   (primaryPurpose)-> [Purpose: "Unified graph service for cross-SAP application integration"],
   (scope)-> [Scope: "Cross-SAP application data integration"],
   (deployment)-> [Platform: "SAP BTP"],
   (aiEnablement)-> [Rating: "High"].

[Technology: SAP_HANA_Knowledge_Graph] -
   (primaryPurpose)-> [Purpose: "Graph engine for storing/querying connected data in SAP HANA Cloud"],
   (scope)-> [Scope: "Technical graph database in HANA Cloud"],
   (deployment)-> [Platform: "SAP HANA Cloud"],
   (aiEnablement)-> [Rating: "Medium"].

[Technology: SAP_BDC_Knowledge_Graph] -
   (primaryPurpose)-> [Purpose: "Business-context-aware graph for AI-driven process automation"],
   (scope)-> [Scope: "Business semantics, processes, and context"],
   (deployment)-> [Platform: "SAP BTP"],
   (aiEnablement)-> [Rating: "Very High"].

5.2         Common Logic Interchange Format (CLIF)

The corresponding ISO 24707 CLIF representation provides a direct Lisp-style S-expression syntax suitable for first-order logic provers.

(cl-text SAP_Graph_Comparison_Ontology

  (cl-comment "Root Comparison Structure")
  (Comparison Study_SAP_Graphs)
  (compares Study_SAP_Graphs SAP_Graph)
  (compares Study_SAP_Graphs SAP_HANA_Knowledge_Graph)
  (compares Study_SAP_Graphs SAP_BDC_Knowledge_Graph)

  (cl-comment "SAP Graph Assertions")
  (Technology SAP_Graph)
  (primaryPurpose SAP_Graph "Unified graph service for cross-SAP application integration")
  (deploymentEnvironment SAP_Graph SAP_BTP)
  (aiEnablementLevel SAP_Graph High)

  (cl-comment "SAP HANA Knowledge Graph Assertions")
  (Technology SAP_HANA_Knowledge_Graph)
  (primaryPurpose SAP_HANA_Knowledge_Graph "Graph engine for storing/querying connected data in SAP HANA Cloud")
  (deploymentEnvironment SAP_HANA_Knowledge_Graph SAP_HANA_Cloud)
  (aiEnablementLevel SAP_HANA_Knowledge_Graph Medium)

  (cl-comment "SAP BDC Knowledge Graph Assertions")
  (Technology SAP_BDC_Knowledge_Graph)
  (primaryPurpose SAP_BDC_Knowledge_Graph "Business-context-aware graph for AI-driven process automation")
  (deploymentEnvironment SAP_BDC_Knowledge_Graph SAP_BTP)
  (aiEnablementLevel SAP_BDC_Knowledge_Graph VeryHigh)

  (cl-comment "General Inference Rule")
  (forall (x)
    (if (and (Technology x)
             (deploymentEnvironment x SAP_BTP)
             (aiEnablementLevel x VeryHigh))
        (BusinessContextAware x)))
)

6 Conclusion

While modern enterprise platforms such as SAP Business Data Cloud have successfully adopted RDF triple stores to build context-aware Knowledge Graphs, standard binary triple models introduce significant overhead when representing complex -ary business transactions and nested modal contexts. As demonstrated in this analysis, adopting Conceptual Graphs (CGs) directly resolves these structural bottlenecks through native -ary relations, first-class nested contexts, and graph-projection reasoning.

Furthermore, grounding enterprise architectures in ISO/IEC 24707 Common Logic provides the deterministic First-Order Logic rigour required for trustworthy neuro-symbolic AI and autonomous agent orchestration. By formalising enterprise semantic layers in standardised serialisations like CGIF and CLIF, enterprise architectures can bypass the combinatorial integration challenges of unconstrained open predicates while guaranteeing verifiable, hallucination-free decision support across complex business domains.

References

  1. ISO/IEC. 2018. ISO/IEC 24707:2018 Information technology — Common Logic (CL): A framework for a family of logic-based languages. International Organization for Standardization.
  2. Polovina, Simon. 2007. “An Introduction to Conceptual Graphs.” In Conceptual Structures: Knowledge Architectures for Smart Applications. Proceedings of the 15th International Conference on Conceptual Structures (ICCS 2007), edited by Uta Priss, Simon Polovina, and Richard Hill, vol. 4604. Lecture Notes in Artificial Intelligence. Springer-Verlag. https://doi.org/10.1007/978-3-540-73681-3_1.
  3. Sowa, John F. 1984. Conceptual Structures: Information Processing in Mind and Machine. Addison-Wesley.
  4. Stakelum, James Lee. 2026. The Architecture That Makes AI Trustworthy Wasn’t Invented. It Was Discovered. Review of the Ontology Summit 2026 Presentation by Arun Majumdar and John F. Sowa.
By , No comments:
Tags , ,

You Will Be Accused of Using AI. Here Is How to Prove You Wrote It

Mike's Notes

This Substack post by Dr Sam Illingworth lists 8 useful steps to prove authorship. For future reference.

Resources

References

  • Slow AI: Knowing When to Use AI and When to Leave It Alone, Sam Illingworth, 2026. Kindle.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

23/08/2026

You Will Be Accused of Using AI. Here Is How to Prove You Wrote It

By: Dr Sam Illingworth
Substack: Slow AI: 07/08/2026

Sam Illingworth is a Professor of Critical AI Literacy at Edinburgh Napier University, where his work looks at how we use artificial intelligence with judgement: when it helps, and when to leave it alone.

He is the founder of Slow AI, a newsletter on using AI with judgement, and the author of Slow AI: Knowing When to Use AI and When to Leave It Alone. He has written and presented for the BBC, and his work has appeared in Nature, Scientific American, and The Conversation.

His path runs from atmospheric physics to poetry, and he still uses poems and games to open up conversations across communities. He lives in Edinburgh, and he is still learning to take his own advice.

...

A novelist lost two million dollars because nobody could show how his book was written. Your record takes twenty minutes.

...

Jerry Falade’s own agents took his book away from him. His debut crime novel drew a two-book offer from Minotaur reported at more than two million dollars, people who had read the manuscript started saying it looked like AI, and within days his own representatives withdrew it, because they could no longer establish how it had been written.

In this post I will:

  • Show you exactly what the evidence in this case was.
  • Give you the audit trail to build, and the two steps that matter if you only have twenty minutes.
  • Say plainly how I use AI to write this newsletter, including the bit where a detector calls me a machine.

Most of you are writing a newsletter, or a dissertation, or a report your manager will read on a train. The mechanism that ended Jerry Falade’s deal is the one now sitting under all of it.

Call Me, I’ll Hide the Body went to a fourteen-way auction and drew that offer from Minotaur, an imprint of Macmillan US. Reports of the figure vary from two to two and a half million. His co-agents at Europa Content, Marc Gerald and Ashley Coleman, pulled it.

Falade denies using AI.

“The accusations are wrong, and I am completely innocent,”

he told the reporter Jeff Sneider. Adding:

“I was on the verge of success, and then all of a sudden, there were rumors, but no one asked me anything. I don’t know why my agency did not have my back.”

Accusation is now one tap away

As I have previously discussed Substack partnered with the detector Pangram on 21 July 2026. Any reader on web or iOS can press a button on an eligible post and get a number back about whether a human wrote it.

LinkedIn have now also added a button that lets users report posts as AI-generated slop, on a platform that spent two years encouraging everyone to generate posts using AI. Your university has a detector. Your publisher has a policy.

The tools to accuse you are one tap from every reader you have, and none of them come with a standard of proof.

The evidence was a book review

The case against Falade’s manuscript, as reported, was three things:

  1. Negative parallelism, meaning sentences built on ‘this, not that’.
  2. Off-kilter metaphors.
  3. A flat prose style.

Those are criticisms. They belong in a workshop, or a two-star Goodreads review, or the margin of a first draft. Every one of them describes a large quantity of published human writing, some of it very good.

There is a second strand. The Bookseller reports a meeting on 29 July at which aspects of Falade’s account changed, and that this is what triggered the withdrawal. However, the agency has so far produced no detector log, no set of drafts, no version history, and no timestamp.

Sandy Hodgman of Hodgman Literary, who handled the potential foreign and UK rights, put it like this:

“Unfortunately, we are no longer able to authenticate how the manuscript fully evolved from origin to completion.”

They had accepted his assurances at first. Then they could not substantiate them, so the book was withdrawn.

Who is being asked to prove themselves

This is already happening at scale. Hachette cancelled the US release of Shy Girl by Mia Ballard in March 2026 and withdrew the UK edition, after a lengthy investigation prompted by evidence the New York Times brought to it. Ballard says an acquaintance she hired to work on an earlier self-published version used AI without her knowledge, and she has told the New York Times she is pursuing legal action.

Falade is a young Black writer and a doctoral student. He has said publicly that three Black authors landed major deals this year and all three saw those deals cancelled or disrupted after AI suspicion.

As I have written about numerous times now, researchers at Stanford, writing in 2023, ran seven widely used detectors over 91 essays written by non-native English speakers. Across the seven, the average false-positive rate on that human writing was 61.3%, and 97.8% of the essays were flagged as AI by at least one detector. The same detectors read US eighth-grade essays with near-perfect accuracy. Careful, standard, unadorned prose looks machine-made to many of these AI detectors, and that describes most people writing in a second language and most people taught to write formally.

The error in the Stanford study fell overwhelmingly on one group of writers. When the tool is uneven, asking who keeps getting called out is a reasonable question.

What produced the verdict in the Falade case was rumour, a changed story, and a reading of the prose, with no record on either side.

How to build an audit trail, starting today

An audit trail is a record of how a piece of writing came to exist, made while you are writing it.

Here is how to create an audit trail for your own work. If you have twenty minutes, do 1 and 4. Version history and an AI log cover most of what anyone will ever ask you for.

  1. Write somewhere that keeps its own history. Google Docs keeps full version history for free, and so does Word with AutoSave on. Substack’s own editor keeps drafts and revision timestamps, so if you draft in the app you already have more than you think. Version history is the single strongest artefact you can hold, because the timestamps are set as you go. You can’t manufacture three weeks of edits after an accusation arrives.
  2. Keep the ugly early drafts. Do not overwrite. Save dated copies at real milestones: the first mess, the structural rewrite, the version you sent to a friend. Five saved drafts across three weeks say more than any detector output ever will.
  3. Keep your raw input, whatever form it takes. This might be the photograph of a notebook page, a voice memo in the car, a scribbled outline, or the twenty-eight-tab research session you had open. Keep it.
  4. Log the AI, specifically. If you use AI in your writing process than keep a single running file per project. One line per session, copy this shape: 

    2 Aug | Claude Opus 5 | structural edit, section 3 | took the reordering | rejected the new opening Date, tool, what you asked for, what you took, what you refused.

    This is the artefact almost nobody has, and it is the one that answers the question Falade’s agents actually asked.
  5. Ask your editors and contractors what they use. Ballard’s account of her own case turns entirely on this: work she paid someone else to do, using tools she says she did not know about. If you hire a developmental editor, a copyeditor, a ghostwriter, a VA, or a cover designer, put one line in the agreement asking them to disclose AI use and to keep their own drafts. You are responsible for work that goes out under your name, including the parts you did not do.
  6. Keep your research trail. Sources, links, saved PDFs, and notes on what you read and when. A piece that can name where every claim came from reads as researched, because it was.
  7. Write your AI use statement before anyone asks for it. Three or four sentences on how you work, published somewhere durable: an about page, a pinned post, the back matter of a book. Here is a template to adapt:

    I use [tool] for [specific tasks: research scanning, structural feedback, proofreading, and image generation]. I do not use it to [generate first drafts / write in my voice / produce the arguments].

    An accurate statement about heavy AI use is worth more than a flattering one that falls apart.
  8. Put a provenance clause in the contract. For book deals and commissioned work, agree upfront what evidence you would provide, to whom, on what timescale. Publishing contracts routinely carry an AI warranty now. Very few of them define what proof would look like, or name who decides. Get that written down while everyone still likes each other.

Do you know someone who is being falsely accused of using AI in their writing? Then please share this with them.

This is not a guide to evading detection

Some people will read those eight steps as advice on how to look human.

Writing to beat a detector means changing your sentences to fool a classifier. It makes your prose worse, it is a losing game against a system that updates without telling you, and it is dishonest.

Building an audit trail means keeping a record of what you did. It changes nothing about your writing. It works whether you use AI heavily, lightly, or not at all, because the record simply says what happened.

If you have never used AI and you kept nothing, you are as exposed as anyone else here, and that is the unfairness at the centre of this. Your defence is a record, and you deserved to be believed without one. Unfortunately many will not.

My own trail, since I am asking for yours

Pangram scores my writing as 100% AI generated. The maximum the system gives. I wrote about the rollout in Substack’s AI Detector and the Return of the Witch Hunt, where that post scored 100% machine and a humanised version of the same text scored 100% human.

My writing is AI assisted, and I have never once claimed otherwise. So the score describes the surface of the text. It says nothing about how the text was made, and that is what anyone actually wants to know.

Here is mine, written out, because I am asking you to write out yours.

Finding the subject. I watch what my own readers argue about in the notes, and I run agent checks across social platforms and news feeds to see what is surfacing and what is already exhausted. The machine does the scanning. I decide what matters this week from what comes back.

Drafting. I mostly do this via Whisper Flow and I speak the draft out loud, making edits as I go, combing it with snippets of notes that I have taken during the week via the research phase.

Editing. I hand the draft to Claude and ask it to peer review, to argue with the structure, and to suggest edits. I also run a persona check, five imagined readers from a near non-user to a hostile expert, to find where the piece loses people. I take some of it and ignore plenty.

Everything around the words. The SEO, metadata, and artwork are all generated using AI.

Then there is my thesis

Take something you wrote before ChatGPT existed and put it through a detector. Use something old, where you already know the answer.

I ran my PhD thesis. Atmospheric physics, submitted in 2010, at a point when the technology being accused of writing it was more than a decade from public release. Running it through a detector in 2026 returns around 70%.

A physics thesis is exactly the careful, formal, low-perplexity register that the Stanford study found classifiers flag.

A detector tells you one thing: that a piece of text resembles a statistical distribution. The question in the room is who wrote it, and no detector has ever answered that one.

Why this matters

None of this should be your job. You should be able to write a book, sell it, and have the people who represent you assume you wrote it. That world is gone, and I am not going to insult you by pretending it comes back if we are patient.

Two years ago the burden of proof sat with the accuser. It has moved. As I wrote in Guilty Until Proved Human, we now start from suspicion and work backwards, and the person carrying the cost is the one being asked to prove a negative, which cannot be done. What you can do is make the question answerable.

Falade lost a two million dollar deal in the gap between an assurance and a record. Fill your gap this week. Turn on version history, start the log, and write the four sentences about how you work.

As you do this, notice who gets asked to prove the provenance of their writing, and who never gets asked at all.

What is your process? Tell me in the comments how you actually write, AI or no AI. There will be no judgement here, as I would like this thread to be a safe space where we can learn from each other as readers, and writers, and humans.

Go slow.

By , No comments:
Tags ,

Chief Economist’s View: Give Me Chastity But Not Yet

Mike's Notes

Gary Marcus's latest post in Marcus on AI referred to an article on X by Peter Berezin, Chief Economist & Head of CoreMacro. The full report is behind a client-only firewall.

Also, links to some of Ed D'Agostino's recent articles from Global Macro Update on college and healthcare costs.

Plus an essay from James Miller, a video interview with Ray Dalio, Semianalysis on power usage, and Gennaro Cuofano on the 1873 crash.

AI, healthcare and education are good things for humanity. Private equity greed often wrecks everything it touches.

In summary, hype, bloat, and waste at a macro level. And now there is a big bubble and growing mountains of debt. Why is that?

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Business Engineer
  • Home > Ajabbi Research > Library > Subscriptions > James Miller’s observations
  • Home > Ajabbi Research > Library > Subscriptions > Global Macro Update
  • Home > Ajabbi Research > Library > Subscriptions > Marcus on AI
  • Home > Ajabbi Research > Library > Subscriptions > SemiAnalysis
  • Home > Handbook > 

Last Updated

23/08/2026

Chief Economist’s View: Give Me Chastity But Not Yet

By: Peter Berezin
Chief Economist’s View: 19/08/2026

Chief Economist & Head of CoreMacro. Peter is BCA's Chief Economist & Head of CoreMacro.

He lead's firm's efforts to analyze global macroeconomic trends and their implications for financial markets. He also designed the firm's Equity Analyzer platform and its state-of-the-art quant model, MacroQuant.

Before joining BCA in 2010, Peter was a Senior Global Economist with Goldman Sachs. He began his career at the International Monetary Fund in program negotiations, surveillance, and research. He also helped produce the IMF’s flagship report, the World Economic Outlook.

Peter holds a Bachelor of Arts in Economics from McMaster University, a Master of Science from the London School of Economics, and a PhD in Economics from the University of Toronto.

...

$10 Trillion In Annual AI Revenue May Be Necessary To Monetize All The Capex Being Plowed Into Data Centers

Hyperscaler capex is expected to reach $1 trillion in 2027, most of which will be AI-related. Let us assume that a capex bust is avoided and capital spending remains at $1 trillion. Let us also assume a blended depreciation rate of 13%, which is roughly what the hyperscalers are currently assuming.

In steady state, the gross value of hyperscaler assets will then converge to 1/0.13=$7.7 trillion, with $1 trillion in annual depreciation expense. Using a straight-line depreciation approach, the net stock of hyperscaler assets will settle at about 0.5*7.7=$3.8 trillion.

The hyperscalers currently enjoy a pre-tax return on invested capital of 30%-50%. Just to steelman the argument, let us use the lower end of that range. In that case, they would need to generate 0.3*3.8=$1.2 trillion in annual EBIT, implying 1+1.2=$2.2 trillion in EBITDA. 

Analysts expect the EBITDA margins for the hyperscalers to rise to around 50% by the end of the decade. If they were to achieve this, they would need to generate 2.2/0.5=$4.3 trillion in annual revenue. That is $526 for every man, woman, and child on Earth. However, if EBITDA margins were to fall back to 30%, which is what they were in recent years, the required revenue would rise to 2.2/0.3=$7.2 trillion. 

Keep in mind that the foregoing calculation does not even include revenue from SpaceX, the neoclouds, or Chinese AI companies. If one were to include those companies and others, we are potentially talking about AI needing to generate $10 trillion in annual sales to justify all the capex being thrown at it.

For reference, global spending on food (including restaurants) is around $10 trillion. Health care is about the same amount. The entire global software market is only $1.4 trillion. 

Clients can read the rest of the report here:

https://www.bcaresearch.com/reports/chief-economists-view-give-me-chastity-not-yet-19-08-2026/224466

Will Hyperscaler EBITDA Margins Continue To Rise?

Executive Summary

Top Takeaway: Wall Street analysts expect record-high earnings growth on top of record-high profit margins. While stocks could rise into year-end, the longer-term outlook for equities is unfavorable.

  • AI companies may need to generate $10 trillion per year in revenue to justify the capex that is being plowed into data centers. This is roughly equivalent to annual global spending on food or healthcare.
  • Fortunately for the AI trade, hardware shortages remain acute. As such, while the risks to stocks are tilted to the downside over a 12-month horizon, it is too early to tactically position for a bear market.
  • I would turn structurally more bullish on stocks if productivity growth were to accelerate. However, with US productivity growth clocking in at close to the 10-year average in Q2, so far there is little evidence of that.
  • One reason that oil prices have fallen from their peak is that rising crack spreads have reduced the demand for crude. That is not a particularly encouraging sign for the global economy.
  • Kevin Warsh's unwillingness to discuss the Fed's reaction function has increased uncertainty over the rates outlook, lifting bond yields in the process. Against the backdrop of a tightening labor market, yields are unlikely to fall much over the coming months.
  • By itself, the recent intervention to support the yen will probably be insufficient. More fundamental factors such as lower oil prices or weaker global growth will be necessary.
  • That said, the yen is extremely cheap by conventional valuation measures and has weakened more than one would have predicted based on changes in interest rate differentials. Thus, the long-term upside potential for the currency is large.

By , No comments:
Tags , , , ,

cf-indexnow: Submit URLs to search engines from ColdFusion

Mike's Notes

Useful. Filed away for future implementation.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > CFBreak
  • Home > Handbook > 

Last Updated

21/08/2026

cf-indexnow: Submit URLs to search engines from ColdFusion

By: James Mobeg
MyCFML: 19/08/2026

myCFML is the developer Blog of James Moberg, Senior Web Application Developer at SunStar Media. Featuring CFML-related articles and best practices.

IndexNow is an open protocol introduced by Microsoft Bing and Yandex in 2021. It lets a website notify search engines the moment a URL is added, changed, or removed instead of waiting for the next crawl. You POST a list of URLs along with a key that proves you control the host, and the submission is automatically shared with every participating engine: Bing, Yandex, Seznam, Naver, and Yep. (Google doesn't participate, but Bing results also feed DuckDuckGo, Yahoo, and others, so one ping still covers a lot of ground.)

I've published cf-indexnow, a CFC that implements the protocol for Adobe ColdFusion 2016+ and Lucee 5+. It's MIT licensed and I'm using it in production. IndexNow.cfc is the only required file:

indexNow = new IndexNow( host="www.example.com", key="yourindexnowkey" );
result = indexNow.submitUrl( "https://www.example.com/new-article" );
if ( !result.success ) {
 writeLog( file="indexnow", text=result.message );
}

Network problems and API rejections never throw. Every submission returns a struct with success, the HTTP statusCode, a plain-English message, how many URLs were submitted, which input URLs were skipped, and the raw per-batch responses. Invalid constructor arguments do throw (with typed exceptions like IndexNow.InvalidKey), so configuration mistakes surface during development rather than in a production log.

submitUrls() accepts an array and automatically splits anything over 10,000 URLs into multiple POSTs, which is the protocol's per-request limit. submitSitemap() fetches a sitemap.xml, recurses into sitemap index files, and submits every URL it finds. In both cases, URLs that don't belong to the configured host are filtered out and reported in the result instead of being submitted, because a single foreign URL will get an entire batch rejected with a 422.

The key file

Ownership is proven with a plain text file at https://yourhost/{key}.txt containing nothing but the key. The component handles the lifecycle: generateKey() mints a spec-compliant key, writeKeyFile() writes the file to your webroot, and verifyKeyFile() fetches it over HTTP and confirms the content matches before you submit anything.

You don't need to store the key anywhere. I derive it from the hostname so every site gets a stable key with zero configuration:

indexNowKey = "indexnow-" & lcase( hash( cgi.server_name ) );

My scheduled task calls verifyKeyFile() first and regenerates the file if it's missing or wrong. It costs one HTTP request.

Only submit what changed

The spec asks you not to resubmit unchanged URLs, so you need to track state somewhere. I added a nullable IndexNowDate column to the content table. Inserts and edits clear the column; a scheduled task submits whatever is pending and stamps the date on success:


qry = queryExecute( "SELECT ID, 'https://#websiteHost#' + Permalink AS Permalink
 FROM Posts WHERE IndexNowDate IS NULL", {}, {} );
batchResult = indexNow.submitUrls( urls=valueArray( qry, "Permalink" ) );
if ( batchResult.success ) {
 queryExecute( "UPDATE Posts SET IndexNowDate = SYSDATETIME() WHERE ID IN (:ids)",
 { "ids": { "value": valueList( qry.ID ), "list": true, "cfsqltype": "cf_sql_integer" } }, {} );
}

Two behaviors worth knowing. Deleted pages should be resubmitted, not skipped: the spiders re-fetch the URL, see the 404 or 410, and drop it from the index. And when a URL gets a 301/302 redirect, submit the old URL too so the engines learn about the move.

A ColdFusion 2016 workaround

An IndexNow key is allowed to be all digits, and that's how I learned something I hadn't run into before. On ColdFusion 2016, serializeJSON() converts a numeric-looking string into a JSON number even when it's wrapped in toString() or javacast("string", ...). A key of "12345678" goes over the wire as "key":12345678 and the API rejects the submission with a 403. CF2016 is the only platform that does this. ColdFusion 2018+, Lucee, and BoxLang all keep the string quoted. (I verified this on ACF 2016.0.17 by asserting against the raw request body; if you round-trip through deserializeJSON() to test it, the coercion is invisible.)

The fix is Nathan Mische's JSONUtil, which serializes values by their actual underlying Java type. Rather than making it a hard dependency, it's a constructor option:

indexNow = new IndexNow( host="www.example.com", key="12345678", useJSONUtil=true );

The default uses native serializeJSON(), which behaves correctly on every current engine. I enable useJSONUtil anyway. It's a little slower, but JSONUtil is stricter, which I like: deserializeJSON( JSONvar=body, strictMapping=true ) throws when the JSON contains duplicate keys (BoxLang behaves the same way, while Adobe ColdFusion silently accepts them), and it avoids another long-standing Adobe frustration when debugging or transforming data: every ACF version re-orders keys alphabetically when deserializing, while Lucee and BoxLang honor the original key order.

Testing

The repo includes a framework-free test harness: 38 tests that run against a local mock endpoint, so the suite never contacts the real API. It's verified green on Adobe ColdFusion 2016 and Lucee 5.4. There's also a demo page that exercises the whole flow against the mock, plus a localhost-only smoke test page for a one-time check against the live endpoint with a real key.

Grab it at github.com/JamoCA/cf-indexnow. If you hit an engine quirk I missed, open an issue and let me know.

By , No comments:
Tags ,

IT-ontology. one more definition

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part six: A post by Michael DeBellis that criticises something John F Sowa wrote on the Ontolog Forum and James Lee Stakelum's views on SGF. I added the names of people quoted to make the robust exchange of views clearer for me.

Resources

References

  • A Universal Moral Grammar (UMG) Ontology, Michael DeBellis, 2018.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

20/08/2026

IT-ontology. one more definition

By: Michael DeBellis
Ontolog Forum: 19/08/2026

Michael DeBellis is a Semantic Web and AI consultant and researcher with over 40 years of experience in industry and academia. He began designing ontologies in the early 1980s while building expert systems for Accenture and later worked as a researcher at USC’s Information Sciences Institute (ISI), where he used Loom — a direct predecessor to the Web Ontology Language (OWL). Throughout his career at firms including Deloitte, Accenture, and ThoughtWorks, he has focused on applying advanced technology to real-world enterprise challenges. His work emphasizes the practical integration of Semantic Knowledge Graphs into complex systems, highlighting the importance of user requirements, legacy data, and enterprise architecture over purely theoretical modeling. He has published and presented internationally on a broad range of topics across multiple domains​.

John F Sowa

Protégé was designed to use OWL,  which is dead end technology.  There is a huge amount of obsolete OWL software, and it must be supported indefinitely.  But new applications should never be based on OWL.  

Michael DeBellis

That's a pretty strong statement and I didn't see anything strong enough to support such a statement in the linked to article: https://medium.com/@JamesStakelum/why-the-triple-is-the-wrong-grain-1cad99e136f4

For example he says: 

James Lee Stakelum

Failure 1: The triple cannot represent an event as a whole.

RDF/OWL representation (five triples):

:Beethoven rdf:type :Composer .
:NinthSymphony rdf:type :Symphony .
:Beethoven :composed :NinthSymphony .
:NinthSymphony :composedIn :Vienna .
:NinthSymphony :composedInYear "1824" .

Michael DeBellis

And contrasts that with: 

James Lee Stakelum

SGF provides the Synapse — a hub‑and‑spoke structure. The verb is the hub (the VerbHub). Participants attach through exactly 15 fixed semantic roles.

Synapse: s1
VerbHub: compose
HAS_AGENT: Beethoven
HAS_PATIENT: Ninth_Symphony
HAS_LOCATION: Vienna
HAS_TIME: 1824

One object. The VerbHub is not an edge label. The event is whole. 

Michael DeBellis

You could do that with OWL too. Create a subclass of Event called Compose:

Event: Compose_Ninth_Symphony
rdf:type: Compose (subclass of Event)
HAS_AGENT: Beethoven
HAS_PATIENT: Ninth_Symphony
HAS_LOCATION: Vienna
HAS_TIME: 1824

I had a model exactly like this, including using a property called has_patient for Agents that were impacted by an Event, in the first OWL ontology I ever wrote about called the Universal Moral Grammar. https://www.academia.edu/53542647/A_Universal_Moral_Grammar_UMG_Ontology  

His argument about not being able to define provenance also seemed weak:

James Lee Stakelum

Failure 2: The triple cannot carry its own provenance.

:Beethoven :composed :NinthSymphony .

This triple is structurally identical whether it came from a scholarly biography or a random comment. Named graphs are optional — provenance can be stripped in transit.

This is a limitation of OWL compared to Property Graphs if we are just talking about properties. In OWL there is no way to associate metadata with a specific triple because the triple is implicit, there is no data structure for each instance of a relation. But he actually describes a solution to this when he says "Named graphs are optional — provenance can be stripped in transit." This is one thing I've come to realize in the last few years going from prototypes to actual systems integrated with real data: named subgraphs are essential for many use cases of large RDF graphs in the real world. E.g., in Stardog they aren't optional. You have to put certain kind of data such as data inferred by the reasoner, into specific sub-graphs. 

Michael DeBellis

I agree, one obvious use for subgraphs is for metadata, another is for defining security and encapsulation boundaries. But the fact that they are optional hardly seems like a reason to just completely throw OWL away. You can just make them non-optional with standards the way Stardog does. And you can also deal with the property problem by just reifying the property. I.e., turn a property into a class so when you create an instance of the relation you create an instance of the class. This pattern is much older than OWL. It's one of the most standard patterns used in OOP.  I imagine most readers know it well but in case you don't: https://www.w3.org/TR/swbp-n-aryRelations/

In this example, we already did the reification in the previous case when we created a subclass of Event called Compose. We could use that to solve the provenance problem as well: 

Event: Compose_Ninth_Symphony
rdf:type: Compose (subclass of Event)
HAS_AGENT: Beethoven
HAS_PATIENT: Ninth_Symphony
HAS_LOCATION: Vienna
HAS_TIME: 1824

has_source: https://en.wikipedia.org/wiki/Symphony_No._9_(Beethoven)

He also says:

James Lee Stakelum

Failure 4: The triple cannot carry its own grounding.

The URI :Beethoven points to a document, not a concept. Is it the composer, the dog, the crater? 

Michael DeBellis

That's not true. Just because it is an IRI doesn't mean it points to a document. He's confusing IRIs and URLs. 

And his solution is:

James Lee Stakelum

The triple cannot carry its own disambiguation. Therefore every identifier must carry its own sense‑level distinction and trace to a shared foundation.

SGF provides the Canonical ID: en.beethoven.ludwig_van_beethoven.person.core. The microgloss ludwig_van_beethoven distinguishes this sense from others. Every Canonical ID has a finite IS‑A path to the Prime Registry — approximately 65 irreducible semantic primes (DO, HAPPEN, SOMEONE, SOMETHING, GOOD, BAD, etc.). Paths terminate at primes. No infinite regress.

Michael DeBellis

That kind of universal ontology for the entire enterprise goes against the best thinking  from people like Dehghani, Fowler, and Evans about Domain Driven Design (the state of the art for Microservice design) and Data Mesh (the state of the art for Data Products which are the microservice equivalent for data). One of the core ideas behind both is that one model for the entire enterprise is an anti-pattern. Not to mention I can't imagine how that kind of highly centralized model is going to work with petabytes of data. It goes against one of the core directions that I see in modern software development: adoption of truly distributed programming. It's why functional programming is finally no longer only for nerds because functional programs (e.g., the Map-Reduce algorithm used with Apache Hadoop and Spark) are great at dealing with highly distributed data. 

But I have a feeling we may be debating apples and oranges. I'm talking about what people building systems that have to deal with petabytes of data and integrate with LLMs should use now and I think OWL and Semantic Web technology make a lot of sense. I mentioned this before but it's worth repeating: the last couple of years I read several books by thought leaders about managing enterprise data: Strengholt, Dehghani, Olesen-Bagneux, and all of them have requirements that are virtually a perfect match for Semantic Web technology: 

  • Use URLs for persistent IDs
  • Use standards
  • Explicit representation of metadata (includes semantic metadata)
  • Graph models and databases
  • Implementation-independent domain models
  • Active metadata (e.g., automated reasoning)
  • Powerful and flexible search

There are also real world examples that are being built. One of the issues with tech like this is that the people who use it don't want to talk about it because they see it as a competitive advantage but I can say from first hand experience it is being used at several tech leaders in the industry. One company that will talk about it is a German company that makes parts for modern cars. They built a Semantic Data Catalog using OWL, RDF, and standard W3C vocabularies such as DCAT and PROV. A paper from those guys is attached. 

Getting back to whether we're talking research or real world. Here is a list of the most popular database vendors right now: https://db-engines.com/en/ranking  

It's kind of depressing how Neo4j is so far above the nearest RDF triplestore. But at least all the major RDF triplestores are on the page. I didn't see a single product that uses The Symbol Grounding Framework (SGF) in that list. 

Michael

https://www.michaeldebellis.com/blog

By , No comments:
Tags ,

AI Didn’t Make Programming Easier. It Just Made It Differently Difficult

Mike's Notes

An excellent ACM article clearly explains how AI is making programming differently difficult. I agree with all the conclusions based on my experience. In my case, I have found that using AI has made it much easier to use my visual way of thinking to design complex system architecture, rather than memorising lots of code syntax. The AI creates the syntax from instructions I give it, driven by architecture decisions rather than code-level details.

These changes are great: they provide more opportunity and an order of magnitude more productivity, allowing more time to read, think and discuss. 10 minutes with AI generates what previously took a week to build.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

19/08/2026

AI Didn’t Make Programming Easier. It Just Made It Differently Difficult

By: Jeremy Osborn
Communications of the ACM: 14/07/2026

Jeremy Osborn (jeremy.osborn@gmail.com) is a technology leader whose work spans software, governance, sustainability, and strategy.

The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.

...

Opinion

For decades, empirical research has shown that programming is a demanding cognitive activity: Developers rely on working memory, long-term recall, and complex mental models to manipulate interacting abstractions such as control flow, data structures, and the structural design of software. This classical model frequently positioned memory and recall as both the central enablers of, and bottlenecks in, software development.

Today’s AI-powered coding assistants are changing that. These tools function as external memory systems, offloading syntax recall, boilerplate generation, and API usage from human to machine memory. As memory demands lessen, reasoning, architectural comprehension, judgment, and code-structure awareness are becoming comparatively more important.

Thus “knowing how to program” is being fundamentally redefined, but not in ways that make programming easier or that devalue the programmer. This article describes four major shifts in how programming work is changing:

  1. The field is opening to new practitioners.
  2. The work is becoming differently difficult.
  3. Education is transforming.
  4. The programmer’s role is evolving from knowledge vessel to orchestrating agent.

Together, these shifts suggest that AI is not eroding the cognitive substance of programming but relocating it—making different skills matter more and creating new forms of difficulty even as old barriers fall.

Programming as High-Memory Work

For most of the history of software development, researchers found that programming relied on a combination of reasoning ability, working memory capacity, and long-term memory recall. Brooks described programming as a cognitive process that depends on maintaining multiple interacting abstractions. [4] Pennington then demonstrated that programmers rely on complex mental models of control flow and data flow to design, understand, and modify code. [6] Studies have shown that these mental models exist in the mind as abstractions, are maintained at high cognitive cost, and are relatively fragile. They break down easily under conditions of context switching and are costly to rebuild in cognitive terms if they are not documented.

Today, however, AI coding assistants are reshaping this traditionally onerous cognitive landscape. Developers now have access to external memory systems capable of generating code, retrieving syntax, reconstructing context, and remembering and regenerating variants of previous mental constructs. This does not eliminate the need to think. But it does shift which cognitive skills are becoming most relevant for programmers.

Working memory and long-term recall.  Working memory is the limited-capacity system that supports temporary storage and manipulation of discrete blocks of information, as formalized by Baddeley and Hitch. [2] Long-term memory, conversely, serves as the repository of consolidated knowledge, including declarative information such as syntax and architectural concepts, and procedural knowledge like coding idioms and problem-solving schemas.

Programming has traditionally relied heavily on both. Soloway, Bonar, and Ehrlich found that programmers rely on internal cognitive preferences, [9] presumably based on experience and retrieved from long-term memory, to structure their approach to iterations. For example, when a loop construct matched the programmer’s natural plan, correctness increased dramatically. This suggests that programming has historically been guided not just by syntax knowledge but by the formation and execution of internal cognitive preferences retrieved from memory and expressed as mental models through design choices. Siegmund et al. used fMRI to show that code comprehension activates networks associated with working memory, attention, and language processing, [8] providing physiological evidence that understanding complex programming tasks is a resource-intensive cognitive task at the neurological level.

Theories of AI as an external memory resource.  AI coding assistants alter this cognitive landscape by acting as external memory and cognition. This aligns with Hutchins’ theory of distributed cognition, which argued that cognitive systems often extend beyond the individual to include the external environment, [5] which can extend and enhance individual cognition.

Alternate theories complement distributed cognition. Cognitive load theory (CLT) holds that AI tools can reduce extraneous load, which is the memory overhead of recalling syntax and boilerplate, thereby freeing working memory for intrinsic, high-level reasoning. The Extended Mind Hypothesis (EMH) goes further by focusing on the individual: If an AI assistant becomes reliably available, habitually used, and trusted, it can function as an integrated component of the programmer’s cognitive architecture rather than as an external tool. Under this view, the AI becomes part of the thinking process itself, shaping reasoning, decision making, and the effects of cognitive effort.

Barke, James, and Polikarpova [3] showed that developers commonly use Copilot to offload low-level work, such as typing boilerplate, recalling API details, and looking up unfamiliar syntax, while shifting effort toward validating and integrating the generated code. These findings collectively support the view that AI is not merely a faster search engine; it is at least partly an integrated extension of human cognitive architecture.

What AI removes and what it does not.  Thus, AI fundamentally changes the costs associated with imperfect memory, effectively reducing the penalty for imperfect recall. A developer can successfully request a common API usage pattern without precise internal recall or retrieve complex syntax without relying on working-memory-intensive reconstruction. This capacity directly reduces the dependency on the rapid retrieval of specific, low-level knowledge from long-term memory, mitigating the cognitive bottleneck previously identified.

However, while AI-assisted programming tools can accelerate routine development tasks, they do not eliminate the need for human oversight, particularly when work requires conceptual reasoning rather than surface-level code manipulation. Every programmer knows AI can produce code that is syntactically correct yet semantically and subjectively flawed, meaning developers must still understand program structure well enough to detect errors, evaluate coding suggestions critically, and ask the necessary “why” and “why not” questions about causal behavior.

Shihab et al. found that students using GitHub Copilot completed brownfield tasks substantially faster and with more solution progress, but in exit interviews many reported concerns about not fully understanding how or why Copilot’s suggestions worked, and the authors call for pedagogical approaches that leverage Copilot’s benefits while fostering comprehension. [7] Alanazi et al., in a meta-analysis of controlled studies of tools such as ChatGPT and Copilot in programming education, reported that while AI assistance improves task performance and efficiency, it offers only small and statistically unstable gains in learning success and ease of understanding. [1]

Taken together, these findings support the view that architectural reasoning, impact analysis, and long-term system maintenance cannot be offloaded to AI. They depend on deep, structural understanding of the codebase that remains the programmer’s responsibility. So, while AI may extend cognition and make certain programming tasks more efficient, thereby improving the productivity of trained developers, critical tasks such as debugging, refactoring, and systems analysis still require expertise and comprehension, and rely heavily on internal mental models that allow programmers to simulate execution and infer complex cause-and-effect paths within a codebase.

This marks a significant cognitive reorganization: Memory becomes a shared resource spanning human and machine; programming becomes less about what the developer can hold and manipulate in their mind and more about how clearly they can think at multiple scales when creating and ordering a complex logical system. Studies confirm that stable mental models of a codebase are essential for navigation and reasoning. Therefore, if developers outsource too much thinking to AI, those internal models can weaken. AI thus shifts cognitive load rather than removing it and speeds up writing code but increases the time spent checking and validating it.

In other words, the hard part moves from recall (“How do I write this?”) to judgment (“Does this actually make sense?”). This shift from recall-based to judgment-based programming represents the fundamental cognitive transformation at the heart of AI-assisted development. Where traditional programming demanded that developers maintain vast internal libraries of syntax, patterns, and idioms, AI-enabled programming demands instead they maintain robust evaluative frameworks for assessing correctness, coherence, and appropriateness. The cognitive burden has not disappeared—it has relocated from retrieval to reasoning.

Programming as Hybrid Cognitive Systems Work

The emerging reality is not that AI replaces the programmer, but that it becomes a second cognitive engine running in parallel. The machine surfaces patterns, stitches together APIs, retrieves forgotten syntax, and drafts first-pass solutions at a speed that reduces low-level recall bottlenecks but can also increase the burden of evaluation. The human, in turn, becomes less a conductor of keystrokes and more a shaper of intent: checking, interpreting, integrating, synthesizing, validating, reorganizing, discarding, editing, and ultimately giving structure and purpose to what the system supplies. It resembles what has already happened in medicine: Diagnostic tools lowered the burden of memorizing obscure clinical details but raised the stakes for interpretation, judgment, and error detection. Expertise became less about recall and more about reasoning.

Understanding this hybrid arrangement helps explain why AI makes programming differently difficult rather than simply easier. The difficulty has not been eliminated; it has been redistributed across a new cognitive architecture that spans human and machine. This redistribution creates new challenges even as it removes old ones.

As AI continues to function primarily as an externalized memory and a code-transformation layer, four major shifts are already visible:

  1. First, the field will open. Many who once would have bounced off the sheer cognitive overhead of memorizing libraries, syntax variations, or error-handling idioms will now find a workable entry path. The bottleneck of recall shrinks, making programming more accessible to people who might previously have struggled with syntax, library details, or unfamiliar idioms, while placing greater emphasis on problem decomposition, systems reasoning, and the ability to evaluate generated code. However, this accessibility comes with a paradox: While the barrier to producing code lowers, the barrier to producing good code may actually rise, as judgment becomes more critical and harder to develop than recall ever was.
  2. Second, the work does not become simpler, only differently difficult. Conceptual clarity, decomposition, debugging, and architectural foresight still demand effort, and perhaps more of it. The challenge moves up a level. Where novice programmers once struggled primarily with syntax errors and API usage, they now struggle with evaluating whether AI-generated solutions are appropriate, maintainable, and aligned with broader system constraints. This represents a more sophisticated form of difficulty, one that requires deeper understanding of software-engineering principles rather than surface-level language features.
  3. Third, education will shift. We will teach fewer people to memorize syntax and more to think in complex systems. The curriculum bends toward architecture, interface design, state management, failure modes, constraint negotiation, test construction, security, and long-term maintainability. Code becomes only one representation of thought among many overlapping ones. Developers must still possess the skills to analyze, adapt, and modify what AI produces, perhaps even more so than before.
  4. Fourth and most importantly, the programmer remains essential. Not as a vessel of knowledge but as the orchestrating agent who understands the parts and how they fit together, maintains the integrity of the system, and who decides what matters. This shift has profound implications for how we understand programming expertise. The most capable developers of this new era will not be those who type the fastest or remember the most, but those who can hold deep mental models while offloading everything that interferes with that. They will combine strong systems reasoning with AI-augmented recall and will treat the model almost like a cognitive prosthetic: useful, fast, but incapable of finally determining subjective-semantic correctness or coherence.

Conclusion

Taken together, these four shifts suggest AI is not eroding the cognitive substance of programming but relocating it. As external memory becomes abundant and code generation cheap, the value of the programmer moves toward interpretation, structural reasoning, and judgment. The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.

AI does not, therefore, diminish the craft; it widens it, deepens it, and makes more of the work explicitly intellectual. The work becomes differently difficult because it demands more sophisticated forms of expertise: judgment over recall, architecture over syntax, orchestration over implementation. These are not easier skills to develop or demonstrate, they are simply different ones, and perhaps ultimately more demanding.

References

1. Alanazi, M., Soh, B., Samra, H., and Li, A. The influence of artificial intelligence tools on learning outcomes in computer programming: A systematic review and meta-analysis. Computers 14, 5 (2025), 185.

2. Baddeley, A.D. and Hitch, G. Working memory. In The Psychology of Learning and Motivation 8, Academic Press. G.H. Bower (Ed.) (1974), 47–89.

3. Barke, S., James, M.B., and Polikarpova, N. Grounded Copilot: How programmers interact with code-generating models. In Proceedings of the ACM on Programming Languages 7, Article 78 (2023), 85–111.

4. Brooks, R.E. Towards a theory of the cognitive processes in computer programming. Intern. J. Man-Machine Studies 9, 6 (1977), 737-751.

5. Hutchins, E. Cognition in the Wild. MIT Press (1995).

6. Pennington, N. Stimulus structures and mental representations in expert comprehension of computer programs. Cognitive Psychology 19, 3 (1987), 295–341.

7. Shihab, M.I.H. et al. The effects of GitHub Copilot on computing students’ programming effectiveness, efficiency, and processes in brownfield programming tasks. In Proceedings of the ACM Conf. Inter. Computing Education Research (2025), 407–420.

8. Siegmund, J. et al. Understanding source code with functional magnetic resonance imaging. In Proceedings of the 36th Annual Intern. Conf. Software Engineering, ACM (2014), 378–389.

9. Soloway, E., Bonar, J., and Ehrlich, K. Cognitive strategies and looping constructs: An empirical study. Commun. ACM 26, 11 (1983), 853–860. 

By , No comments:
Tags , , ,
Subscribe to: Posts (Atom)