Showing posts with label mind. Show all posts
Showing posts with label mind. Show all posts

Oliver Sacks on the Three Essential Elements of Creativity

Mike's Notes

Very cool. Maria Popova's original post includes many more reference links. Everyone has creativity, some more than others, and it can be cultivated.

I love Oliver Sacks' colour-highlighted notebooks.

The River of Consciousness compiles the following essays:

  • Darwin and the Meaning of Flowers
  • Speed
  • Sentience: The Mental Lives of Plants and Worms
  • The Other Road: Freud as a Neurologist
  • The Fallibility of Memory
  • Mishearings
  • The Creative Self
  • A General Feeling of Disorder
  • The River of Consciousness
  • Scotoma: Forgetting and Neglect in Science

Resources

References

  • The River of Consciousness, Oliver Sacks, October 2017. Pan Macmillan.

Repository

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

Last Updated

05/09/2026

Oliver Sacks on the Three Essential Elements of Creativity

By: Maria Popova
The Marginalian: 09/11/2017

Maria Popova is a Bulgarian-born, American-based essayist, book author, poet, and writer of literary and arts commentary and cultural criticism that has found wide appeal both for her writing and for the visual stylistics that accompany it.

...

“And don’t ever imitate anybody,” Hemingway cautioned in his advice to aspiring writers. But in this particular sentiment, the otherwise insightful Nobel laureate seems to have been blind to his own admonition against the dangers of ego, for only the ego can blind an artist to the recognition that all creative work begins with imitation before fermenting into originality under the dual forces of time and consecrating effort.

Imitation, besides being the seedbed of empathy and our experience of time, is also, paradoxically enough, the seedbed of creativity — not only a poetic truth but a cognitive fact, as the late, great neurologist and poet of science Oliver Sacks (July 9, 1933–August 30, 2015) argues in a spectacular essay titled “The Creative Self,” published in the posthumous treasure The River of Consciousness (public library).


Oliver Sacks captures a thought in his journal at Amsterdam’s busy train station (Photograph by Lowell Handler from On the Move)

In his impressive handwritten notes on creativity and the brain, which became the basis of the essay, Sacks had enthused about — in two colors, underlined — the “buzzing, blooming chaos” of the mind engaged in creative work. But, contrary to the archetypal myth of the lone genius struck with a sudden Eureka! moment, this chaos doesn’t occur in a vacuum. Rather, it coalesces from a particulate cloud of influences and inspirations without which creativity — that is, birthing of something meaningful that hadn’t exist before — cannot come about.

With the illustrative example of Susan Sontag — herself a writer of abiding wisdom on the art of storytelling — Sacks traces the inevitable trajectory of creative development from imitation to originality:

Susan Sontag, at a conference in 2002, spoke about how reading opened up the entire world to her when she was quite young, enlarging her imagination and memory far beyond the bounds of her actual, immediate personal experience. She recalled,

When I was five or six, I read Eve Curie’s biography of her mother. I read comic books, dictionaries, and encyclopedias indiscriminately, and with great pleasure…. It felt like the more I took in, the stronger I was, the bigger the world got…. I think I was, from the very beginning, an incredibly gifted student, an incredibly gifted learner, a champion child autodidact…. Is that creative? No, it wasn’t creative…[but] it didn’t preclude becoming creative later on…. I was engorging rather than making. I was a mental traveler, a mental glutton…. My childhood, apart from my wretched actual life, was just a career in ecstasy.

[…]

I started writing when I was about seven. I started a newspaper when I was eight, which I filled with stories and poems and plays and articles, and which I used to sell to the neighbors for five cents. I’m sure it was quite banal and conventional, and simply made up of things, influenced by things, I was reading…. Of course there were models, there was a pantheon of these people…. If I was reading the stories of Poe, then I would write a Poe-like story…. When I was ten, a long-forgotten play by Karel Čapek, R.U.R., about robots, fell into my hands, so I wrote a play about robots. But it was absolutely derivative. Whatever I saw I loved, and whatever I loved I wanted to imitate — that’s not necessarily the royal road to real innovation or creativity; neither, as I saw it, does it preclude it…. I started to be a real writer at thirteen.

