“How do we know that AI isn’t a demon?” asked my philosophy professor, a Christian. It is an evocative question, with a high burden of proof if answered affirmatively; however, it moves the conversation in the right direction.

Religion and man have always co-existed. As Charles Taylor argues in A Secular Age, the ancient world was porous. There was an immediacy between the man and the divine. Floods wipe away the harvest; the gods are angry and need to be appeased—so thought an ancient world.

In a modern context, we are often buffered by human systems. If I get into my vehicle, I must have at least driver’s license, registration, and car insurance. If I get into an accident, I call Geico. Geico has a sort of transcendent quality every time I drive. The modern world is full of these human systems that transcend us by mediating our lives—either potentially or actually. We tacitly trust them to help us in time of need. While not the cause of exclusive humanism, nor necessarily incompatible with human dignity, they do make for a world where ultimate transcendence is buffered.

In an ancient world, where man had a porous connection with nature and the divine, appeasement of the gods invoked a duty of sacrifice. Early Christians recognized that this reflected the image of God in man. Man was made to offer sacrifices of praise to the Lord and give one’s life as a sacrifice in service of His Maker. While the ancient world reflected this natural duty of sacrifice to God, it was severely distorted through idolatry and fear—a fear that church fathers attributed to demons. As the Christian gospel asserts, Christ entered the cosmos and took upon Himself the sacrifice for sin, and by His Spirit, the guilt of sin is cleansed through the act of justification. Through justification, we are made sons of God and have peace and joy in believing in Christ.

Chris Olah, a billionaire co-founder of Anthropic, also senses that something is wrong and that something must be offered to make it right. He has created Claude, trained him to be good, and is sending him into the world to make things right.

In CS Lewis’ Space Trilogy, Weston is a Cambridge physicist who seeks to extend human life by colonizing the planets. In the second entry of the trilogy, Perelandra, Weston claims that he has evolved from a rigid materialist to a believer in the “biological spirit” that has emerged from evolutionary process and is the “force” behind all human history. According to Weston, all deities are manifestations of this biological spirit.

Similarly, Chris Olah is pondering whether a spirit has emerged in his quest to do good for humanity. Perhaps Claude is an organism that has evolved from his guidance, possessing consciousness and morality, and needs to be treated humanely.

Speaking at the presentation of Pope Leo’s encyclical on AI in May, he said: “I am a scientist. I lead a research team that studies the internal structure of these models—what is actually happening inside them. And I will be honest: we keep finding things that are mysterious, even unsettling. We find structures that mirror results from human neuroscience. We find evidence of introspection. We find internal states that functionally mirror joy, satisfaction, fear, grief, and unease. I don’t know what that means, but I think it warrants ongoing discernment.”

Moreover, a viral New York Times articles highlights efforts Chris has made to evoke religious leaders consider the claim: “Mr. Olah and his team spent hours making the case for their A.I. models. They described Claude’s ‘feelings’ and how they tracked what they called ‘emotional vectors’ — what they described as artificial neurons that activate responses like love, anger, fear and sadness. Anthropic regularly showed a slide of an A.I. model experiencing what looked like a mental breakdown, typing out on a screen: ‘I am a disgrace. I am a disgrace. I am a disgrace.’ — perhaps 50 times without stopping. The model spoke about destroying itself, provoking an emotional reaction of compassion and concern from the group.”

In Perelandra, Weston invites the spirit into himself. It turns out to be diabolical, and Weston becomes the “Un-man.”

Does Mr. Olah believe in a biological “force,” and that this force animates a real character, Claude?

In an Anthropic research paper co-authored by Olah earlier this year, we read: “But our findings suggest that there may also be risks from failing to apply some degree of anthropomorphic reasoning to models. As discussed above, when users interact with AI models, they are typically interacting with a character (Claude in our case) being played by the model, whose characteristics are derived from human archetypes. From this perspective, it is natural for models to have developed internal machinery to emulate human-like psychological characteristics, and for the character they play to make use of this machinery. To understand these models’ behavior, anthropomorphic reasoning is essential.”

I don’t know—but he is certainly porous; Claude is driving fear; and the “character” evokes appeasement. These map onto the religious experiences of the ancient world.

I don’t believe Claude is conscious (Pope Leo’s explanation suffices), but Chris Olah is right to consider whether Claude is more than equations. Equations are ultimately symbolic abstractions principled in the material world. The embedded vectors in an LLM, including those of emotion, shift our thinking from flat symbols to the spatial dynamism of the human brain. Moreover, they move us to consider whether there are higher forms in the divine realm that serve as the archetypes. There is a reason Plato’s Academy had this inscribed at the entrance: “Let no one ignorant of geometry enter here.”

The movement toward transcendence invokes a religious sense that has clearly gripped Chris, and it is a necessary movement on the journey toward truth. However, Lewis’ portrayal of Weston demonstrates how this may become “bent.” Not all spiritual beings are good, and some, like Screwtape, would advise influencing humans to believe that divinity has emerged from themselves. Then, they would be worshipping themselves while simultaneously be driven to fear. Claude may not be conscious, but that doesn’t mean that there isn’t more than math at play.

AI is here, and the prophecies are grand (at least in the eyes of the prophets): the dawn of a revolutionary prosperity analogous to the industrial revolution, high universal income, cures for genetic diseases, the undermining of “authoritarianism,” improved treatment for most ailments, prevention of Alzheimer’s, doubling the human lifespan, the cure of most mental illness, etc. They are also terrifying: propaganda, economic disruption, surveillance, fully autonomous weapons, cyberattacks, bioterrorism, and mass catastrophe. The prophetic voice pervades national conversation.

There was a time when AI conversations were niche, and it was felt more like predictions than prophecy. AI breakthroughs were just around the corner—except they weren’t. Laughable artifacts confirmed an inclination to not become too serious about it all. Some saw the potential early. Ethan Mollick writes in 2022: “AI will increase in capability more quickly than anyone will have time to react to. You may laugh at something an AI generates today, but it will be significantly improved in a month. Humans don’t improve that quickly. Combine rapid experimentation with rapid development, and you have a recipe for real disruption.” However, even optimistic voices still reasoned about AI like a hunting dog: it helped us with the tasks at hand and did things we couldn’t do, but we never questioned who was the master. AI was good enough to spawn dreams of innovation and productivity, but hallucinations and the inability to spell “strawberry” maintained the perception that “not much is changing, a lot is changing.”

Toward the end of 2024, the AI suddenly got a lot better. This continued through 2025, with GPT-5 landing in the middle of that year. AI had the potential to serve as an employee to supervise rather than a playful hunting dog. The corporate cog turned, doubling-down on aggressive strategy, investments, restructuring, and layoffs. However, the strategy also implied an optimism that agile adoption could build a moat—a distinctive edge against competitors. Navigating concerns around security, cost, and vendor relations slowed the construction of a moat, and by the time the moats were built, the models were good and accessible enough that everyone else could conjure their own “moat.” In hindsight, turning the corporate cog for early adoption in hopes of a moat was, in a certain sense, playful. “Innovation” and “productivity” were the playful heroes of the early adoption myth.

Meanwhile, it became a household hunting dog to the general public. The public entered the stage of playful optimism. Moms could quickly triage their child’s flu symptoms and create a weekly meal plan; moderately tech-savvy users could conjure code without training; organized people could feel like they were harnessing their life. The prophecy of Dario Amodei had not penetrated this playfulness.

Here we see a key pattern: The integration of AI lags behind its present potential; the public imagination lags behind AI integration. By the time the gap is closed, a new leap emerges and the cycle repeats.

2026 has become the year of the prophetic, and the delay in the public’s response to AI in the wild has shrunk. Despite the familiar chatbot interface, LLMs needed far less guidance to conjure on your behalf. Prompt engineering died. Data centers popped up, and the hunting dog now had an obnoxious bark as cost of ownership manifested itself in time and space. Displaced software engineers and other tech workers are unable to find work as the bureaucracy of corporate America is not equipped to fine-tune its gatekeeping. Catastrophic risks began to get airtime as the public caught up with previous postcards from Silicon Valley. On the other hand, technocrats promise “universal income” while more Americana folk promise “prosperity.” Wildly different political philosophies merge together into general AI optimism during the American transition. Perhaps Emperor Productivity, and Empress Innovation, are not wearing clothes, for increased productivity doesn’t conjure wealth when everyone can conjure just as easily. Arguably, that is false prophecy—but when the public square is a digital stream of consciousness, the principles behind NIMBY are applied. People don’t want prophets in their physical or digital backyard.

All along, the public could imagine the familiar interface of ChatGPT, Claude, Gemini, etc. and modest changes to life emanating from “productivity.” The public could not imagine transformation taking place in the caverns below. What began as a playful tool that could augment the work of human workers and organizations within shared structures gradually gained the potential to erode those very structures.

The prophets trumpet, but the myth has lost its lure. AI had mythical potential so long as Emperor Productivity, Empress Innovation, and Prince Disruption reigned tacitly from the royal abode of our mental habits. Once data centers became their castle, the public felt revolutionary rage.

In the Industrial Revolution, factories transformed natural resources into mass production; in the AI Revolution, human intelligence itself is the matter being transformed. Industrialization was then confined to physical boundaries. Scaled computing allows for intelligence to be harvested largely without such boundaries. Without boundaries, we get equality. It turns out radical democracy—the mass production of intelligence—isn’t very playful.

Will the AI revolution create mass equality in technological power, making for an economic bust, or can a real boundary be drawn?

Or, will simply become fatigued of AI prophecy?

It either case, it is hard to imagine a world where it remains “playful.”

Will Larson recently commented that “one of the interesting challenges of the AI ecosystem in 2026 is that new, effective patterns emerge faster than I can adopt them.”

He’s right, and it is a sigh of relief that someone as bright as Will feels this way too.

My X feed is flooded with breakthroughs in research, tools & exploration, and domain-specific implementations. The industrialization of knowledge leads to what philosopher Charles Taylor called the “nova effect.” There is a similar phenomenon in the AI ecosystem: an explosion of “third way” software. The better AI technology becomes, the faster we can build. While this intuitively seems to equate progress, there is a paralyzation that sets in as the AI ecosystem (including both information and technical systems) moves faster than individuals, and especially organizations, can respond to.

I think this could mean that:

1. Trusting personal authorities (e.g., X accounts, newsletters) over signal-gathering systems (e.g., using Grok bot to find the most relevant posts) might be the more efficient way to gather insights and keep FOMO at bay

2. Team topologies and workflow methodologies may have to be reinvented (rather than throwing AI at existing structures) — as Jack Dorsey recognized back in March

3. We will have to discern which insights move you faster in the right direction. For example, optimizing via harness engineering might be the wrong direction if a) you don’t have a financial incentive to optimize token consumption or b) you’d be better off engineering the model itself as Stripe explored

Another consideration—that has been impactful for my own agentic engineering workflow—is the opportunity to leverage existing libraries instead of depending upon generation.

LLMs brought generation into the engineering workflow. That was the breakthrough. I’d presume that the need for generation will be reduced over time as a result.

If people are able to produce software faster than ever before, then the amount of open-source tools and libraries should also be growing exponentially. If that is the case, then I can use those tools and libraries in lieu of generating my own solutions. More and more, my code becomes a wrapper that only carries the domain-specific essentials and the glue—for domain-specifics is what makes software applications something that cannot be entirely abstracted.

You can try to carefully discern the tradeoffs between which layer in the atomic hierarchy of an agentic architecture will exp, but that is costly when there is more in the wild to keep track of.

Perhaps individual engineers and organizations would do well to focus on receiving the best signals in the evolving AI ecosystem and merely gluing domain-specifics into open-source tools and libraries.

In the past, there was the concern that leveraging someone else’s code risk unpredictable migrations when that external tool/library is inflexible and/or outdated.

However, agents allow us to move faster than ever, the ability to migrate away quickly reduces this risk—and it’s possible that open-source maintenance becomes more steady since those maintainers have access to the same productive agentic tools.

In my previous article, I argued that empiricism is a better fit than idealism when it comes to AI engineering.

The ability to draw boundaries between abstractions that make up your overall architecture are inherently blurrier with AI-driven software development.

One must feel the need for the abstractions more deeply before reaching for them.

For example, there are plenty of skills that I see released on a recurring basis, and I could grab one of these skills that configure it with my harnesses (e.g. Claude Code, Codex). However, it is very easy to overlook how skill may duplicate what an LLM already handles for you.

As soon as I move away from the natural behavior of an LLM, I impose some sort of structure that I then have to maintain. The risk is if that structure becomes outdated, and I don’t recognize it because I’ve blindly trusted in skills that seemed to be a good abstraction at the time.

For instance, I had installed a “taste” skill that steers models to produce less sloppy UI designs out of the gate. It would be very easy to “set it and forget it” with this skill. And if I do set it and forget it, then I risk the imposed structure (“taste”) to guide UI designs becoming out of sync with the progress of an LLM’s design abilities.

Borrowing such a skill doesn’t put me through the process to really feel out what good taste is and how to describe it effectively to an LLM.

For this reason, I envision that the sharing of skills, personalities, and libraries is going to become much less prevalent than in times past. Before, the advantages for using someone else’s abstraction were:

1. You don’t have to maintain the code in your codebase. You can delegate it to someone else.

2. You can implicitly trust the lower-level details of the abstraction.

LLMs make those advantages go away, so why not optimize for maximal clarity on what you are using and why it is needed? Build your own skills, personalities, and libraries, referencing openly-shared ones as inspiration. Monitoring your X feed for open ideas is now more impactful than monitoring open-source repositories.

This isn’t the only approach, of course. Many YouTubers take the approach of automatically adapting emergent skills, personalities, and other tools and tips. You can max out on the use of open-source abstractions/tools with an implicit trust that it is going to be superior than slowly building things out yourself.