Sontag’s experience, Sacks argues, reflects the common pattern in the natural cycle of creative evolution — we learn our own minds by finding out what we love; these models integrate into a sensibility; out of that sensibility arises the initial impulse for imitation, which, aided by the gradual acquisition of technical mastery, eventually ripens into original creation. He writes:

If imitation plays a central role in the performing arts, where incessant practice, repetition, and rehearsal are essential, it is equally important in painting or composing or writing, for example. All young artists seek models in their apprentice years, models whose style, technical mastery, and innovations can teach them. Young painters may haunt the galleries of the Met or the Louvre; young composers may go to concerts or study scores. All art, in this sense, starts out as “derivative,” highly influenced by, if not a direct imitation or paraphrase of, the admired and emulated models.

When Alexander Pope was thirteen years old, he asked William Walsh, an older poet whom he admired, for advice. Walsh’s advice was that Pope should be “correct.” Pope took this to mean that he should first gain a mastery of poetic forms and techniques. To this end, in his “Imitations of English Poets,” Pope began by imitating Walsh, then Cowley, the Earl of Rochester, and more major figures like Chaucer and Spenser, as well as writing “Paraphrases,” as he called them, of Latin poets. By seventeen, he had mastered the heroic couplet and began to write his “Pastorals” and other poems, where he developed and honed his own style but contented himself with the most insipid or clichéd themes. It was only once he had established full mastery of his style and form that he started to charge it with the exquisite and sometimes terrifying products of his own imagination. For most artists, perhaps, these stages or processes overlap a good deal, but imitation and mastery of form or skills must come before major creativity.


A page from Dr. Sacks’s wild and wondrous handwritten notes on creativity and the brain.

Curiously, Sacks points out, many creators don’t make the leap from mastery to such “major creativity” — something Schopenhauer considered in his incisive distinction between talent and genius. Often, creators — be they artists or scientists — content themselves with reaching a level of mastery, then remaining at that plateau for the rest of their careers, comfortably creating more of what they already know well how to create. Sacks examines what set those who soar apart from those who plateau:

Why is it that of every hundred gifted young musicians who study at Juilliard or every hundred brilliant young scientists who go to work in major labs under illustrious mentors, only a handful will write memorable musical compositions or make scientific discoveries of major importance? Are the majority, despite their gifts, lacking in some further creative spark? Are they missing characteristics other than creativity that may be essential for creative achievement — such as boldness, confidence, independence of mind?

It takes a special energy, over and above one’s creative potential, a special audacity or subversiveness, to strike out in a new direction once one is settled. It is a gamble as all creative projects must be, for the new direction may not turn out to be productive at all.

Much of the gamble, Sacks argues, is a kind of patient gestation at the unconscious level — something Einstein touched upon in explaining how his mind worked. Echoing T.S. Eliot’s insistence on the necessity of “a long incubation” in creative work, Sacks adds:

Creativity involves not only years of conscious preparation and training but unconscious preparation as well. This incubation period is essential to allow the subconscious assimilation and incorporation of one’s influences and sources, to reorganize and synthesize them into something of one’s own…. The essential element in these realms of retaining and appropriating versus assimilating and incorporating is one of depth, of meaning, of active and personal involvement.


Illustration by Maurice Sendak from Open House for Butterflies by Ruth Krauss

He illustrates the detrimental absence of such a gestational period with an example from his own experience:

Early in 1982, I received an unexpected packet from London containing a letter from Harold Pinter and the manuscript of a new play, A Kind of Alaska, which, he said, had been inspired by a case history of mine in Awakenings. In his letter, Pinter said that he had read my book when it originally came out in 1973 and had immediately wondered about the problems presented by a dramatic adaptation of this. But, seeing no ready solution to these problems, he had then forgotten about it. One morning eight years later, Pinter wrote, he had awoken with the first image and first words (“Something is happening”) clear and pressing in his mind. The play had then “written itself” in the days and weeks that followed.

I could not help contrasting this with a play (inspired by the same case history) which I had been sent four years earlier, where the author, in an accompanying letter, said that he had read Awakenings two months before and been so “influenced,” so possessed, by it that he felt impelled to write a play straightaway. Whereas I loved Pinter’s play — not least because it effected so profound a transformation, a “Pinterization” of my own themes — I felt the 1978 play to be grossly derivative, for it lifted, sometimes, whole sentences from my own book without transforming them in the least. It seemed to me less an original play than a plagiarism or a parody (yet there was no doubting the author’s “obsession” or good faith).

In a testament to his uncommon empathic might and his endearing generosity of interpretation in regarding others, Sacks reflects on the deeper phenomena at play:

I was not sure what to make of this. Was the author too lazy, or too lacking in talent or originality, to make the needed transformation of my work? Or was the problem essentially one of incubation, that he had not allowed himself enough time for the experience of reading Awakenings to sink in? Nor had he allowed himself, as Pinter did, time to forget it, to let it fall into his unconscious, where it might link with other experiences and thoughts.

The unfortunate playwright seems to have embodied the lamentation which poet Mary Oliver so beautifully articulated in her meditation on the creative life: “The most regretful people on earth are those who felt the call to creative work, who felt their own creative power restive and uprising, and gave to it neither power nor time.”

Sacks points to three essential elements in a creative breakthrough, be it a great play or a deep mathematical insights: time, “forgetting,” and incubation. More than a century after Mark Twain declared that “substantially all ideas are second-hand, consciously and unconsciously drawn from a million outside sources,” Sacks — who had previously written at length about our unconscious borrowings — adds:

All of us, to some extent, borrow from others, from the culture around us. Ideas are in the air, and we may appropriate, often without realizing, the phrases and language of the times. We borrow language itself; we did not invent it. We found it, we grew up into it, though we may use it, interpret it, in very individual ways. What is at issue is not the fact of “borrowing” or “imitating,” of being “derivative,” being “influenced,” but what one does with what is borrowed or imitated or derived; how deeply one assimilates it, takes it into oneself, compounds it with one’s own experiences and thoughts and feelings, places it in relation to oneself, and expresses it in a new way, one’s own.

...

Complement this fathom of The River of Consciousness, thoroughly resplendent in its totality, with physicist and poet Alan Lightman on the psychology of creative breakthrough in art and science, then revisit Bill Hayes’s loving remembrance of Oliver Sacks and Sacks himself on what the poet Thom Gunn taught him about creativity.

Permanent Dawn

Mike's Notes

Great reflection and open questions from Ksenia Se in Turing Post.

Resources

References

  • ASI-Bench: At the Dawn of Artificial Superintelligence.
  • The Tacit Dimension, by Polanyi, Michael, 1891-1976.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Turing Post
  • Home > Handbook > 

Last Updated

29/08/2026

Permanent Dawn

By: Ksenia Se
Turing Post: 24/08/2026

Mom of 5. 

Ksenia is a writer, analyst, and editor covering machine learning and AI for more than seven years. At Turing Post, she shapes the editorial direction, leads the Inference interview series, and produces Attention Span, a video series explaining major shifts in AI with technical clarity, historical context, and a healthy suspicion of hype.

She is the co-founder of TheSequence.ai and a speaker and moderator at industry conferences, including AIE, HumanX, Ai4, and others. She also serves on the board of Track Two: An Institute for Citizen Diplomacy.

Before founding Turing Post, Ksenia held editor-in-chief roles in media and contributed to publications including Stratfor and Towards Data Science.

...

Four years into an announced era, and I still cannot picture the thing we are running at.

...

Today’s editorial: The superintelligence we are racing toward – and how to record our path to it.

...

Permanent Dawn

I want to stop. I want to take a few steps back actually, because I need to see the whole picture and I have not been able to.