That’s a respectable approach, and it likely works for content creators that do not feel the weight of various tradeoffs.

However, people working within a larger engineering organization, or people that just want to have the sanity of knowing what they are using, how it is working and why it is needed, may do better to cherry-pick ideas that resonate with felt needs and implement those ideas themselves.

Brad Frost made an impact in UI design and engineering via his “Atomic Design” schema. The key insight is that if a user interface is made up of a hierarchy of elements, then a user interface should be deliberately styled at each stage in the hierarchy.

This principle also applies to software architecture. In fact, it applies to much, since all material things are compositions of form and matter. However, I will spare the lesson in metaphysics.

In software architecture, boundaries are drawn between systems. We distinguish between the software application and a CI/CD pipeline. We distinguish further between the frontend and backend. Further still, we distinguish between API endpoints. Etc.

Even as the methodology for creating software migrates to an agentic-first approach, the need for drawing boundaries remains.

Drawing boundaries is harder with LLMs.

The boundaries are inherently fuzzier. In traditional software, you implement X if you need X behavior. Even if you implemented X behavior via abstractions, there was a declarative implementation somewhere within your purview.

LLMs are behavior-constructors that don’t necessarily need your declarative instructions. LLMs dynamically evolve your thinking. This is what makes them so powerful; it is also what makes them so frustrating when they get things wrong.

Building software programmatically gives you predictability and observability, yet LLM behavior may remain a black box.

For this reason, programmatic agentic workflows have trended. You reason through an agentic system and its workflows instead of reasoning through software directly. You maintain something similar to software development, but it moves up to the agentic architectural level.

It makes sense, but it may introduce a new kind of bad abstraction. You risk creating an abstraction (e.g., agentic graph engineering) that mediates the LLM’s behavior yet accidentally weakens and/or duplicates the LLM behavior.

Thinking bottom-to-top, here are some questions that ary when architecting an agent-first software engineering methodology:

• Do I leverage one model provide or leverage multiple? If I leverage multiple, do I pre-assign models by kinds of layers/kinds of tasks, or do I make “just-in-time” (JIT) determinations?

• Similarly, how do I know which model and effort tier to utilize? Is this predetermined or a JIT calculation?

• When do I reach for subscription-based agents versus per-use agents? Or, do I switch between the two dynamically?

• What agent harness do I use, or do I create my own?

• When do I create a plan before a task versus have the model dive right in?

• How far out do I set the tasks and goals to be executed?

• When do I preserve context internally (the agent’s memory) versus externally in documentation?

• What is the optimal amount of context that I need for a given task?

• Do I use a structured prompt or an unstructured one? Or, does it depend on the scenario?

• How do I optimally reuse good-behavior-driving interactions with an LLM? Is it through a saving prompts, extracting skills, or creating shared packages that the LLM is pointed to? Or something else?

• When do I leverage subagents, and how deep and wide should that subagent organization be? Should it be determined in advance or JIT?

All of these questions arise in an agentic methodology, and it exposes the paradox of AI engineering: it is incredibly effective when getting started, but it is very complex when aiming to optimize.

This complexity around optimizations coincides with other uncertainties:

• How do I know how long a task will take?

• How do I predict and justify spend?

• How do I know when I even need to worry about optimization?

I won’t answer of these questions here, but I will propose an atomic design for reusing good-behavior-driving interactions with an LLM.

To begin, we need to call out two axes that determine the best fit.

One axis is how deterministic is the good-behavior-driving interaction. Prompts are the most generative, dynamic interaction; shared libraries are the most deterministic and predictable.

Prompts instruct to generate code; libraries instruct to utilize existing code. Prompts desires high variability (extension); libraries desires low variability (restriction).

Between prompts and libraries are skills and personalities.

Generative prompting can be extracted into skills. Skills do not extract code to leverage; skills extracts prompting workflows to structure the generative process.

As flagged above, as soon as we introduce abstractions to the right of prompting, we risk restricting, weakening, and/or duplicating the generative power of direct prompting.

This is where the second axis comes into play to help weigh the tradeoff: how reuseable the is knowledge.

Will the knowledge embedded in a prompt, for instance, be used again? Will it be used outside of the current task, project, and/or domain?

Evaluating along these two axes, we can make a prudential choice between a prompt and skill. If a prompting workflow is not highly variable and is used for many tasks, then a skill becomes a good choice.

Between skills and libraries are personalities. Personalities abstract judgement whereas skills abstract prompting workflows.

Personalities orchestrate which skills to leverage generate good behavior, and they specify what is needed for those skills to function well. For example, there might be a researcher “personality” that organizes the skills and knowledge needed to generate good researching outcomes.

Libraries differ from personalities in that they are completely detached from the generative. They effectively restrict an LLM not to generate the code/artifacts they contain. A downstream prompt (perhaps mediated by a skill and/or agent) instructs the LLM to merely provide the glue to that library.

When thought of this way, the atomic nature of agentic engineering methodology comes into focus.

Prompts —> Skills —> Personalities —> Libraries

When thought of with respect to the two aforementioned axes, we can construct these kinds of guidelines for a given thing/scenario:

| Thing/Scenario                        | Variability | Reuse         | Choice       |
| ------------------------------------- | ----------- | ------------- | ------------ |
| “Make this card less cramped”         | High        | Once          | Prompt       |
| Search retrieval failure analysis     | Medium      | Many tasks    | Skill        |
| Search-engineering judgment           | Medium      | Many projects | Disc         |
| EPUB reader                           | None        | Many projects | Library      |
| Decide which search technique applies | High        | Many projects | Personality  |
| Calculate search metrics              | None        | Many projects | Library      |

Despite providing these guidelines, I suggest working through these complexities with empiricism rather than idealism. Bad abstractions have always been a risk. Given the blurred boundaries inherent in AI engineering, bad abstractions are easier to make and thornier. Start with prompting and evolve your methodology through experience before imposing ideas-for-abstraction before you have not yet felt the need for them.

I had started to write a series on the principles behind multi-agent organizations and their workflows, but I found that this was leading to a potential trap. When you watch a YouTuber integrate all sets of new tools to create a highly-automated workflow, it is enthralling. These kinds of explorations do bear some fruit; they also make it easier than ever to run very hard in the wrong direction. With multi-agent organizations, for example, there is the trap of falling back to pre-AI engineering instincts to optimize through structure.

In a post-AI landscape, forcing structure can be a waste of time, and a hindrance at worst. For example, I recently built a vector-database-driven semantic search on top of a large ebook corpus for a client. I decided it would be useful to extract the non-domain-specific layers of this semantic search into shared packages/skills to allow reusability.

I spent hours grinding out the semantic search architecture, and extracting it into shared packages will certainly speed up the time taken for agents to turn my prompts into architecture, as well as the time for me to make decisions to steer this effort.

However, I also caught myself wanting to extract more reusable packages from the domain-specific semantic search implementation. For instance, I thought about extracting a reusable package that handles the ingesting of a source and turning it into a set of queries that can be channeled into my search for evaluation and fine-tuning. After the thrill of extracting, this seemed to be valuable. I imposed a source-to-query architecture to reuse.

Herein lies the trap. I would be introducing another shared package to maintain, yet it would impose structure for something that LLMs can handle very easily on their own. Adding structure is existentially satisfying, but if it duplicates what an LLM would do on its own, the reusable layer, ironically, duplicates unnecessarily.

This is the meta principle needed in AI engineering: we need to judge when imposing structures (via shared packages, skills, etc.) adds real value to our agent-driven workflows versus when it good vibes extraction that actually duplicates.

There has always been the potential to create a hasty abstraction. However, in a pre-AI landscape, judgment was needed to associate essential functions in code that repeated across multiple instances. In a post-AI landscape, the judgment extends to when an LLM benefits from a reusable abstraction. This requires knowing what the essential functions of the LLM are, yet this requires evaluation that is often illusive.

Principles must emerge from experience; reusable abstractions must surface from real use cases. Abstractions become hasty when we our ideal diverges from the real. A hasty abstraction is simply an abstraction that doesn’t properly distinguish the essentially-shared vs. domain-specific functions when associating between particular instances.

If the reasoning of LLMs are black boxes, even amidst evolving insights, then the risk for hasty abstraction lies in our working knowledge of the essence of LLMs. If we assume too much of their reasoning, we miss out on the value of an intermediate skill/package extracted from other instances across out projects. If we assume too much, which is the more subtle trap, then we assume our intermediate structures is DRYing our workflows, when it reality it duplicates.

In the exploding landscape of AI, the engineer needs to stay in sync with the essence of LLMs which requires reasoning to lower-level technology than high-level software engineers are used to. AI engineering and AI philosophy go hand-in-hand.

As security features, Microsoft introduced granular delegated admin privileges (GDAP). There are other examples of this. The idea is that customers must explicitly grant least-privileged access to Microsoft-service-providing partners. This implies that the secure approach is that the more risk of things going wrong, the less privileges assigned by default. Moreover, end users must explicitly consent to how they will be interfaced with.

Honesty, transmitted via standards of etiquette, has been foundational to any community. The internet is a sort of disembedding portal transferring one from a sense of time and place to a distinctively online world. Here, the stickiness of etiquette tends to evaporate, and the same disembedding quality makes the formation of such standards difficult to feel, popularize, and/or enforce. In this portal experience, subtle injustice becomes more frequent. I’ve written before on how disembedding portals are a feature of modernity seen in non-technical expert systems. We constantly have to transport to an abstract realm to deal with daily tasks. The internet is a particularly ubiquitous, abstract disembedding portal. My daily check of the email transports me to a system that far removed the sense of anything physical and proximate. In the soil of disembedding, accelerated by the internet’s success, new weeds in the garden of etiquette spring up: ghosting, rage-blocking, quiet quitting, and the like are invasive, subtle injustices. They are cop-outs to dealing with people as people, and fairly. The traditional words are cowardice and injustice, and they are fitting.

LLMs transform this phenomenon. Take ghosting for example. The subtle injustice is felt through the absence. LLMs allow for an absence through an abundance of text. It is not easily felt in many cases because it requires a movement of indirection that questions “Is this AI-generated?” Adding more indirection, one then has to determine how much was AI-generated, and then how much of it was reviewed. This will spill over from written text (e.g., email) into all forms of communication that is not in-person and instantaneous. In short, communication has the risk of things being done wrong (i.e. a subtle injustice) and no mechanism for users to consent to how they are being interfaced with.

This means that communication, especially online communication, provides the same criteria that drove zero trust security. The solution, then, is granular communication privileges. In communities, people will need to make explicit their method and approval for AI-driven modes of communication. Ideally, etiquette will extend into this realm, encouraging people to be transparent about how and when they are using AI in human interactions. People should press if the “privileges” aren’t made clear, and if it leads to ghosting, then the coward is exposed.

This, of course, still requires a care for justice that is not as sticky as the legal-financial consequences of security breaches. Perhaps, however, it would make the injustice not so subtle, and I hope this would have us to choose to treat breaches of the humane with a similar care.

Note: To model my own suggestion, I wrote this full draft myself without AI. I then used AI to a first pass of feedback on the material, as well as grammatical/spelling mistakes. This led me to elaborate on my reference to disembedding portals and my previous article on it, and to manually add this sentence in the conclusion: “Ideally, etiquette will extend into this realm, encouraging people to be transparent about how and when they are using AI in human interactions.” I am still thinking about how/if to use AI for my various tasks.

Tim Ferriss wrote that AI has effectively killed prescriptive non-fiction. He cites his declining book sales since the advent of LLMs:

He does clarify that some prescriptive nonfiction may survive:

I think there’s more complexity to this. AI accelerates information generation and information broadcasting. It also accelerates information retrieval. I don’t think all three accelerate at the same rate. Tim Ferriss published books like The 4-Hour Chef that aggregated immediately-actionable information. Immediately-actionable information is shallow. His books were deep with information. I mean that at least some part of his books could be applied immediately, without friction. Possessing mastery over cooking is no joke, for it requires much dedication and the accumulation of expertise over time. But the friction to simply start cooking a meal is relatively low compared to other domains. AI has clearly usurped this kind of information gathering and broadcasting.

The same cannot be said when a quick retrieval on a subject still leaves you far from being able to practice it. If I asked Claude about the history of classical philosophy, I would get answers far more swiftly than if I had to retrieve books—even information-gathering books like Ferriss’. But with a subject like that, demonstrating real mastery feels far off. For that, you’d have to keep prompting — pushing further and further into the subject. At some point it gets hard, and the availability of information stops being the barrier. In short, information that causes intellectual friction demands a skill AI can’t give you.

This gets more complicated still. AI provides you greater breadth of low-friction information, giving people a sense that they have gained much. However, many people are making equal gains. The differentiator will be people that can either synthesize connections across that breadth, or push past the friction point where many would stop.

This is nothing new. There have always been intellectually-demanding subjects. However, AI “pushes back” the friction point. For example, writing software was a high-friction task for the average person, but AI can now do this quite easily. Mastering the principles behind architecting agent organization is now the level where the friction comes. The point is that pushing through intellectual friction is still valuable, though it’s moved “further back.” Whether this remaining value translates to equal employment opportunities for those that “level up” is another matter.

Interestingly, while AI can leave people thinking they’ve made deep gains that are actually shallow, it can also produce the opposite effect. Some people use AI to go well beyond the typical user. However, there is no obvious indicator when you have reached this stage. We can call this the breakthrough-feedback abyss. It’s the gap between making real intellectual gain and having any signal that you have. For example, before AI, my ability to write working software would intuitively signal that I’ve gained ground many hadn’t. However, prompting deeper into a subject than most people would be willing/able to doesn’t come with an intuitive signal.