We are racing – through the spasms and the fever of social media, through the launches and the leaderboards and the week's argument about timelines – toward something that none of us has managed to describe. What surprises me most is that even science fiction, which used to be reliable for a glimpse of what was coming, is no help here.

What is this superintelligence we are at the dawn of? The disagreement about when it arrives seems to me the smaller trouble. What bothers me is that we are reorganizing our lives around a thing we have not yet put into words.

There is an old way of finding out what a person is made of, and it is always the same method: take the help away and see what remains. It is how we test a student, how a craft decides an apprentice is finished, how a parent notices a child has grown. You withdraw the instructions, and whatever is still standing afterward is the person.

A benchmark ASI-Bench: At the Dawn of Artificial Superintelligence published last week – the thing that started me thinking about the dawn of superintelligence in the first place – runs that experiment on machines. Sixty research projects across eleven sciences, served at four levels of help: full procedure, then only the name of the method, then only the goal and the data. The scores fall off a cliff, and they fall at a particular place, the moment the written procedure is removed. Take away the steps and most of the capability goes with them. Take away everything else and little more is lost, because there was not much else there to lose.

That is the pretext, and it is only a pretext. The question underneath it is a great deal older than the technology.

The part that cannot be written down

Michael Polanyi, the Hungarian-British polymath, gave this a name in 1966 (in The Tacit Dimension): we know more than we can tell. The surgeon's hands. The editor's ear for a sentence that has gone false. The scientist's suspicion that a result is too clean. Little of it survives transcription. It passes by standing next to someone for years, and it tends to die with people who never had an apprentice.

I want to be that apprentice. Standing next to a thing for long enough to catch what it cannot say about itself strikes me as a reasonable job description, for a person and for a publication both.

We rehearsed for a different arrival

We have not managed to describe this thing, and yet we spent a century describing it in advance.

We have "seen" the robot with a body, countable and discrete, standing in a doorway. We were persuaded it would be a hostile singular mind with a plan of its own. There was an android asking to be recognized as a person, and others besides – most of those stories assumed the machine would want something.

What arrived has no body and no edges, and wants nothing of its own. It is not singular and not continuous, and it does not persist between conversations. It is not hostile, and its characteristic failure is not rebellion but a fluent, untroubled wrongness that few novelists thought to invent. It came through a text box, priced like a streaming service. Or even for free.

It also took the wrong things first. The tradition assumed arithmetic and heavy lifting would fall early, and that poetry, argument, and drawing would be the last human ground. The so-called Moravec paradox, that we debunked a couple of years ago.

There were people who saw some angles of what we have. E.M. Forster wrote "The Machine Stops" in 1909, about people who live alone in cells and consult a disembodied system through a screen for everything, including company (but we do not live in cells). Stanisław Lem's Golem XIV is a superintelligence that lectures its audience and has no particular interest in them (but it has interests of its own). In 2013, Her gave us a voice-first, bodiless, emotionally competent system sold as a consumer product (but Her still felt too human-like, and LLMs are not).

Her. 2023

Image Credit: Warner Bros

None of them works as the image for what we have now, or for what is coming. Fiction was never forecasting. It was rehearsal – the advance picture that tells people where to stand when the thing walks in. We rehearsed for the uprising and the rights hearing. We did not rehearse for a colleague with no self, who writes better than we do and is sometimes confidently wrong about exactly the things we are least able to check. And we certainly have not rehearsed for abundance that somehow became associated with that very text box.

We have too many images of machine intelligence, most of them wrong, and now that wrongness is fogging the real picture.

Who has an audience

The people who asked the larger question well were not the ones imagining machines, and I think that is why they lasted.

Keynes asked it in 1930. He guessed the economic problem would be solved within a century, and then, instead of celebrating, he worried. He thought we would be delivered into our permanent problem – how to occupy a life that necessity no longer occupies – and he expected something like a collective nervous breakdown, judging by the wealthy women of his own time who had been released from need and found little on the other side.