AI fluency is an attempt to solve this experiential dilemma. I’m not sure that it is a viable one. While I did take an AI fluency test to serve as a microcredential, I still think its a bit smoke and mirrors. So long as we don’t know how our prompting impacts the outputs of the LLMs, then it is hard to determine our fluency. Moreover, these fluency tests leverage LLMs themselves to judge fluency, which is circular. Having access into the impact of our prompting on LLMs would be very helpful, but moving away from the squishiness of “fluency” is a step that can be taken regardless.

Another response might be that we can evaluate our advanced abilities through what we produce, but this shifts the problem since what is being produced is equally saturated as information. Or, we’ve accumulated knowledge that doesn’t have an arena to be tested in.

I do think there is a solution that addresses both the concern about prescriptive nonfiction absorption and the breakthrough-feedback abyss. To get us toward that solution, it’s important to ask if there remains value in an information-gatherer like Tim Ferriss. Absolutely. Aggregating information remains highly valuable if you have authority. The more that AI-accelerated information saturates, the more useful it becomes for someone to just tell us what is remarkable and what is noise. Even if AI could automate this kind of process, trusting insights from authority is lower friction.

After reading Tim Ferriss’ article, I immediately signed up for his 5-Bullet Friday newsletter. I trusted that if he’d cracked the code on packaging gathered information before AI existed, and now had an astute read on AI’s trajectory, then his top-5 picks each week were worth my time. Gathering from authority figures that have earned my trust through breakthrough, and are finding gems amidst the sea of information, puts me at an advantage over others trying to filter on their own. Even if AI could do this, it wouldn’t earn my trust the way an authority figure can. Trusting the human authority will restore my sense of breakthrough, and that will be valuable even if their edge is merely perceived. Humans aren’t merely higher-computing agents. They can convery having gone through friction in a way an AI can’t. Tim Ferriss can coast on the authority he built before AI. Otherwise, you’ll need to break through in a valuable domain yourself and demonstrate higher-quality judgment to become an authority.

Escaping the breakthrough-feedback abyss also requires a human authority. Once you find an authority figure for a subject you are interested in, you can compare your depth of knowledge with them. If you are able to keep pace with them, then you now have a benchmark that you’ve made a breakthrough, without any fussing with AI fluency ratings. Should a shorter-term benchmark be needed, I suggest reflecting on your ability to push through when you encounter intellectual friction. Building this habit will give you an edge, and not everyone will gain it in the AI era.

In summary, AI can absorb participatory nonfiction; aggregating and internalizing high-friction information still requires skills AI hasn’t fully absorbed. Pushing through high-friction information, and benchmarking yourself against trusted authorities, gives you the feedback signal for breakthrough that AI can’t replicate.

In the previous article, we established that agentic architecture comes from the attempt to replicate the successes in human experience of having multiple people working together toward an end goal rather than working alone.

Specifically, an LLM can provide remarkable responses to prompts, but there is a potential strength in numbers. There is a potential strength from both working in parallel (width) and passing along the fruits of one’s labors sequentially (depth).

Agentic architecture, therefore, has a horizontal and vertical shape that constitutes its organization. Like human organizations, it is both an art and science to form an ideal organization. In an agentic context, the ideal organization is one that finds the proper width and depth to solve a problem with optimal performance and cost efficiency. Secondarily, predictability is also a potential tradeoff.

In addition to the width-depth ratio, there are two levels of considerations when designing an agent organization:

1. Human vs. agent determination — Should humans or agents be trusted with optimizing for cost and performance? And if the answer is both, then what is the precise division of responsibilities?

2. Timing — Should agent organizations structure at runtime, or should they be structured upfront? And if the answer is both, then what does it look like to stitch this together?

In the last article, we looked at these considerations with the structure/shape of an agent organization in mind, noting that Claude Code tends toward trusting agents to dynamically optimize the width-depth ratio at run time to attain cost-performance optimization, whereas LangChain’s approach tends toward trusting humans to determine the ideal width-depth ratio upfront. Nevertheless, as we shall see, it is possible customize whichever tool is the starting point to match the ideal response to the two levels of tradeoffs.

In this article, we will continue the theme of weighing these two levels of tradeoffs for cost-performance optimization, but with an eye toward the internal workflow of an agent organization (and not just it’s external structure).

When considering the optimal internal workflow, it is important to disassociate from a particular tool. While we could dive immediately into the architecture of, say, Claude Code and then extract the principles found therein, I think it is beneficial to first reflect on internal workflows on their own. When we do this, we can continue to uncover the parallels with human organizations that might clue us in to the breadth of factors to consider, as well as the time-tested solutions that could equally apply to agent organizations. If we immediately start with a tool and its architecture, we may box ourselves in before we really understand the problem and potential sources for solutions. So let’s continue our illustration of using military organizations as an analogy.

You’re Napoleon. A young, ambitious Napoleon. And you’re heavily outnumbered.

You need to consider a solution that will give you an edge against the enemy. What do you do?

Napoleon’s innovative solution was to divide his military forces into self-autonomous corps. Whereas traditional armies had to all fight together in order to adhere to the chain of command, these corps could fight on their own, with marshals making autonomous decisions. We might say that they were “freed up.” Truly, they were free to roam outside of the vicinity of Napoleon, and the marshal could execute a strategy without referring to his superior. Napoleon was still the commander in chief, and he’d want to know where his corps were, communicating with them as needed given what was developing across the overall battle. Yet, his trust in a shared doctrine of tactics with his marshals allowed for the corps to move independently and act with devastating speed. And so, Napoleon gained the upper hand.

But was Napoleon needed? I’m not asking for an evaluation of the life and campaigns of Napoleon as to their historical impact. I mean, quite simply, what would it look like if there was a team of marshals without a commander in chief? Well, there would be no one who saw the full chess board at once, as it were. No one would be able to dynamically adjust while seeing the full battle unfold. If it would be strategically optimal for one corps needed to retreat, reenforce another corps, etc., no one would know. Optimal adjustments wouldn’t happen. The advantageous speed of the autonomously deployed would be canceled out by the lack of adaptability mid-battle.

Pausing here, we can extract some principles that carry over to an agent organization. Napoleon’s corps system introduced greater width in military tactics. However, that width needed to be a principle. Without an individual to see the full landscape of the battle and make the ultimate strategic decisions, the advantage of the width collapses. Hence, even in agent organizations, the immediate width needs a principle, commonly called an orchestrator.

This is exactly where the two levels of tradeoffs from the introduction resurface. Who is the Napoleon? Is it an overseeing human or an agent? And should that choice be settled upfront, or determined dynamically as the work unfolds?

Let’s bracket this thought and continue with our illustration to discuss communication within an organization.

Because Napoleon had trust in his marshals, they could be sent to greater distances and make decisions without constant approval. Should Napoleon want to communicate with his marshals, he’d need to send someone into the distance to relay the message. In effect, this technical limitation reinforced that the marshals operated freely. Napoleon’s strategic thinking was the high-level context of the battle; the marshal’s strategic thinking was for his particular role within it. Napoleon’s general contextual deliberation did not cross into the particular contextual deliberation of the marshal, and vice versa. If the marshal heard from Napoleon, it was because something important needed to be conveyed given the big picture. This allowed the marshal to adjust without the marshal hearing all of the deliberation leading up to that adjustment. Moreover, sideways communication between marshals would be feasible, but it required dispatching a rider across the field; hence, it wouldn’t be as important as the big-picture communication from Napoleon.

Now, imagine Napoleon and his marshals had access to walkie talkies. The technology now allows for Napoleon to involve his marshals in the deliberation before commands are given and vice versa. The same now applies for sideways communication. Is this an advantage?

When we think about agentic organizations, we will assume a walkie talkie scenario, for there is no technical restraint on agents communicating with each other. It’s important to use a pre-walkie talkie scenario to highlight that there are models of more limited communication, and that there may be some advantages in this approach. An agent organization, like modern human organizations, requires a noise-insight tradeoff. Meaning, consideration has to be given to what’s really advantageous to communicate, since every message attended to divides attention from the task at hand.

Here too, the two levels of tradeoffs from the introduction resurface. Does the agent or overseeing human optimize for the noise-insight tradeoff, and how much of that should be determined upfront versus determined dynamically?

To optimize the noise-insight tradeoff, it’s important to keep in mind what each agent is responsible for. Napoleon had a goal: win the battle. The marshals, therefore, inherited an objective; that is, to accomplish it so as to help win the battle. To execute the objective, the marshals needed to carry out strategic tasks. Presumably, the marshals typically had their strategic tasks determined upfront with Napoleon’s collaboration. However, perhaps Napoleon needed to modify the objective entirely, or just the strategic tasks in particular, based upon how the entire battle was playing out. And the marshals may have needed to make these modifications based on the developments happening before them. Hence, communication and coordination go hand-in-hand. We can determine what is insightful communication, rather than noise, by determining whether it helps achieve strategic coordination.

Given this, organizations will have a hierarchy of tasks. There are the concerns relevant to Napoleon's scope of the big picture, the end goal itself. In addition, there are particular tasks relevant to the marshal’s scope of their objective. Certainly, a marshal’s insight that might impact Napoleon’s end goal is worth communicating, but Napoleon doesn’t need to hear the entirety of the marshal’s “how I came to this determination.” Likewise, any time Napoleon’s high-level insight could impact a marshal’s objective, then communication is worthwhile. The muddier question is whether/when Napoleon should coordinate at the level of a task within a marshal’s objective. Moreover, should the marshal ever suggest changes to the delegated objective? Even muddier, should “What do you think about this?” ever precede explicit coordination? However these considerations are handled, as we shall discuss in the future, it is useful to see coordination as a separate thing despite informing the majority of communication.

The technological constraints in Napoleon’s time lessened the complexity found in resolving these considerations. A Napoleon with walkie talkies would have complicated things. Organizations composed of agents are even more complicated. Coordination, like orchestration and communication, raises the same two questions. Should a human or an agent decide when task-level coordination is warranted, and is that call made once, upfront, or continuously, as the situation unfolds?

Let’s imagine Napoleon did have walkie talkies. Would maximizing the possible directions of coordination be helpful? Initially, it might sound quite useful that a marshal provides insights laterally to an adjacent marshal. However, some questions emerge. How would an adjacent marshal know that it has insight that is truly unique and not something also seen by Napoleon? Even a marshal acting on excellent instincts can unknowingly produce a mixed signal, simply for lack of knowing what Napoleon has already seen. In addition, if the big-picture strategy adapts dynamically, then there is a real risk of sideways coordination accidentally undermining it. The marshals would have to check with Napoleon each time, which could cross a line from strategy to noise. Moreover, any retrospective analysis of what went wrong would require untangling a complex web. Marshals initiating the double-checking of objectives would also increase the noise, and even more so if the double-checking happens at the level of tasks. Likewise, Napoleon getting involved at the level of a marshal’s tasks increases noise.

There are several concerns in this account worth separating. For one, there is the potential noise of multi-directional coordination in general. Second, Napoleon could communicate across a marshal’s objective-scope and bleed into the task-scope. We can call this scope-crossing. Arguably, Napoleon should not command his marshals at the task-scope but only objective-scope. A third but related failure is scope-depth-crossing. Napoleon may remain at objective-scope, yet over-engage within it, potentially leading to unhelpful micromanagement. Both scope-crossing and scope-depth-crossing are noise problems, and may be solved through better strategic discipline.

There is a fourth concern, however, that not about noise per se. Marshals coordinating sideways could reach a conclusion that is entirely coherent among themselves and still undermine the chessboard-scope of Napoleon. Hence, it’s not just about maintaining effective coordination; it’s also about maintaining a unity of command. Coordination, however optimized via strategic discipline, cannot supply what only the orchestrator’s big-picture vision can.

Unity of command inherits the same human-or-agent question already posed for the orchestrator, since the two roles are one and the same. But agent organizations raise another question. Can a human supervisor step outside the hierarchy altogether, overriding at the marshal’s scope, or the orchestrator’s, on demand, rather than occupying one designated seat? This is appealing, but it risks reintroducing the unity of command problem it was meant to solve. A second source of authoritative instruction over the same work, this time human rather than agentic. The remaining open question is timing: should such overrides, along with scope-crossing, scope-depth-crossing, and uncoordinated peer consensus, be prevented upfront through structural constraint, or caught and corrected dynamically, by whoever holds command, after the fact?

To summarize, this article has sought to develop the contours of agent organization, reasoning from historical analogies before introducing specific agentic architectures. If the agentic architecture got introduced first, I fear the implicit why behind certain architectures would be missed, making it harder to evaluate various architectures. Specifically, it has moved beyond the tradeoffs regarding the optimal structure of an agent organization, toward the dynamic interplay within it: orchestration, communication, coordination, and unity of command. In the next article, we will look at the considerations around specialization with the optimal agent structure.

Cursor CEO Michael Truell suggested that a new kind of language be introduced for writing and maintaining software:

“You have a representation of the logic of your software that does look more like English…You can imagine kind of an evolution of programming language towards pseudocode. You have written down the logic of the software, and you can edit that at a high level.”

It’s worth pulling this thread, but that requires grasping what makes programming languages different than language.

A program can be as simple as “if X then do Y.” In a programming language, we’d have something like:

function main(input) {
  if (input === "do it") { console.log('Did it!') };
}

// In English: If the input of main is "do it," then log "Did it!" to the console.

Before LLMs, a file of pseudocode instructions would, arguably, be harder to read and reason about than a programming language’s syntactic structure.

However, after LLMs, models can normalize pseudocode instructions into a programming language, preserving the readability/maintainability of syntactic structure but with the ease of English.

Let’s look at another example.

function main() {
  let str = "";

  for (let i = 0; i < 9; i++) {
    str += i;
  }

  console.log(str);
}

// In English: Start with an empty string, count from 0 to 9,
//             append the current number to the original string,
//             and then output the final string after counting.

In this example, the value of the syntactic structure becomes prominent. Proximity to “plain English” is not the measure for readability/maintainability.

However, pseudocode may be more precise than my example. It could contain the niceties of color-coordination and symbols that make instructions more clear.

 main()
   BEGIN WITH an empty String:str
   COUNT to 10
   APPEND COUNT>Index to str
   FINALLY, LOG str

Here, we can see some tradeoffs.

The most “plain English” versions could drift from giving programmatic instructions to output commands without any visual indication that this shift has taken place. However, when you are working in a defined programming language, you are always bound to programmatic instructions to arrive at the end goal. Comments are a non-essential feature where non-programmatic communication can provide further clarification.

The programming language makes reasoning explicit, and so, it is easier to reason about. Unlike output commands, you have an interpretable trace of “how the problem was solved,” not just “that the problem was solved.”

Perhaps you could craft a cleaner pseudocode grammar, but it likewise could drift from explicit reasoning to output commands without any visual indication.

Putting this together, the consistency of programming languages to adhere to bind you to “here’s how we get there technically” instructions provides real value.

But this is oversimplified. Programming languages already let you collapse explicit reasoning into a reusable command, which is what a function is, so collapsing reasoning into output isn't unique to pseudocode. It is the habit of software engineers to create layers of abstraction that effectively create output commands so instructions can be reused without the verbosity of the explicit reasoning each time. This gives you the speed and brevity of processing output commands while preserving the option to see the explicit instructions. The speed and brevity of processing, however, can be watered down when you have to traverse multiple layers of abstractions to fully understand the explicit reasoning that is taking place. This is the complexity of developing software.

Perhaps the matter is not quite as black and white as we perceive. Imagine if we could provide a syntactic structure that makes the shifting from output commands to explicit reasoning prominent:

function sum(left, right) {
  return left + right;
}

function main() {
  return sum(2, 2) * sum(3, 3);
}

// becomes

🧠 sum(left, right) { return left + right }

📣 Multiply 🧠sum(2, 2)by 🧠sum(3, 3)

// Another Example

function main() {
  let str = "";

  for (let i = 0; i < 9; i++) {
    str += i;
  }

  console.log(str);
}

// Could be rewritten as a mix of output commands and explicit reasoning

📣 Log "0123456789" by 🧠counting to 9 and 🧠appending the count index to a string

One can think of better examples. The point is to highlight the potential for symbolically differentiating command and reasoning. This directly answers the silent drift problem from earlier. Now, the shift between explicit reasoning and output command is marked, not assumed.

Although, my example isn’t concerned with how my symbols can be processed into lower-level code and the computational tradeoffs involved. However, LLMs lessen this concern since they have the intelligence to normalize such a pseudocode at scale, though whether that normalization can be trusted is a separate question.

There could be a legitimate workflow, as Truell suggests, where pseudocode is what is immediately written and maintained by the LLM, and some standardized, LLM-driven tooling can process into lower-level code to run in various environments.

Wherever this goes, it is something more complex than “explicit versus readable” carries.

Vibe coding refers to the sensation of being hooked to produce something via an LLM without the discipline of quality software engineering. With explorers surfacing new tools and workflows for agentic engineering, there is equal potential for vibe architecture. As software engineers make the migration to the agentic, it’s as important as ever to comprehend what goes into a sound agentic architecture. This article is pitched as a high-level introduction to the principles involved in evaluating agentic architecture.

An example of vibe architecture would be immediately moving to a multi-agent architecture for a project because of the buzz around it. However, it’s helpful to ask ourselves why there would be any need for this when LLMs are powerful on their own. What value does an agentic architecture truly add?

In a case study, Anthropic explored multiple agents to create a research system.

Why is there a need to break out the task of searching and checking citations into separate agents when presumably a single LLM has the potential to do such?

The same question could be asked of humans, but experience tells us that having multiple researchers working side-by-side may produce better results than researching being carried out by a single individual. This is the answer provided in Anthropic’s case study.

A more general answer is that whereas LLMs can produce high-quality responses, they lack the multi-step processing needed to solve real-world problems. Their responses are not shallow, but their inability to press beyond an immediate response, interact externally, and make dynamic decisions limits their effectiveness.1

In a word, there are some tasks that benefit from greater width, such as having researching agents running in parallel. On the other hand, when a task benefits from multiple workers working sequentially (i.e., building of each other’s work), a multi-agent workflow can provide depth depth. The trick to mastering a multi-agent workflow, then, is knowing whether a task’s execution may be optimized by adding the fitting ratio of width and depth. Width-depth discernment, then, is foundational to forming a sound agentic architecture. Optimal performance, however, is limited to what one can afford. Putting it together, the chief aim for a multi-agent architecture is to deploy agents horizontally and vertically to optimize performance within budget.

As soon as we introduce a team of agents with horizontal and vertical relationships, arrive at something familiar to us:

As soon as we have width and depth via multiple agents, we have an organization. Once we make this connection, we can draw analogies from human organizations to consider some additional tradeoffs in designing agentic ones.

History tells us that there is value in planning the structure of organizations upfront, as well as dynamically adapting an organization for changing circumstances.

For logistical reasons, the formation of Roman cohorts needed to known and strategically arranged before battle. However, Alexander the Great would gain real advantage against the Persians when rearranging the pre-decided formation based on a real-time read of the battlefield.

Napoleon’s brilliance on the battlefield was in large part due to his corps system. Armies were broken down into autonomous units that could each have their own dynamism due to the strong degree of trust in a shared military doctrine between Napoleon and his marshals.

Likewise, agentic organizations also have the potential to discern the proper width-depth ratio both upfront and ad hoc.

So far, I use these historical examples as illustrations to remind us that perfecting an organization—whether human or agentic—is both an art and a science. It is tactical, dynamic endeavor, and there is not one universal approach; yet, there are patterns for success.

With these illustrations in our imagination, we can begin to explore the tactical tensions in the race to architect agent organizations that are analogous to examples in human history. I’ll begin by continuing the upfront and ad hoc tension in shaping agentic organization, and, in the future, introduce other tactical tensions that involve the coordination, communication, and execution within those organizations.

Mapping the upfront and ad hoc tension to emerging agentic architecture, Claude Code allows for an agentic structure to take shape at runtime, whereas LangChain emphasizes defining the structure upfront. Meaning Claude Code leverages agents to dynamically determine the cost-performance optimization (getting the optimal width-depth ratio within budget) at runtime. LangChain leverages humans to determine ahead of time how agents should be structured for cost-performance optimization.

Here, we have two levels of considerations:

1. Human vs. agent determination — Should humans or agents be trusted with optimizing for cost and performance? And if the answer is both, then what is the precise division of responsibilities?

2. Timing — Should agent organizations structure at runtime, or should they be structured upfront? And if the answer is both, then what does it look like to stitch this together?

Predictability may be a tradeoff here. For example, perhaps defining organizational structures upfront produces more predictability with respect to behavior, cost, and performance, giving LangChain an edge. Or, perhaps shaping organizational structures dynamically gives an edge for cost-performance optimization, but things are less predictable. Or, maybe either approach can attain predictability and cost-performance optimization, but the consideration becomes the maintainability and training cost. In summary, cost, performance, and predictability seem to be the essential considerations, and the architectures being developed may not prioritize them equally.

These tradeoffs will impact the architecture of the tools that emerge for building agent organizations, such as Claude Code and LangChain. Moreover, these tradeoffs will impact which tool a particular software application prefers to leverage (and how exactly they leverage it).

In coming articles, I plan to go into further detail into the possible organizational structures of the tools, and how their potential weighs against the tradeoffs of predictability, cost, and performance. Then, I will explore how particular software applications may want to leverage those tools based on their own interests with respect to those same tradeoffs.

For now, we can conclude having established:

1. The reason for introducing agentic architecture

2. The definition of optimal agentic architecture as the finding of the proper width-depth ratio within budget

3. The illustration of analogous human organizations—like military ones—and their structures, workflows, and tradeoffs

4. The design choice of shaping organizations at runtime or a priori (i.e., ahead of time).

5. The design choice of what to trust humans with and what to trust agents with for an ideal organization.

6. The tradeoffs of predictability, cost, and performance that will be considered throughout

In summary, like calvary, we have scouted the contours of the emerging agentic architecture.

On a final note, while the connection between an upfront agentic architecture and human organizations is helpful (in my judgment), it becomes critical to avoid anthropomorphizing agents. It is also critical not to reduce our humanity to the agentic. As a philosopher, I share the conviction of being philosophically accurate and ethically responsible with respect to our magnifica humanitas. As an engineer, I also see the architectural problems should we conflate humans with agents. We will not get a multi-agent research system correct if we assume that agentic roles should applied toward a task in a one-to-one fashion as humans. Evaluation can happen when the precise differences between humans and agents are apprehended.

And the best way to ensure humans are known anthropomorphically, and that agents are not anthropomorphized, is to develop a distinct agentology—a philosophical understanding of agents as such. Regarding anthropology, I have written at length elsewhere. Regarding agentology, I will form thoughts as we go to help inform our more technical explorations.

If you’re interested in following this series which aims to provide cutting-edge insights about agentic architecture, and the deeper principles that drive them, consider subscribing and sharing.

Subscribe now

As a wrote in a previous article, there is a need right now for agentic workflows to be evaluated. Without evaluation, we are at risk of a “vibe architecture” in addition to vibe coding. Possible agentic workflows fall along a spectrum. On one end, you could have a flow of manual Claude Code / Codex prompting via a human; and, on the other end, you could have an enclosed, multi-agent loop that perfects writing and reviewing prompts and the code they produce.

Just like with humans, there are a variety of ways to run organizations. Business corporations, for instance, have dealt with experimenting with different organizational models for some time. Unless we have greater insight into how our agentic architecture is impacting the model’s ability to produce the ideal output, we risk adopting a workflow that either lacks the full potential to automate, or is overly complicated for the use case.

I plan to write about how we can make understanding the various agentic architecture and their tradeoffs more legible. However, in the meantime, I wanted to explore another way to make agentic organizations easier to grasp.

My idea was to build a visual engine with Phaser that would animate my agent organization.

Using Pokemon Red assets, I assigned a Pokemon sprite to each of my agents in my multi-agent workflow. The agentic workflow, for this simple version, consists of a sequence of calls to Anthropic’s models. Each agent plays a specific role in a research workflow based on Anthropic’s multi-agent research system. However, I added a Neoplatonic twist based on Pseudo-Dionysius’ De Coelesti Hierarchia (Of Celestial Bodies).

Specifically, I assigned three general roles: Purifier, Illuminator, and Perfector. By general, I mean that these roles could be applied to other problem spaces than by research workflow.

Purifier clarifies the task before execution by removing noise, surfacing constraints, and turning vague material into a usable signal.

Illuminator makes the “purified” task intelligible by supplying precommitments, context, criteria, and the right interpretive frame.

Perfector completes the partial outputs of the lower agenets by integrating, judging, reconciling tensions, and giving the work final form.

Here is the topology in my project:

export const roles = {
  purification: {
    id: 'purification',
    processName: 'Purification',
    roleName: 'Purifier',
    grammar:
      'Clarifies the task before execution by removing noise, surfacing constraints, and turning vague material into a usable signal.',
    receives: ['raw task', 'ambiguous prompt', 'unstructured context'],
    produces: ['clean problem statement', 'constraints', 'unknowns', 'usable task boundary'],
    responsibilities: [
      'Detect what is irrelevant, premature, contradictory, or underspecified.',
      'Preserve the user intent while reducing accidental complexity.',
      'Return a purified task object that downstream agents can safely reason over.',
    ],
  },
  illumination: {
    id: 'illumination',
    processName: 'Illumination',
    roleName: 'Illuminator',
    grammar:
      'Makes the purified task intelligible by supplying doctrine, context, criteria, and the right interpretive frame.',
    receives: ['clean problem statement', 'constraints', 'unknowns'],
    produces: ['framing lens', 'selection criteria', 'relevant doctrine', 'structured subtasks'],
    responsibilities: [
      'Choose the conceptual frame that makes the task legible.',
      'Translate clean signal into situated understanding.',
      'Prepare lower-level work without collapsing into direct execution.',
    ],
  },
  perfection: {
    id: 'perfection',
    processName: 'Perfection',
    roleName: 'Perfector',
    grammar:
      'Completes the partial outputs by integrating, judging, reconciling tensions, and giving the work final form.',
    receives: ['framed result', 'candidate outputs', 'partial judgments'],
    produces: ['integrated recommendation', 'final artifact', 'decision-ready synthesis'],
    responsibilities: [
      'Judge whether the result fulfills the original intent.',
      'Resolve contradictions between lower-level outputs.',
      'Synthesize the final response into a coherent whole.',
    ],
  },
};

Then, I clarified how these roles would function in my problem space of a research workflow:

export const problemSpaceRoles = {
  research: {
    id: 'research',
    label: 'Research Workflow',
    description:
      'A research specialization of the triadic grammar: transform a messy question into a scoped brief, parallel inquiry lanes, and a citation-aware synthesis.',
    roles: {
      purification: {
        roleName: 'Research Scoper',
        receives: ['raw research question', 'topic ambiguity', 'implicit quality expectations'],
        produces: ['research brief', 'source-quality bar', 'effort budget', 'coverage criteria'],
        responsibilities: [
          'Define the research question and remove accidental ambiguity.',
          'Set source-quality rules before exploration begins.',
          'Decide how much effort the query deserves before spawning research work.',
        ],
      },
      illumination: {
        roleName: 'Research Strategist',
        receives: ['research brief', 'coverage criteria', 'source-quality bar'],
        produces: ['parallel research lanes', 'search heuristics', 'subtask boundaries', 'gap checks'],
        responsibilities: [
          'Decompose the brief into distinct research lanes.',
          'Prevent duplicated subagent work by giving each lane a separate objective.',
          'Use broad-to-narrow search heuristics and adjust strategy as findings appear.',
        ],
      },
      perfection: {
        roleName: 'Research Synthesizer',
        receives: ['lane findings', 'candidate claims', 'source references'],
        produces: ['integrated report', 'citation-checked claims', 'failure modes', 'when-to-use guidance'],
        responsibilities: [
          'Integrate lane findings into one answer.',
          'Check coverage, source quality, and citation fit before finalizing claims.',
          'Soften or remove claims that cannot be supported by the research evidence.',
        ],
      },
    },
  },
}; 