Arendt asked it in 1958. The opening pages of The Human Condition describe a society of laborers about to be freed from labor, which she thought close to the worst thing that could happen, because such a society knows of nothing better and has nothing else it knows how to do. Her separation of labor from work from action remains, for me, the most useful equipment anyone has built for this moment.

Bernard Suits asked it in 1978 and gave the strangest answer. If every instrumental activity became unnecessary, what would be left is games – voluntary attempts to overcome unnecessary obstacles – not as a consolation prize, but as the highest form of existence available to a being with nothing it has to do.

They lasted because each described the human condition without necessity, and that description does not depend on what the machine turns out to be. The novelists specified the hardware, and the hardware is what rotted. Abstraction outlived imagination, which is not the usual result.

People are working on this now – Shannon Vallor on what these systems reflect back at us, John Danaher on automation and utopia, Elizabeth Anderson on work and freedom, Michael Sandel on merit and dignity, Kieran Setiya and Susan Wolf on meaning. The problem is that the asking has no audience where the decisions are made. It is not flashy, it does not sell an LLM or a world model, and it will not be reposted by Elon Musk. And if you think about it, the most important topics are currently discussed on X, which is essentially a living feed. It is a remarkable way to stay inside the Silicon Valley bubble and read every mover in the industry at once, but even their words turn elusive there, because they dissolve into the noise of everyone else's.

What I want to do, and what I want to ask you about

Here is the thing I have been circling for months, and I would like your advice before I commit to it. (That was the topic I wanted to discuss with you last Friday, but I couldn’t formulate it yet.)

I do not think we need to predict the future, which is what so many reports spend their pages doing. I think we need to register it carefully – write down what was claimed, by whom, and when – and then go back and check at each stage. Kept up for long enough, that unfolds the future for us without anyone having to forecast anything.

So I want Turing Post to keep a register. Not forecasts, and not another feed of takes, but a running record. What was claimed. Who claimed it. What would have to be true for the claim to hold. And then, at intervals, what happened. The claims themselves are easy to find and easy to forget, which is the whole trouble, because they are made in a format designed to be forgotten. A register – a ledger, am almanac? – would hold them still long enough to be checked.

Part of that belongs online, where it can be corrected and extended. But I have come to want a material version as well: something printed, arriving a few times a year, something extremely beautiful that you can put on a shelf and take down in 2030 to see what we believed in 2026 and how much of it survived. Or even read it to your children. They often see things we miss.

And yes, I just need to hold it in my hands and flip the pages, don’t you?

Alongside the record I want the reflection, which is where the philosophers and the economists come in. Not commentary on the week, but people willing to say what a claim would mean for a life rather than for a valuation. I have been building toward this with the economists already. The philosophers are the next step.

What I do not know is where the line sits, and this is the part I would like help with. Whether a register is something you want at all, or whether the weekly explanation is enough. Whether print reads as serious or as nostalgia. What are we missing in this whirlpool of news and changes?

I am not confident in any of this. I am more confident that we are describing the wrong problem. We are doing it very enthusiastically and very loudly, but I keep thinking we are missing the bigger picture.

So I would like to know what you see. Send me your thoughts. I do not trust a poll on that.

P.S. Turing Post has always tried to connect the development of AI with the humans building it and living with it. But some questions are too large for the daily news cycle. They need time, history, disagreement and repeated examination.

Each quarterly Almanac could take one such question and follow it across technology, economics, institutions, history and human life. Not to manufacture a final answer, but to understand the choices being made while those choices are still ours.

If this really is the dawn of superintelligence, we should document more than how intelligent the machines become.

We should ask what kind of humans we intend to be beside them.

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. 

I have been very lucky

Mike's Notes

A curious mix of chance and trying hard; who would have thought? I am very grateful to all those who helped me along the way.

I learn by the seat of my pants, making lots of mistakes, never repeating them. Being self-educated is great. So is listening, asking questions, reading print books, learning to use tools to make things, challenging every assumption, "strong opinions, weakly held", subject to change as factual evidence emerges via robust Science. We are all capable of doing this.