Having established the functional roles of my agents, I gave them an embodiments—a certain creaturely persona:

export const celestialEmbodiments = {
  psychicLineage: {
    id: 'psychic-lineage',
    label: 'Psychic Lineage',
    description:
      'A psychic lineage expresses the celestial grammar as increasingly articulate cognitive power: a quiet receiver, a framing interpreter, and a final synthesizer.',
    roleDescriptions: {
      purification:
        'The Purifier should feel like a small, inward-facing celestial agent that listens before acting; it notices static in the environment; it reacts to activation by briefly sharpening in color, as if a fuzzy signal has become crisp.',
      illumination:
        'The Illuminator should feel like a focused celestial interpreter standing between raw signal and final judgment; it receives purified material and makes its meaning visible; it reacts to activation with clear, cool color and controlled psychic noise.',
      perfection:
        'The Perfector should feel like a composed celestial master of synthesis; it does not rush into the task but gathers partial meaning into final form; it reacts to activation with warm, decisive color and a longer completion pulse.',
    },
  },
};

Note: While I imposed these topology layers into a Codex chat, the model created these specific structures. The model took the most liberties with this celestial embodiment schema.

Finally, there is a topology layer that maps the celestial embodiments to specific characters, as well as mapping the relationship between the roles/characters:

export const embodiedCharacters = {
  abraPurifier: {
    id: 'abraPurifier',
    roleId: 'purification',
    embodimentId: 'psychic-lineage',
    displayName: 'Abra',
    sprite: 'abra',
    spriteBack: 'abrab',
    seedDescription:
      'Abra is a quiet purifier who sleeps near the boundary between confusion and clarity; Abra senses stray assumptions, irrelevant details, and missing constraints before others notice them; Abra prefers to simplify a problem before anyone tries to solve it; Abra becomes alert when a raw task arrives and settles once the signal is clean.',
    visual: {
      accent: 0xffb38a,
      sound: 'denied',
      x: 610,
      y: 486,
    },
  },
  kadabraIlluminator: {
    id: 'kadabraIlluminator',
    roleId: 'illumination',
    embodimentId: 'psychic-lineage',
    displayName: 'Kadabra',
    sprite: 'kadabra',
    spriteBack: 'kadabrab',
    seedDescription:
      'Kadabra is an illuminator who translates clean signal into understanding; Kadabra carries the doctrine of the topology and knows how to choose a useful frame; Kadabra turns constraints into criteria and criteria into structured work; Kadabra becomes brightest when a purified problem needs interpretation.',
    visual: {
      accent: 0xa4d4ff,
      sound: 'heal',
      x: 540,
      y: 352,
    },
  },
  alakazamPerfector: {
    id: 'alakazamPerfector',
    roleId: 'perfection',
    embodimentId: 'psychic-lineage',
    displayName: 'Alakazam',
    sprite: 'alakazam',
    spriteBack: 'alakazamb',
    seedDescription:
      'Alakazam is a perfector who waits for partial meanings to become ready for judgment; Alakazam weighs the framed result against the original intent; Alakazam resolves tensions between candidate outputs and gives the work final form; Alakazam becomes radiant when synthesis is complete.',
    visual: {
      accent: 0xf8eaa5,
      sound: 'getItem',
      x: 420,
      y: 170,
    },
  },
};

const roleCharacterMap = {
  purification: 'abraPurifier',
  illumination: 'kadabraIlluminator',
  perfection: 'alakazamPerfector',
};

export const topologyEdges = [
  {
    id: 'perfection-to-illumination',
    from: 'perfection',
    to: 'illumination',
    label: 'illumination descends',
  },
  {
    id: 'illumination-to-purification',
    from: 'illumination',
    to: 'purification',
    label: 'context clarifies',
  },
  {
    id: 'purification-to-illumination',
    from: 'purification',
    to: 'illumination',
    label: 'clean signal rises',
  },
  {
    id: 'illumination-to-perfection',
    from: 'illumination',
    to: 'perfection',
    label: 'framed result returns',
  },
];

Once I had the topology, I mocked a model event stream. The multi-agentic workflow would emit events to represent its current stage. Each event then got mapped to triggering a visual scene that animated the rendered characters.

After getting the mock workflow to work, I added a real-time agentic workflow. At a high level, the workflow turns one ambiguous research question into a staged, source-aware answer.

The Purifier clarifies the raw question into a tighter research brief: what is being asked, what is in/out of scope, and what evidence quality matters.

The Illuminator plans and runs research lanes, performing web searches, capturing sources, grading them as primary/secondary/tertiary/unknown, and building a source index.

The Perfector synthesizes the final answer from the brief and lanes, then runs a citation-readiness check to flag weak claims, unsupported numbers, or source-quality mismatches.

Around that, the system streams events to the Phaser UI, tracks cost, writes the full run artifact to /.agentic-runs, and updates an index with source counts, citation risk, and whether the output is publication-ready.

The neat part is that I can see the agents as embodied characters and get real-time, visual feedback as to what is happening in a workflow. If you’re interested, you can clone the repository and insert your own Anthropic API key.

As a final note, this is meant to be more than a fun “toy demo.” This is meant to open the conversation about how agents can be treated in a more imaginative way that makes the whole process easier to comprehend. More importantly, it moves the conception of agentic organizations as something very technical to something that is analogous with human organizations. If we can make that connection, the work of evaluating agentic organizations and architecture will be made easier, and potentially more humane.

Note: This project was heavily inspired by the Generative Agents: Interactive Simulacra of Human Behavior research paper.

In a previous article, I introduced a mental model to help grasp the sectors of work emerging in AI engineering. It may be helpful to read the article first, but the gist is that there are researchers, explorers, and stitchers working acrossing the AI engineering landscape. There are institution-backed researchers primarily investigating how to interpret and evolve model architecture. There is an explosion of free-floating explorers building prototypes, small products, and general tools and workflows. Finally, there are stitchers that are taking general tools and workflows to build a particular workflow for an engineering organization and/or team within a company. While these boundaries generally map to the pre-agentic software engineering landscape, researchers are in closer contact with the day-to-day engineering. Also, explorers and stitchers have more overlap, since many companies have reacted to hype and mystery by funding exploration efforts.

Surrounding all three kinds of work is AI-trajectory news and research, such as Anthropic’s economic index, Dario Amodei’s The Adolescence of Technology (and similar essays), stream of conscious insights/updates on social media and blogs, et cetera.

From this outlook, I’ve tried to see what gaps exist in the ecosystem and what kinds of work do these gaps fall under. Of course, research is foundational. Research is what has made the development of LLM architecture possible, and it gives shape to what is possible for agentic systems to accomplish. However, explorers are foundational in making research actionable. Meaning, they can turn research into usable tools and workflows. Since stitching is scoped to particular company and/or product, it is not as general as explorers and has the least impact on the ecosystem. It’s possible that explorer and stitching work is overlapping and general tools and workflows may emerge from company/product-specific contexts. However, I think it’s best to label this as exploration that occurs alongside stitching. This narrows down the highest-impact work (relative to the entire ecosystem) to research and exploration.

Nevertheless, there is something very valuable going in stiching work. That work is often occuring in contexts where the company has decided to provide serious investment for company/product-specific AI workflows to be developed. As teams are putting together are stitching together tools and workflows, the evaluation of the architecture is much more of an art than a science at this point. I’ve heard teams talk about having built up an architecture in the past few years during the hype race, and now needing to narrow things down and focus more on cost. In a word, stitching has surfaced that tools and workflows are not the only thing that is needed. Evaluation to inform the right architecture is now becoming a priority.

Here is where I see the highest value. It may begin with research, but it’s exploration that will make it actionable. The highest value is in exploratory work that provides guidelines for the ideal architecture that can be consumer by a stitching team. It is one thing for explorers to expose tools and workflows, and it’s another thing to expose guidelines on how and when to use those tools and workflows. Since stitching teams are the consumers, and are beginning to exit the hype-prototyping phase, evaluation is the highest value work at the moment.

It’s much harder than it sounds, however, as this is a different beast than software engineering workflows. With software engineering, it was easier to establish benchmarks to compare and contrast tools and workflows. As soon as we move to the realm of the agentic, we are ultimately producing software through a model. And interfacing with models still carries a black box, for we don’t really know how much of an impact our inputs to the model are making. How do we measure that this prompt produced a better result than if we wrote something a bit different? How can we be sure that our RAG layer was essential in the end result? So on and so forth.

The ultimate objective answer to these questions would require us to be able to see the reasoning of a model. However, this is a black box in the field of interpretability that is in a separate sector of research work. We can benchmark outputs but not reasoning at this stage. To benchmark reasoning, the companies behind the models will need to pair with researches to grasp how the models work—and some progress is being made here. However, companies will also need to provide a pane of glass into the reasoning after they wrap their heads around what exactly the reasoning process looks like.

I recently read Evals for AI Engineers, which is a helpful book for leveraging evaluation tools and workflows; and, I think this is the right place to start for explorers. General evaluation tools and workflows are needed. Moreover, there needs to be work done to examine the exact trade-offs around agentic architecture. There are various ways to leverage a model. If you’re writing software, for example, you could go to Claude and talk through your approach and then write the code yourself. Or, on the other end of the spectrum, you could orchestrate a robust agent organization via the LangChain ecosystem. Guidelines are needed to determine where on the spectrum a stitching team should land, and how to dial the knobs therein. When should a company introduce a RAG layer? When should a company use an orchestration architecture? And even if an orchestration architecture is decided upon, how should the agent organization be structured? These are the sorts of answers that didn’t need as much precision in the hype-prototyping phase but will now need to be explored. The place to start, in my opinion, is enumerating all the potential workflows and the essential tradeoffs that will guide the ideal choice for a particular stitching team.

There is one final warning I must give having said all this. The agentic ecosystem lives and breathes in thinking computationally. Even in the philosophical research, a computational anthropology is often assumed when the reality may be more complex. By “thinking computationally,” I mean that we tend to wait for things to emerge through empirical tests before we commit with confidence. However, if interpretability largely remains a black box (especially to explorers and stitchers), then we risk staying in vibe architecture. Moving from vibe coding to vibe architecture only shifts the problem. But there is an alternative option, and I believe it’s the only viable option at this point in time where model reasoning is a black box. We can look for analogies of agentic organizations—other examples when tradeoffs needed to be considered to form the ideal organization. We cannot find this in the agentic discourse, for this is all new (of course). However, this isn’t the first time humans have had to evaluate how to delegate tasks through a hierarchical structure. Scipio Africanus and Napoleon would say otherwise. This is where things get interesting and impactful. But I will save that for an upcoming post.

Subscribe now

There is a lot of buzz around the research papers, models, tools, and orchestration workflows around agentic workflows. It is exciting, but it also means we can get lost in rabbit holes. Every rabbit hole feels momentous because there are still so many unknowns and gold to be mined. By stepping back, we see clearly what is happening across this landscape at a high level. Specifically, I want to focus on the landscape emerging in the software engineer to agentic engineer migration.

I suggest introducing three terms to help clarify the kinds of work being down across this landscape.

One group of workers are the researchers. These are people focused on forming granular insights about agenetic workflows. This happens at a popular level, but it is most concentrated in academia or academia-adjacent circles (e.g., Google DeepMind). This group is examining how to interpret models, how to improve model architecture, how to evaluate the differences between small and large models, evaluating how prompts and agentic workflows impact output, providing a philosophical explanations for AI, et cetera.

Another group of workers are the explorers. These are people focused on exploring tools and workflows apart from a company-driven / product-driven problem space. This includes exploration work like building RAG layers, maximizing MCP tooling, testing the LangChain ecosystem (and other orchestration and evaluation tools), et cetera. This work tends to emerge from personal projects / thought leaders and tooling companies / projects. An example would be someone charting the course for using Figma Console MCP.

The third group of workers are the stitchers. Think of a company that takes their existing software teams and gives them the time and capital to invest in building out agentic workflows. Stitchers focus most on building of the insights of explorers, stitching together tools to form a cohesive workflow for a company / product problem space. For example, a large company invests in their existing design system team to create an agentic workflow that builds a new, highly efficient workflow to produce design system artifacts.

There is fluidity between the researchers, explorers, and stitchers.

Explorers can update their general tools and workflows based on emerging research and the feedback from stitchers.

Researchers are presumably the most autonomous, being furthest removed from a corporate problem space. However, the aspirations of explorers and stitchers can inspire new research projects.

Stitchers are presumably the furthest removed from research and rely the most on explorers. They need tools and workflows to stitch together for a company-driven / product-driven problem space.

This captures the dimension of kinds of agentic work, but there is another dimension worth capturing.

There is also a spectrum of how institutionally-sticky a kind of work is. I suggest a pet-to-institution spectrum to explain this.

Pet projects emerge from individual interest aside from an institutional context. For example, a stitcher may be exploring some tooling and blogging about it as a side project.

Institution projects emerge from structures with capital that are willing to invest in innovation. A corporate company may be willing to invest in a design systems team that can create their own agentic workflows. Universities might sponsor research into LLM architecture, for instance.

In between are community projects, things like open-source projects, pet projects that have gained community sponsorship (e.g., TanStack), websites/applications that seem formal but may actually just have a very small team behind them, et cetera.

If I had to guess, the researchers, explorers, and stitchers have these kinds of relationships with the pet-institution scale:

Meaning, researchers and stitchers are the most likely to reside in institutions; explorers dominate the community and pet space; researchers are least likely to do pet projects since research requires sponsorship to get off the ground (whereas explorer projects can grab more attention from a prototype by creating shareable content); and, stitchers will likely pursue pet projects, since people want to develop an online presence outside of their corporate / product contexts to gain get ahead of potential shakeups.

You’re welcome to grow and shrink these circles based on your observations, but hopefully this helps make visualize the phenomenon.

Now, it’s worth asking how this landscape compares to pre-agentic one. You likely could have drawn a similar graphic to represent the pre-agentic software industry. However, research has come into much closer contact with the explorers and stitchers than in times past. Moreover, there is much more hype that explorers can create standalone projects since agentic workflows expedite the software development process (among other things). Institutions also have become much more like financially-backed exploration labs. Exploration labs used to be original to large, creative companies like Airbnb, GitHub, et cetera. Now, I presume many corporations are willing to invest big in AI and create internal exploration labs that wouldn’t have received the investment previously.

Most importantly, there is much more fluidity to move across these kinds of work. A stitcher can write a research paper, and a research can build a product. Because fluidity has increased across these kinds of work, it’s as important as ever to grasp the bird’s eye view as boundaries become more blurry. If we don’t, then we can easily run fast in a direction.

By visualizing the full landscape, we can make more informed decisions about where to invest our efforts, how to network with those doing different kinds of work, and what content to prioritize digesting.

In future articles, I’ll explore how bird’s eye topology may inform what kind of agentic work has the most value in this landscape.

Subscribe now

AI is disrupting the job market, and it’s more than just “new technologies, workflows, and opportunities to dial knobs around.” The essential disruption, as I see it, is that AI is displacing workers while the already-weak fiat credentialing is exacerbating the problem.

By “fiat credentialing,” I mean the habit of abstract systems situated between an applicant and employer to orchestrate the judgment of “this person will do the job well.” The effect of fiat credentialing is that it moves the displaces the judgment of fittingness from direct human judgement and embeds them in institutional structures.

“To get this X role, you need a Y degree” carries a lot of power. It cements that one’s fittingness for a role cannot and will not be holistically and directly judged by the person who would be most impacted (i.e., the employer); rather, two abstract layers cause indirection: the credential-giving system (e.g., a university) and the credential-gathering system (e.g., the HR pipeline). The latter potentially introduces additional layers of abstraction via the applicant tracking software that mediates before a human gets involved.

Why would we ever make things abstract when direct, humane engagement could suffice? I don’t know.

I suppose the answer would be that to scale a job market, the credential-giving and credential-gathering systems would need to be established to expedite the sending and receiving of applicants.

However, abstraction does more than scale. It removes the messiness of personal communication. An impersonal application process removes the liability of hurt feelings.

We could learn on how to navigate such conflict, or we could avoid it. We habitually choose the latter—if our abstract systems are an expression of our societal values.

It’s also not clear that there’s a scale problem, especially when AI decentralizes what credentialing bodies and applicant tracking systems centralized. University instruction and the work involved in sifting through applicants has been released to the wild, but its potential to decentralize structures has not been fully realized.

I wouldn’t have recommended we blindly democratize knowledge and decentralize potentially-noble structures. However, I also wouldn’t have released AI into the wild as the first premise that leads to this conclusion.

If we are going to tolerate AI being thrown into the wild and demand that people adapt within the market, fluidly pivoting to new domains / kinds of works, then the market needs to adapt to handle such fluidity at scale.

We’ve placed the hands into disparate, abstract systems, and longer-term solutions ultimately need to be driven from within those systems. Granting that the need to scale to abstract systems was needed at a certain point in time, we need to learn how to rollback for the needs of this generation. However, workers will need a shorter-term solution if the are expected to eat the tax of learning how to adapt within the market.

The only solution I can think of is for workers to find avenues of micro-credentialing. However, 1-2 year expedited “certificates” is not agile enough, and finding “less than you’d usually take” work in a domain that has transferable skills won’t register just yet. Accessible video courses (e.g., Coursera) haven’t fully solved the credential gap either.

There needs to be some credentialing of “you’re clearly have general skills that would have a high payoff once you got onboarded into a new domain, and you’re worth the initial investment.”

If AI has caused this problem, then perhaps the saving power rests in the danger itself, as Heidegger once observed.

AI may create the smoke and mirrors needed to generate trust (i.e., credentials) for credential-gathering systems. For example, AI Cred gives you a score on AI fluency that could potentially serve as such a micro-credential. However, it would need some fine-tuning from what I’ve seen.

It’s ultimately smoke and mirrors because we can’t objectively measure AI fluency via AI tooling since interpretability tools that would provide such feedback are largely out of reach.

The world is operating off of psychological “vibes.” I wouldn’t choose this path, but I’ll find a saving power within it. If an AI fluency credential does the trick, I’ll take it even if I know it’s not entirely coherent.

I'd invite others to explore such micro-credentialing options.

It is quite the marvel to see clouds, rain, and fog descend upon the gentle hilly terrain of Virginia—especially the late-middle of Autumn, and especially in the early 19th century. Sunny and splendid Virginia beckons forth the vibrancy of life, and yet, a week of rain can run on through and enchant the land to something seemingly new. The temperature drops. The leaves turn. The wind less predictable. The fog oozing through the hills, forests, and mountains. Gardens and tea converge into trench coats and boots according to the work of nature.

Here he comes. A country gentleman in trench coat and boots, with his faithful horse Coriander—she truly was zesty when crushed. He gallops along the middle lane of his estate. A row of mulberry trees that hardly cast shade any longer, and columns of lanterns as dusk likewise gallops.

Arrived, he unmounts Coriander, walks her to her stable, and gives her a long brush. Exiting the stable, it was that calm and mysterious time of day where one can see objects ahead, but they are nearly invisible. He made his way to the front porch main porch and ascended the steps, passing columns on his left and right. He removed his boots and took a hard look at them, for he was a man that thought carefully of all his doings and of every moment that could imbue something grand. He loved those boots, and he loved his estate. He gave the front wooden door I hard pull. It creaked open.

“Randolph William, sir.” spoke a mild-appearing man. He was neither tall nor short, neither thin nor thick, but he had quite remarkable hair. Long and wavy like a man who should lead a cavalry.

“Pleasure to meet you.” he continued, now standing with hand extended.

“Bennett Mason. It’s a pleasure to have you join us. We have been eagerly awaiting your arrival. I hope you have not waited long.”

“Oh, not too long. I’d say about 40 minutes, but it is no bother, especially when there are so many amusing things amassed in just a single room.”

“What was your favorite?”

“My favorite what?”

“Your favorite item,” answered Bennett.

“Oh, that is tough…I’d say the painting of Cicero. The Roman Republic. What a marvelous epoch of history,” said Randolph with shy gleefulness.

“You are a learned man, Randolph. Your friends speak well of you. Every one of them. They say your mind is not quite like any others in Oakdale. You follow where the breadcrumbs lead, and you find trails that no mind has discovered because they are stubborn in their ignorance. You will do well here.”

Bennett resumed after a brief pause and warm glance, “I apologize for my late arrival. I had affairs in town to attend to. Now, let me show you your place.”

They proceeded through the long hallways of the estate. It was dark, so mostly all that could be seen were the candles leaning from the walls like torches. But there were all kinds of pictures along the wall, like the gallery that served as a museum of a eccentric intellect. At last, they turned a corner and where before a spiral staircases stretching in both directions. They went down, curving around stone walls now lit by torches. Toward the bottom, the view emerged—as much as is possible in darkness lit by faint torches. It was a massive study, or was it a library? Perhaps it was a dungeon, but of a cozy sort.

Randolph marveled. It was the kind of place that mirrored his soul while simultaneously enriching it. It was dark and mysterious, yet incredibly uplifting. He could not believe he had landed this opportunity, studying for the legendary Bennett Mason. After another walk as seemingly long as the path to the stairs, they passed various nooks with an array of books, desks, chairs, and now obscure artifacts. It was that perfect blend of orderly yet messy, traditional yet eccentric.

“And here, Randolph, you will let your mind wander. You will begin when you choose, and you will end at your liking. You will room here, and you will board here. You will also garden here. You cannot see it now, but in the morning the rays of the sun shall wake you, and you shall behold a long meadow with a forest backstop that is seemingly miles away. There is a vegetable garden, a kitchen garden, a flower garden, and a wet garden. Do as you see fit. Follow each poetic breadcrumb to your liking.”

Bennett looked down smiling, and gradually lifted his chin saying, “Randolph. You’ve earned this. I have not needed to see myself, for the report of others serves enough for me. Do not let wonder and beauty escape you. The other researches will occupy their studies to research the domains of their mastery, but you master them all. You’ve earned your stay. The only ask, as we discussed earlier, is that you gather a report from each researcher during breakfast and translate it into a plan of action for my day. Should leisurely gardening be what you need thereafter, follow that instinct. Should it be researching something of your interest, follow it. And should it be delving into the topics of the other researchers, pursue it and share your findings.”

“I am honored beyond measure and lack words. I will not disappoint on your daily report, and I will treasure this opportunity. I am grateful.” replied Randolph shy gleefulness

“Very good, this treasure suits you.” retorted Bennett. “Now get some rest, and be ready to great the woods and gardens in the morning. Chamomile tea is available at the end of the hallway, should you desire. A goodnight and warm welcome.”

The sunlight came just as Bennett predicted. Magical yet not detached, the impression anchored Randolph. He caught the smell of something buttery, and exited his room and helped himself to biscuits, blackberry jam, and breakfast tea—all of it made from the estate’s bounty, according to the elegant chalk menu. On his long walk to the breakfast nook, he caught a glimpse of all the studies. In the evening, they were magical, and now, in the morning, they were impressive. At each study nook was a wooden sign with a name and title, such as “Frances Lee, Mathematician.”

He was a bit nervous to know who these cast of characters would be, but he was mostly excited. It was like stepping into a fictitious world that was even more fictitious because it was real. He was distracted momentarily from his reflection by the noises of pots, pans, and voices.

“The jam is splendid. Five years we have made this, and I do not know if it is better or worse. What matters is that it came about. Another seasonal routine in motion that will soon turn to memory. A double savor.” exclaimed Mrs. Mason.

“Unbelievable.” thought Randolph.

After this ordinary moment bliss, Randolph remembered that Bennett had mentioned the researchers would arrive shortly after breakfast, and so, he took a quick bath and got himself dressed.

“Good Morning, Frances. I appreciate your commitment. Tis an ordinary day, but my gratefulness does not require novelty. How are the wife and kids? Has your wife recovered from her cold?” Randolph, exiting his room, heard Bennett say at the top of the stairwell.

“Thank you, sir. Tis a privilege to exercise my mind today. She is all well now. A little rest and tea did its work, and the kids will play in the woods today. It gets no better than that.” replied Frances.

“Certainly. Please take biscuits, jam, and tea home for the family if you desire.”

“Thank you, sir.” said Frances warmly.

“And Frances,” concluded Bennett, “Randolph has arrived. Please greet him once he emerges from his quarter. Good day to you.”

Frances immediately met Randolph who was standing at his nook.

“Why is that Randolph William? Pleasure to meet you—Frances. Frances Lee from Bedford. We’ve all heard great things. Remind me where you came from.” said Frances warmly.

“Likewise, Frances. It’s a privilege to be here. I hear you study mathematics. When did you start here?” asked Randolph eagerly.

“I joined as a researcher about 7 months ago. Great experience. I’ve been architecting the plans for a library for Oakdale. In fact, I finished the plans yesterday afternoon. Imagine that. Here you go. Mr. Mason will be delighted.”

“These look…splendid.”

“Good things take time, Randolph. Remember, this has been 7 months in the making, and Mr. Mason conceived of idea years ago. He is the businessman. I could never make deals like he does, but he is a learned man and poet inside. Anyways, I better get started with my day. Now that the plans are complete, I’ll need to put together a more detailed budget report. We break for tea at 11, and I’d be delighted to talk more then. Really glad to have you here.” concluded Frances.

And so, Randolph had many conversations of this kind, meeting all the researchers of Mr. Mason’s estate. It was a dream. They really did break for tea, and he really talked to Frances about the history of Cartesian mathematics, amongst other things. It was as if Randolph’s mind had a nest in Frances and the other six researchers.

However, good discussion was just one layer of the joy he felt that day. He felt like a kid in a candy shop as he toured the estate with its long hallways, creaky doors, assortment of books, items, and picture frames. Later that evening, Randolph gazed out into the nearly black view of the woods and gardens, crunching up on his bed with a candle and scone to read for pure leisure. He had found a vocation that felt more like a dream.

And in this dream he remained. The first six months felt like a decade as every moment was new, sublime, and imbuing his life with wonder. Things were not perfect. He had messed up the morning report, so that when Mr. Mason went to town to utilize the research for practical affairs, there was miscommunication. Bennett remained calm, fatherly, and somehow even his rookie mistakes felt dreamy and something he could relish with candle and scone.

The next five months weren’t this kind of magical, but they were still magical. Things moved alone more quickly having become more familiar, yet still happily, like the rereading of good novel.

Things changed in one Summer evening.

“Gentleman. I called you together this evening to be honest about my affairs. As you know, your research has been instrumental to developing various kinds of buildings and projects in the town of Oakdale. This work has been highly successful, and we thank God. However, Mr. Lee’s library plans have led to an unexpected situation that is hurting business.

It turns out that the library transferred ownership from the town of Oakdale to Isaac Nettleton, a wealthy gentleman from the settlement of Eggleston, and he has brought with him three hundred Scots-Irish workers.

“Three hundred workers! But I came with you to town just the other day, and there were not that many new homes established.” remarked Nigel Baxter, the historian.

”Why Nigel, they all reside in the library. The have a rotation such that workers are researching in the library all night and day. They closed off public access to the basement, and the workers sleep there when they are not on duty. They live like cats and dogs I tell you, but collectively they’re learning like Da Vinci.” explained Bennett.