We are all smarter than we give ourselves credit for.

Resources

References

  • Reference

Repository

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

Last Updated

09/08/2026

I have been very lucky

By: Mike Peters
On a Sandy Beach: 27/07/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I have been very lucky. I have had a lot of people in my life who were a good influence on me. (I get rid of anyone who sabotages or is a bad influence)

My grandmother Bessie showered me with attention and love, gave me endless things to pull apart to see how they worked, and took me to meet very clever people in a small-minded backwater town.

Family holidays in wild New Zealand, next to rivers, beaches, forests and mountains, which ignited a lifelong obsession with the patterns of nature, the why in my life.

My best friend right through school; he was the brightest kid in NZ.

My remedial "Cabbage Maths" teacher, Mrs Campbell, who took me from the bottom of a class to the top of the school with 98% by teaching me maths visually. That's when I learned the problem was not me; it was the way I was being taught, so from then on, I taught myself everything by reading 20 books a week, drawing notes, and having a go.

My high school science teacher, Mr Morgan, let me play in the chemistry lab, doing experiments after school unsupervised for several years, and taught me the scientific method on my very last day at school, the most important thing I learned in 12 wasted years.

The wise old tradesmen took a skinny kid from sweeping the floor to being able to make anything by learning on the job, trying hard, and having my butt kicked when I deserved it.

Nelson Mandela taught me to have the courage of my convictions and never give up.

The sculptor Neil Dawson and the set designer Tony Geddes taught me how to work authentically and in the flow.

My blind friend Grant, who made and gave away $60 M NZD, taught me, while he was cutting down bushes with a chainsaw, determination, quiet courage and human decency.

The magnificent 50,000 working people of South Christchurch, who trusted me to lead a volunteer residents' army doing recovery work for 3 years after the Christchurch Earthquake, teaching me humility, what honour is, and valuable leadership skills gained by trial and error in the moment.

My beloved Tracy, the bravest woman I have ever met, the only paraplegic to do the Coast-to-Coast Iron Man, who married an undomesticated autistic male and made me a much better man. Her unwavering devotion, encouragement and loyalty made all this possible.

They all shaped me; I can't thank them enough. May their memories be a blessing.

No posts for a wee while

Mike's Notes

I was on holiday for the last few weeks and am back now. There will be no blog posts, newsletters or meetings until Pipi Core is back up and running.

Update 27/05/2026

Lots of surprises. Making rapid progress. The peace and quiet are bliss.

Update 31/05/2026

The problem and solution are how things are named. Pipi auto-generates thousands of code names using multiple pattern languages, and all the naming conventions require many minor fixes for several unexpected reasons after migrating from a developer laptop to a production server environment. Everything else is absolutely fine.

Other naming problems are also being solved now, including:

  • The rapid development of Boxlang by Ortus has brought forward another challenge. Pipi 10 will be migrated to run on top of Boxlang in 2027 to support multiple languages, including C++, CFML, COBOL, Go, Java, JavaScript, PHP, Python, Rust, etc.
  • Future integration with cloud-based LLMs.
  • Future integrations with Office365, Google Workspace, Zoho, LibreOffice, etc.

The common solution is to create standardised naming systems that are simple, stable, robust, schema-based, versioned, self-documenting, and extensible to meet unanticipated future needs.

This is done by replacing code-based naming rules with database-driven ones that can be easily edited in the future via an admin UI.

90% of these names are internal, hidden in the closed core, and how they work and what they are will not be discussed here. The rest will be publicly and fully documented as part of the open-source workspaces for developers to work with.

Update 02/06/2026

I'm changing the disclosure boundary between the Pipi closed-core and open-source workspaces. Previously, "disclose everything unless there is a security reason not to". This is now changed to "disclose on the basis of need to know".

Closed-core accounts for 90% and open-source workspaces for 10% of lines of code, databases, etc.