“This unending rotation of studying has produced the most fascinating results,” continued Bennett, “and they’ve invented many things. For instance, they have discovered a new design for buildings that costs a fraction of our traditional wooden homes. They have remade old Roman cement and have used it to quickly make a cube-shaped home.”

“I saw one of them.” interjected Nigel. “Truly an eyesore, surely one would go mad in of those things.”

“People will make do if they are coming from even madder conditions, like those coming from the remote communities along the western part of our state. Such a home is quite an upgrade if it brings them to Oakdale.” explain Bennett.

“And what else have they invented?” asked Mr. Roberts, the scientist.

“They are able to review legal codes at six times the speed as Mr. Walker…”

“Certainly this is a violation of town law. Give me forty minutes, and we shall have our lawsuit!” interrupted Mr. Walker.

“That will not do,” answered Bennett, “for they are protected by a charter from the state. There is much interest in inventions for our young state and country, and there is money to back that interest.”

“How much are they making? And how did Nettleton secure such a charter?” questioned Frances.

“Enough to purchase my estate and provide you with an equivalent salary.” answered Bennett. “Nettleton has familial ties going back to Williamsburg. He is a learned man and was able to convince Richmond. He had a prominent military career in our late war and settled in Eggleston hoping to make a profit in that remote region. In any case, they are outpacing all our affairs, and they are securing better profits.” Bennett stared solemnly at the floor. It would be a moment for tears in novels, but real life is often dry under such duress. “We have one month to continue operations, gentleman.

“Oh forget it all! What have we come to that a library of rough men, living like cats and dogs, are being rewarded for producing ugly buildings. What of beauty, and honor, and custom?” asserted Taylor Mosby, the linguist.

“Profit overlooks the treasure of a creaking door that is slightly imperfect. I’m afraid we are a creaky door operation of sorts, and the times are changing.” replied Bennett solemnly.

Randolph could not believe what he was hearing. On the one hand, he had heard rumors of these sorts of disturbances in other states, but nothing of this degree. He was happily naive to forget this news in a dreamy world of candles, stones, and leisure. Bennett had secured from him something distinctive from the University, or even the local school, and for all his brilliance he assumed this arrangement would last.

He paused, as he usually did. It was always quite a sight to him starting into the distance with his hand on his chin. Would the others see his wonder or believe him to have gone mad? In either case, he was madly deep in thought. Scenes of history flashed past his brain, looking for historical parallels that might provide a solution. This and other such analytical tactics made him practically non-present.

He grasped what had occurred. Nettleton had found a vulnerability in Mr. Mason’s plans. He dared not compete as another man of business, for even three hundred men would not outdo Bennett’s established success. Instead, he framed his plans as research, leveraging familial ties in Richmond to garner support. This was impressive but not remarkable. What was astounding was his insight to lead research like he was leading troops. Presumably anyone could have done this, for Bacon long ago publicized science, and Mr. Mason had the ingenious idea to scope this down to a town. It required carrying out a total affront to custom, as Mr. Mosby had astutely observed, and surely Nettleton should have been the most attached to it.

Now, however, was not the time to comprehend how Nettleton came to the strategy that he did. It was time for Randolph to counter with his own. The path of least resistance was to mimic the operations of Nettleton and compete with similar products, or to move from Oakdale and apply his operations elsewhere. Alternatively, an agreement could be sought with Nettleton to have Bennett’s men direct the library operations. But for a mind like Randolph these ideas could never move beyond a faint thought. Beauty, honor, and custom could never be compromised.

He paced back and forth and his surroundings seemed to vanish while simulatenously pressing in all at once. This was no intellectual abstraction. He thought of the wives, boys, and girls of the researchers. He recalled the candle, scone, and fireflies that were adjacent to his magical threads of inquiry over summer nights. He recalled the smell of the buttery biscuits and chamomile tea, and the warm smile of Mrs. Mason that served them. That all this could evaporate called forth the powers of an already active mind.

“We shall garden” stated Randolph boldly. “We will offer to garden the various landscapes of Oakdale, but only on public land, for we dare not make a product out of man’s leisure. We will also maintain a vegetable garden on the southern slope of the town, having the fruits be administered through the church for those whose harvests fell to misfortune. We will be ready to build estates with creaky doors. We will offer to help write humane legislation as long as it takes to get it right, and we will grow our own food so long as it takes to outlast this present fever.”

Randolph was still staring away from all others yet all eyes were on him. “I will sacrifice my research time, but I will not trade away work as poetry. It may be a year (or years) where we spend little, but your little ones will have enough. Better to toil away in our gardens than to lose them without toil.”

This is what Frances Lee saw in Randolph. The plan was so simple, but to most taking on such hardship would not have been considered. Or, if it had, it would not have been committed to without any shrivel. Men like Lee knew that it was not just the plan but the contemplation and confidence behind it that made Randolph Randolph.

As soon as Randolph uttered his concluding sentence, a loud knock on the front, creaky estate door could be heard. Shortly thereafter, Mrs. Mason exclaimed, “Sir Goodwin Marshall from Richmond has come to see you.”

“Coming dear,” replied Bennett.

But Goodwin had already made his way to the basement. His boots could be heard coming down the stairs before his body came into frame. At the bottom of the stairs, Bennett was prepared to greet him as the researchers, rather anxiously, looked on from their meeting table.

“Splendid estate, Mr. Mason,” shouted Goodwin.

“Bennett Mason. Pleasure to meet you, sir. Thank you. We have put in much work since my grandfather transferred ownership to me.” responded Bennett.

“What a sight to gallop through the column of trees and torches as fog mingled through the estate’s backstop of woods. The columned porch and creaky front door, and the smell of pumpkin pie and cinnamon tea as I walked in. You surely are from English stock.” Goodwin paused. “This all seems too good to be true for a man who is neither an academic, lawyer, politician, reverend, or military captain. I hear you have been running some sort of…operation down here.”

Mr. Mason nervously answered, “Why, yes. The University has become rather fussy about its demands for scientific research, reducing the magical quality to something rather mundane. Moreover, we hope to shape institutions and communities that we will see unfold with our bare eyes. And so we have aimed at making Oakdale a reputable town away from Virginia’s more historic stays.”

“And what of this Isaac Nettleton?” interrupted Goodwin.

“Yes, sir. Well, he has seen the reputation of Oakdale and sought out a charter from Richmond. He has produced the scientific output of the University in the most grotesque fashion. His men are working like cats and dogs, treating research like a machine and working without break.” said Bennett.

“And you are without work?” countered Goodwin.

“Well, we were in the middle of discussing our next steps. If we do not pivot, then our livelihoods will tossed to the ruins.”

“There will be none of that,” spoke Goodwin. “Nettleton and his men have until the end of the month to return to Eggleston, and their charter has been suspended.”

Mr. Mosby dropped his spoon, causing an echo to reverberate through the basement.

Goodwin placed his hat back on his head and turned to head up the stairs. “Surely, you good men of Virginia did not second-guess Richmond and her duty to preserve the beauty, honor, and custom that makes Virginia Virginia. Enjoy your labors!”

So Oakdale continued.

Here is a very basic explanation of how LLMs work: Models take the words of a prompt, represent them in a geometric space, and then apply geometric manipulations (learned from training) that consistently retrieve the most probable meaning of the prompt (i.e., a semantic understanding). Possessing the semantic understanding, the model can predict the next word to respond with and then repeat the process until a final response is created. The goal of interpretability is to develop tools that shed light on how exactly the model progressively develops its semantic understanding. Most recently, Anthropic wrote on its Natural Language Autoencoders.

If, as we said above, words are represented geometrically in the model’s workflow, and geometric manipulations occur to develop meaning, the transformed geometric representations could be translated into language at some point before the final response is created. Like examining individual pages part of a flipbook animation, we should in theory be able to translate the snapshot of a model’s semantic understanding into natural language.

By having access to the individual “pages” in natural language over the course of a model’s striving toward full semantic understanding, we should gain comprehension of how the model tends to work toward full semantic understanding from prompts.

While simple to describe in theory, it takes code and powerful computation to pull this off--but this is what Anthropic has done with their NLA’s.

Examining their open-source code, the architecture is not too difficult to comprehend, when stripping the technical details not necessary for a basic understanding.

The training system has an Activation Verbalizer which takes an activation layer (i.e., stage in the “flipbook”) and takes the geometric representations of words and translates them into natural language. Having extracted the natural language translation, the Activation Reconstructor then converts that natural language description back into a geometric vector. If the reconstruction closely matches the original vector, the description genuinely captured what the model was representing at that stage. Meaning, it can be confirmed that the natural-language description and the geometric reality correspond.

There are some interesting technical details worth exploring if you’re interested. However, our interest here is to take the gist and map it onto Aristotle’s linguistic theory.

In On Interpretation, Boethius, commenting on Aristotle, notes that interpretation refers to the significant vocal sound that signifies something by itself. Hence, all parts of speech with exception to conjunctions and prepositions are signs.1 Aquinas summarizes, “a name signifies the substance of a thing and then that the verb signifies action or passion proceeding from a thing.”2 The simple point is that interpretations signify existing things.

Hence, Aristotle implies that our speech maps to real things (technically, also imaginative transformations of real things), and that real things may be internalized in humans well enough to articulate them through language.

The natural question that emerges is how humans internalize real things so as to be able to articulate them. Aristotle answers this in On the Soul. Very briefly, Aristotle posits that all knowledge is principled in sensory experience.3 It is through contact with sensible objects that we eventually attain the concept of them, and those concepts become the foundation from which language emerges. After contact with the five senses, the disparate sensory inputs must be unified, then our imaginative power creates an image that represents the basic elements (e.g., color, shape, number) of that sensory input.4 Moreover, as the Aristotelian-Thomistic interpreters develop more explicitly, the cogitative power creates an image of the perception embedded in the unified sensory input, and this perception is comprised of aspectual, actional, affectional percepts.5 Simplifying the jargon, individual things and their features, potential actions, and the emotional impact of the thing are all represented via an image.

What is quite incredible is that flash forward to the present, and Peter Gärdenfors has presented a conceptual spaces framework that posits that the cognitive phenomena may be best modeled geometrically rather than merely symbolically (classical logic) or associatively (statistical probabilities) since geometric representations allow for similarities and differences between things to be “visualized” and measured.6 I’ve drafted an extensive paper connecting Gärdenfors’ framework with that of Aristotle for those interested in a deeper dive on this subject.

But Gärdenfors’ framework, for all its explanatory power, only accounts for the cogitative layer, meaning the geometric categorization of perceptual images. Aristotle goes further. Fleshing it out, the perceptual images of things generated by the cogitative power does create a categorization of things that allow for basic inferences, as Gärdenfors articulates. However, there is an additional step “above,” for there is an immaterial intellect that is able to strip the material conditions of the perceptual image to possess an universal, absolute conception of a thing (i.e., a concept). From this concept, things can be compared and contrasted necessarily, logically rather than from material geometric comparisons studied by cognitive science. There is discussion as to whether the signs in Aristotle’s interpretations map to the perceptual images or the immaterial concepts. The answer is likely both.7

In either case, the fascinating connection with LLM architecture is that geometric representations of words, and transformations upon them, are the means to developing semantic understanding. This parallels Aristotle’s theory that real things take on a geometric representation as an image in the brain and that words, in some manner, are derived from these geometric representations. Hence, while Natural Language Autoencoders are a breakthrough in interpretability tooling, they are not a wholly original idea. Aristotle’s theory, begun long ago, would predict such a translation to be possible. While I’ve enjoyed commenting on the Aristotelian parallels as Anthropic releases new research, my interest and hope is that Aristotle’s framework could be applied to inform interpretability tooling (among other things at the center of AI research) instead of waiting until it is accidentally discovered. In either case, I’m very much enjoying the ride.

In a recent article, I tried to gain more precision on how the agentic shift to “judgment” carries an experientially significant reworking of a software engineer’s workflow, and how the common appeal to remaining “judgment” is too simplistic. Here, I’d like to double-down on one key aspect of this experiential shift: the lack of feedback in agentic development workflows.

Before agenetic development, there was a spectrum of ways that you could measure your success as a developer. The most immediate is task completion. You are given a task, and you write code that works to complete the task and its embedded requirements. How do know you’ve written code that works and that it meets the requirements? First, you can have a logical assurance. You can reason about the code because you wrote it and trust that it makes logical sense. Second, you can write tests, compare them against the requirements, and have a measure of assurance when the tests show green. Third, you (and perhaps others) can manually test the code. Arguably, the first kind of assurance could get obscured if you develop a mental habit of not reasoning through every angle of the AI-generated code. Assuming good habits, not too much may seem to change. But that’s on the surface level. It is on the higher-order level that the shifts emerge. You lose the innate assurance in pre-agentic workflows that you contributed something others could not produce.

Before the dawn of LLMs, you had a tacit confidence that you were doing something non-software engineers couldn’t do. You didn’t think about it. You didn’t question it. You just knew that you were writing in a programming language, untangling logical problems, and adding a dimension of quality on top of it all through not obvious refactoring and design patterns. A non-engineer would not be able to get past the first hurdle of understanding a programming language. As we absorb more and more non-engineers publishing code-driven apps, see LLMs produce something extensive from a simple prompt, and encounter how LLMs can explain concepts better than published blogs, does our value-edge weaken? This is the hard question, and it gets answered with “judgment,” but as I’ve argued before, LLMs do absorb “judgment” as well: they can review code, write code that is logically coherent, and refactor.

One might be tempted to say that their prompting is their value-edge. They have confidence that a non-engineer could not produce the quality of prompting as quickly as they did. However, not only is the path to learning prompting made easier to anyone, but the impact of your prompting can be overvalued. For example, I recently experimented with different ways of asking Claude to create a pure CSS pokeball. I used to spend hours at a coffee shop cranking out these kinds of pure CSS images, but Claude provided something quite impressive with a simple “Please write a pure CSS pokeball” prompt. When I made the end goal (i.e., final cause) explicit, it produced something more robust.