This will reduce the documentation burden, given Pipi's vast scale. So, the open-source workspaces will be fully shared and documented on GitHub, etc, without restriction. This includes;

  • Standards schema
  • Ontologies
  • Parameters
  • Laws of physics
  • HTML + CSS
  • Algorithms
  • Module DDD models
  • Workflow diagrams
  • Documentation
  • API schema
  • UI code
  • etc

This also means some existing technical documentation about the closed-core will become hidden and only available internally.

Update 07/06/2026

Pipi Core is the IDE used to edit Pipi Core (AKA: which came first, the chicken or the egg?). Temporary UIs have been created and are being used across multiple engines to edit the names in use. This is much faster than directly editing data, which had to be done initially. The next step will be turning auto-generation back on. Once that's done, temporary UIs will be used to build permanent UIs. More automation will then be enabled via the UIs, and so on, as Pipi Core builds itself with a human in the loop.

Update 08/06/2026

The list of code cases available to use now for auto-generated naming, I/O translation, etc with examples, includes;

  • camelCase: userProfilePicture
  • kebab-case: user-profile-picture
  • PascalCase: UserProfilePicture
  • snake_case: user_profile_picture
  • SCREAMING_SNAKE_CASE: USER_PROFILE_PICTURE
  • Train-Case: User-Profile-Picture
  • flatcase: userprofilepicture
  • UPPER-CASE-KEBAB-CASE: USER-PROFILE-PICTURE
  • Sentence case: User profile picture
  • Title Case: User Profile Picture
  • middot·case: user·profile·picture
  • dot.case: user.profile.picture
  • UPPER CASE: USER PROFILE PICTURE
  • lowercase: user profile picture

Update 12/06/20026

Checking that these changes to variable names and internal messaging do not clash with the Gödel Machine.

Update 17/06/2026

The DevOps Engine (dvp) has unexpectedly proven to be critical to solving this puzzle. Mostly fixed last night. Watching the rather excellent live Google talk, Beyond the GPU: Maximising goodput with self-healing AI infrastructure, this morning has given me valuable insights into how to fix the remaining issues by reviewing Google HPC YAML files. 😎😎 Sometimes insights come from the strangest places.

Update 01/07/2026

The main work now is rapidly configuring Pipi for production and full autonomous automation. Using Google Search AI Mode (Gemini) and then Grammarly Pro makes the work easier and 100x faster.

  • I have decided to have Pipi re-render the many Ajabbi draft public websites with the new and missing developer information. (20K pages)
  • The website's .robot.txt file will then be unlocked to enable search engines.
  • The HTML will be updated to make it easier for AI to read.
  • This blog will be imported into Pipi, cleaned up, re-exported from Pipi, and published to Blogger via the API.
  • The new posts created in Pipi will return to A Sandy Beach to discuss something already built rather than being built.

Update 02/07/2026

The DevOps and IaC engines are getting rapid data model overhauls. The IaC engine is a great test for the variable names. I'm building a capability into Pipi to autonomously and automatically run OpenTofu and Ansible, initially targeting the Pipi Data Centre, then GCP and AWS for deployments. It's going very well and making rapid progress.

Update 05/07/2026

Pipi will initially run the open-source enterprise applications on Google Cloud Run and Google Cloud Storage (GCS). The code is complete and will be very low-cost to run, giving Ajabbi, a bootstrapping-purpose startup, a very long runway.

Update 18/07/2026

The job has now shifted to configuring, networking and deploying many physical servers. Installing software, including Pipi, labelling cables and rack gear, throwing out junk, tidying, etc., leaving nothing to chance. Shipping delays are holding up part deliveries.

Update 28/07/2026

Most of the equipment has arrived, and the small data centre setup is coming together. More deliveries later this week. It's already running a lot better and is much more productive.

Update 31/07/2026

Work on Pipi has reached a tipping point or system phase change as Pipi takes over tasks using autonomous automation. Pipi now has deadlines, not me. Soon it will set the deadlines. It's now a downhill run; daily posts from me resume tomorrow, and much more will come.

In hindsight. This whole project has been systematic trial and error, spending 10 years learning how to crack a hard problem.

Resources

References

  • Reference

Repository

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

Last Updated

31/07/2026

No posts for a wee while

By: Mike Peters
On a Sandy Beach: 15/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I was on a no-coding holiday for the last few weeks to clear my mind, and it has been great. I am back on the job today.

Suspended

Until the closed-source Pipi Core is back up and running 100% on autopilot, 10x faster, the following are suspended.

  • New posts "On a Sandy Beach
  • All newsletters, including the weekly Friday Report and the monthly Ajabbi Research Newsletter.
  • The fortnightly online Open R&D meeting.

Rapid refocus

  • A new developer area with five coding screens, designed to be more productive for hypervisual learners.
  • A better library has been set up for my A4 drawings in ring binders, the many reference books I use, and more bookshelves are on the way.
  • The server rack has been moved to a better location.
  • The light levels have been adjusted.
  • A big office tidy is almost done. An office-work-only desk has yet to be set up with a cat bed included.
  • A separate area with no screens for the happy cat, coffee, music, reading and drawing.

Less is more

Minimise screen time to be more productive at work. The new setup is also much less tiring.

Get the job done

The good thing is that, with a holiday and lots of drawing, I now have mental clarity about what needs fixing and how to fix it. Mainly, quite delicate changes here and there, organised into a list of steps. Now, I need to concentrate on one thing only: go as fast as possible, without meetings, post-deadlines, phone calls, or other distractions.

How

1. Use an AI workforce

Be the architect, and AI fills in the dots to make it happen.

Use Google Search AI mode (Gemini) to generate 99% of the code in one-page chunks (including references) to copy and paste, then manually change the variable names and SQL. Careful, test everything, resulting in 100x faster progress. Know how everything works and rapidly raise personal skill level.

2. Then build a cathedral

Make a wooden scale model of a cathedral for the builders. Google Search AI mode (Gemini) makes each brick, and Pipi Core assembles the bricks into floors, arches, walls, and vaults...

Speed is king

With the 100x coding productivity gains from Google Search AI mode (Gemini), plus the 10x10x10x speedup of Pipi Core currently underway over the next few months, what previously took a year will be done in hours and better.

Phase transitions

Once these initial migration issues from laptop to server are resolved, further transitions can be anticipated as the number of engines rapidly increases beyond 20. Increasing the number of engines slowly changes the whole system's behaviour from deterministic to probabilistic and adaptive.

Here is a partial list of transitions expected as the number of engines increases from 0 to 200. The actual numbers are a bit of a guess.

  • 20 engines enable Pipi 9 Core in a simple, deterministic structure.
  • 40 engines enable a workspace with a UI for administering Pipi Core.
  • 60 engines enable self-generation of user documentation.
  • 80 engines enable REPL and IAC (infrastructure-as-code).
  • 100 engines enable Workspaces for different user accounts.
  • Different Pipi 9 editions are made with the same engines, which recombine differently in response to the external environment.
  • And so on until...
  • 200 engines self-organise into a multi-layered complex fluid structure with probabilistic behaviour and emergent properties, as engines also act as agents.
  • 200+ engines enable Pipi 10 to interact with externally cloud-hosted LLMs, combining the very different strengths of both.

Official Trailer for The Dyslexic Advantage Movie

Mike's Notes

I'm very lucky, and so are these people. Grammarly is just a tool. Work from what you are good at.

Mind Strengths Assessment

I did the assessment. This is my score.

You can also do a free assessment.

Resources

References

  • The Dyslexic Advantage: Unlocking the Hidden Potential of the Dyslexic Brain, by Brock and Fernette Eide. Penguin 2012.

Repository

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

Last Updated

16/04/2026

Official Trailer for The Dyslexic Advantage Movie

By: Brock and Fernette Eide
Dyslexia Advantage: xx/10/2026

.