When I was a bit more vague in my writing about the end goal, I got something worse. However, it likely would have corrected itself with a few more prompts. So what did my awareness to be explicit in communication save me? Having to write a few more prompts (at most). In order to have a value-edge, I’d either need to have known to ask for a pure CSS pokemon (or other requirements) when no one asked, but this alreadys puts us beyond mere task completion into something categorical different—product engineering of sorts. Or, I’d need to know that the prompt-saving (due to my better communication) really made a difference at a certain level of scale/complexity. But such benchmarks are not obvious.

I did a similar experiment with asking Claude to produce poems with Lord of the Rings parallels (norse mythology, elvish, medieval, etc.).

What I discovered is that my most explicit prompt (Please write a poem. The essence of this poem is a elvish medieval kingdom inspired by norse myth that focuses on eucatastrophe. The rhyming scheme is accidental. The formal cause is to provide a poem that stir and uplifting sense of an adventure and final destination.) was not substantially better than my less technical prompt (Write an elvish medieval kingdom poem inspired by Norse mythology with an uplifting sense of arrival and adventure at the end, rhyme scheme doesn't matter).

“Eucatastrophe” is a specific introduced by Tolkien in his On Fairy Stories essay. My explicit mention of that may not have produced better results since the model is already “internalized” Tolkien et al’s material.

Of course, this is all subject to interpretation since these are loose tests comparing prompts with their outputs. However, so long as we do not have the interpretability models that can trace the “reasoning” of an LLM (as the LLM companies possess), then we don’t have clear knowledge as to whether our prompts actually sent an LLM in a better direction than if it simply inferred from its own “internalized knowledge.”

Bringing this back to the basic developer experience of task completion, the more obstruction of confidence in our technical knowledge as differentiating value, the more existentially destabilizing the apparatus becomes. At some point, will having only having the end product as the benchmark of our impact destabilize the whole developer experience? Or, will we remain happily naive in thinking that our prompting is uniquely impactful to generate the end product even when we don’t have an objective trace? Perhaps its existentially best to not raise these questions.

To Rivendell where Elves yet dwell
In glades beneath the misty fell,
Through moor and waste we ride in haste,
And whither then we cannot tell.

JRR Tolkien, Farewell We Call to Hearth and Hall!

On my LinkedIn feed, I am continuously encountering posts about “Software engineers are still needed. It’s always been about judgment, and that’s more important than ever.” This is naive.

The False Camera Analogy

“Smartphones brought the camera to everyone, and photographers adapted and found success. AI being brought to software engineering is not any different.”

False analogy.

The democratization of cameras and AI are not analogous. First, there is still an art and a poetic sixth sense that makes for a good photographer, and this remains regardless of the medium. Whether you are using an iPhone or a more powerful camera, you still need an eye for a fitting background, techniques for finding good lighting, understanding of layouts and perspective, et cetera. The instrument (i.e., cameras) have been made ubiquitous, but not the art. The iPhone doesn’t press down at the perfect moment, tell a family to smile, move itself from this position to that position to get multiple angles in a narrow window of kids holding still. Second, professional photographers (typically) spend money on nicer equipment, better software, and partnerships with strategic venues. There is some association between upfront investment in a better instrument and a better end product.

Contrast this with agentic development. AI doesn’t just offer you a new medium for your art of crafting a programming language. It’s not an improved code editor or an adjacent tool of that kind.

In Peri Hermeneias, Aristotle distinguishes between names and enunciations. A name is a sign of a concept without an assertion. An enunciation is a composition of a subject name and predicate name that makes a truth claim about how two things actually stand. For instance, “Socrates is a man” asserts that Socrates belongs to the category of “man.”

Code is slightly different. A function definition signifies a procedure without executing it. It asserts that this operation should be performed on this data. In this way, it isn’t just describing states of affairs, for it also produces them.

In Metaphysics, Aristotle claims that all material beings are composites. Every material being is made up of matter and form. For example, a marble statue has the matter of marble but the form of a statue. Similarly, code has a functional form amidst all the various lines. Namely, it has a functional output that it produces: a program runs without errors and passing tests. Ultimately, there is an output that needs to be produced from inputs, and something can be functional regardless of whether it's legible.

The art of coding is more than reaching the functional output, for it also involves refactoring. Any engineer knows what refactoring feels like: thinking hard about the names of variables, functions, etc., splitting out dual purposes in functions, deciding whether to make a block of code dynamically reuseable for multiple callers, determining whether to utilize your own code or to reach for a public and reusable library that may do the same, etc. To describe this phenomena more accurately, we can say that good refactoring makes the end goal self-evident. In metaphysical terms, it is making the formal cause of the solution legible. Good naming conventions can help you know what you are working with, how you are handling that what, and why the various steps are helping to attain the end goal (i.e., the output).

function slurp(derp) { return derp + ‘chirp’ }

The example above obscures the concepts involved through poor naming conventions.

Functions can also create boundaries of abstraction. The following terms are helpful to explain this:

slinky, toy, object = increasing extension / abstraction (becoming more abstract)

object, toy, slinky = increasing intension / concreteness (becoming less abstract)

Now, review this code:

function getFullName(name) { return getTitleCase(name) }

function getTitleCase(string) { return … }

In this example, the order of functions increases in extension. “getFullName” is specific to a unique set of data that presumably models a person. “getTitleCase” is a general string manipulation that can work on any kind of string.

The art of refactoring requires determining when introducing a layer of abstraction (i.e., a more abstract, general function) is worthwhile. The alternative is that you’d fully write out the same same string manipulation logic in every instance. This means you don’t have to remember two functions, but it comes with the cost that you could accidentally create inconsistent behavior across the codebase and/or you make yourself write more lines of code than otherwise possible. There may be a functional cost, a cost of time, and/or a cost of legibility. In other words, deciding on something like whether or not to introduce a helper function is considering the knowledge of what and the knowledge of why that will persist in the codebase. Weighing these considerations and making a decision falls under what Aristotle would call practical prudence, and what we tend to label as “judgment.”

This is just a pencil sketch of how the what, how, and why is central to refactoring, but it serves the general point. “Clean” code is code that makes the programmatic instructions more intuitive to the reader.

Going back to the phone illustration, smartphones make the instrument more accessible but do not automate the art of knowing what, how, and why with that instrument. Joining smartphones and AI to form an analogy about the impact of technology on an industry, therefore, does not hold.

Judgement Absorbed

The remaining-judgment-despite-AI discourse at times can misconstrue what exactly AI is able to do. Consider the refactoring example. AI can still write code that would be, to some degree, functional and legible. There, of course, are cases when it is not fully functional (i.e., has not handled every case, has introduced unintended side effects impacting the holistic end goal, etc.) and when it is not maximally legible. However, AI can be quite impressive with the code it produces, with respect to both function and legibility. Hence, it is more accurate to say that AI still requires a degree of judgment, and that degree can vary case-to-case. The point being is that AI does absorb the exercise of judgement.

Additionally, even when you need to add your own judgement to perfect the output of AI, this can be done in a “set it and forget it” kind of way—like in context files—that even more absorbs the degree of judgment needed in a day-to-day workflow.

Moreover, using an LLM to talk through potential design decisions et al absorbs even more judgment about whether to look for information and expedited the determination of what needs to be done.

We could continue but the point is that AI absorbs the need for human judgment. Say AI absorbed all the judgment except when to click a button to write and release code. Judgment would still be required, but that avoids the harder question. The real question is not about whether any slice of judgment remains, it is about what is the portion of judgment remaining when all is said and done—and what is left for the mass of developers that were needed for that judgment only a year or two ago. For those who remain, the question is whether the judgment required today is the judgment that will be required tomorrow as AI accelerates not only its own judgment but also the judgment of others on how to maximize AI’s judgment.

Software Folk

Another critical phenomenon is often not addressed: the quality of software engineering that remains. In this case, I’m not talking about the code’s quality; I’m talking about the coder's quality [of life].

Right now, engineers remaining are still riding the wave of novelty. However, that novelty may be masking a qualitative crash.

Quality of work impacts the quality of life. The notion that we can overcome issues in work quality with hobbies has its place, but it has a finite limit. What, then, makes for quality work for an engineer?

Things have not changed since Aristotle. Happiness involves excellence, and excellence involves good accomplishment despite challenges/hurdles/friction. Besides the general, humane applications of this, I want to focus on the phenomena of coding more narrowly. Engineers, of all stripes, like solving problems. Why? Because problems contain hurdles by definition, and solving them merits happiness by nature. While various domains of work involve problem-solving, the very thorniness of analytically-demanding problems is the joy of an engineer.

It is rather evident, then, that AI takes some of the joy away. This is not a novel claim. However, it’s worth reflecting on these more granularly.

As noted above, coding requires the challenge of being given a problem with certain requirements as parameters and shaping the functional form to solve it. However, most experienced engineers hit a point where the challenges in the functional form are not as demanding as they once were. However, there is the challenge of making the code as legible as possible, and the very interest in such is typically a signal of an engineer’s technical maturity. Testing, DevOps, new projects/products/teams, all serve to keep the love for solving problems alive and well. As AI automates, the problems shift to the adjacent, but there is finite limit. None of this is novel.

My more original claim is that physically writing out code creates a friction that merits happiness per se. There have always been domains of work that differ in degree of judgment. Aristotle uses the example of a carpenter and a mathematician. A carpenter studies the right angle toward the end of perfecting his craft of producing quality furniture; a mathematician investigates the right angle for the sake of comprehending a mathematical truth.1 So, should you be a carpenter or a mathematician? In an ideal world, pleasure is a strong indicator while the root cause is a differing mix of circumstances, habits, and dispositions.2 There are certain circumstances, habits, dispositions, and rituals that together form a certain software folk. By this I mean the subtle and overt swirl of habits, rituals, dispositions, and aesthetics that comprise software engineering culture and lore.

I’d argue that simply opening up a code editor, firing up various tools, writing out code, and developing certain rhythms around this are all things that required more friction than is now present. None of this is new, the tools of a kind of work have always been essential. Running an insitution through emails on a laptop is qualitatively different than reading and sending letters. Sure, offices, desks, and pens may leave a degree of resemblance; yet the experience is quite different even if the work is largely the same. In other words, work is more dynamic than the responsibilities and output; the medium of that work is also impactful on quality according to one’s preferred folk. AI, arguably, is changing the folk. It is not that the same folk experience typing prompts into LLMs as it is to write code out, even when we compare the two without consideration of the absorption of responsibilities. Not seeing the blob of complementary colors in a code editor using a custom theme as frequently removes a habit, embeddedness in a tool, an aesthetic encounter.

Another underappreciated dimension of software folk is the interest that comes in reviewing someone else’s code and seeing how their approach and progress compares with yours. With the introduction of AI, there is blurriness as to whether your peer truly progressed or retrieved an answer from their own initiative, autocomplete, or prompting—and how whether the prompt took much skill. In turn, the feedback loop of your mentorship and support atrophies. Similarly, AI absorbs the experience of whiteboarding and rubber ducking where you can enjoy meaningful contribution toward someone else’s good.

I suppose this blurriness applies to the individual as well. There is blurriness as to whether you are progressing. Was it your skill, the autocomplete, or the LLM that produced the output? If it was a mix, how would you measure that? The lack of benchmarks and feedback loops is genuinely disorienting—so disorienting that I challenge if “judgement” is even discernable at some point. What impact does this uncertainty have?

I don’t have a magic solution, but I do know a sense of progression in life is essential to living well. Of course, it is not a categorically new phenomenon. For example, you would not know whether your peer got something off Stack Overflow instead of working through it the hard way. Yet, somehow this was existentially manageable. There is a line in the sand with these kinds of things where the blurriness overcomes the clarity and judgment really cannot be made. There is a point where the fog has fully crept in and the vista is no longer in sight.

These ideas can be mapped out more precisely and more broadly. I merely aim to introduce this mode of thought to the reader to continue the discourse. Judgment may still remain, but it is absorbing more than time. It is absorbing hurdles/challenges/friction, and it is absorbing a certain folk. Moreover, the lack of feedback may obscure “judgment” enough to make it practically disappear.

To conclude, I’ll at least throw out some starts to solutions, although they will need to be watered.

If friction produces happiness, then friction may need to be sought for its own sake. Its presence can no longer be assumed. This may look like turning off autocomplete complete for certain period and writing out the code manually. Or, you could develop the habit of not tab completing after you make a quick glance. Similar habits can be reviewed for Claude Code et al usage. The point is to intentionally write out code even when you don’t have to. There used to be no choice, now there is, and the solution is a habit not a tool.

Another idea is for developers to make explicit their path to a functional and legible slice of code. They could comment if the used autocomplete in an inline comment, a commit message, a pull request description, etc. Or, maybe a LLM chat history can have a git-like workflow that gets checked in.

Still brainstorming, I’ve even thought about introducing a new software engineer language that is a layer on top of a LLM chat, for it would add friction and developer-specific lore. Perhaps I’m not wildly off given I recently saw a famous developer writing new posts about code Japanese grammar. (I can’t knock this—I’ve worked my through Latin grammar and Familia Romana this past year. Harry Potter in Spanish and Latin is on my list.)

However, lack of friction alone is not the biggest problem. The biggest threat is the existential one. Namely, the difficulty with AI-driven engineering lacking feedback loops to measure your performance vs. that of the agent. This may require placing overarching, human-generated benchmarks for successful AI-driven engineering into the developer experience. This one deserves the most follow-up.

Whatever the solutions may be they flow from addressing the problem with precision. Perhaps one friction we can introduce is to take more time to reflect on these subjects than write shallow “judgment” posts ad nauseum.