A University Can Enroll You. It Cannot Make You a Student.

What is yours to do? Epictetus begins the Enchiridion with the distinction that underlies nearly all of Stoic practice: “Some things are up to us, and others are not.” Up to us are our judgments, choices, and actions; not up to us are the choices and actions of other people.

For an instructor, that matters more than most of the current debate about AI and cheating admits.

It is mine to teach well. It is mine to design serious assignments, establish clear standards, demand evidence, give useful feedback, assess honestly, and protect the integrity of the credential. It is mine to create a classroom in which learning is visible, rewarded, and difficult to fake cheaply.

What is not mine is another adult’s willingness to learn.

A university can admit someone, register them, collect tuition, assign them a student ID, place them in a classroom, and, if they satisfy its requirements, eventually award them a diploma. None of those things can make that person intellectually curious, disciplined, honest, or genuinely invested in becoming more capable.

Enrollment is an administrative status.

Being a student is a choice.

That distinction is easy to lose because modern education often behaves as though learning can be compelled if we design enough controls around the learner. Lock the browser. Proctor the exam. Ban the tool. Detect the plagiarism. Monitor the screen. Restrict the environment. Close every possible escape route, and perhaps eventually the student will have no option left except to learn.

I do not believe that. I won’t teach that way.

I can require work. I can require evidence. I can refuse to certify competence that has not been demonstrated. But I cannot reach inside another adult mind and manufacture the desire to become educated. If someone is absolutely determined to avoid learning, they will spend astonishing amounts of effort finding a way around it. AI did not create that person. It merely gave them another tool.

If you teach and you think your job is to close escape routes, ask yourself, “Are you an educator or a prison guard? Are you standing in front of students or inmates?”

This is not an argument for abandoning standards. Quite the opposite. Academic standards matter precisely because a credential should mean something. If I certify that a student understands programming, mathematics, history, accounting, or anything else, I should have credible evidence that they actually do.

But protecting the standard and forcing someone to value the standard are two different jobs.

The first belongs to the instructor.

The second never did.

That is where I think much of the panic over AI in education begins from the wrong premise. We are asking how to force students not to use a tool to avoid learning, when the more fundamental question is why we continue designing education around the assumption that an unwilling person can be compelled into genuine intellectual engagement.

A university can enroll you. It cannot make you a student.

AI Did Not Create the Cheater

AI did not create the student who wants the credential without the education. That so-called student has always existed. Before ChatGPT, they copied homework, bought papers, used answer sites, borrowed code, memorized just enough to pass an exam, or found someone else to do the work. AI did not invent the desire to avoid learning; it simply made avoidance faster, cheaper, and harder to detect.

That distinction is significant because much of the current response to AI treats the technology as though it created the underlying problem. Ban AI. Detect AI. Require disclosure. Lock down the environment. Build better traps. But if the objective is to prevent every determined student from finding a shortcut, we have chosen a contest we cannot win. There has never been an educational system capable of forcing an unwilling person to learn, and generative AI did not suddenly make that possible.

What AI exposed is a weakness that was already there: we rely too heavily on the finished product as evidence of learning. A correct program, polished essay, strong analysis, or solved problem once suggested that the student probably possessed much of the capability required to produce it. AI has weakened that signal dramatically. The answer is not to pretend we can restore the old world by prohibiting the tool. The answer is to change what counts as evidence.

That is the premise behind the AI-Integrated Classroom. I require AI use and then demand evidence around the result: development, verification, explanation, reflection, and, when necessary, direct demonstration. The question is not, “Did AI participate?” Of course it did. The question is, “What does the student actually understand?”

Use AI. Now prove you understand the work.

That preserves the standard without pretending I can manufacture motivation. If a student is determined to fake the process, generate the reflection, fabricate the development history, and evade every opportunity to learn, they will succeed… for a while. But at that point, the problem is no longer that AI allowed them to cheat. The problem is that they have chosen appearance over competence.

Academic integrity still matters because credentials must mean something. My responsibility is to demand credible evidence before I certify understanding. But academic integrity can protect the credential; it cannot manufacture a student.

And that brings us to the more important question: what actually separates the person who uses AI to become more capable from the person who uses it to avoid becoming capable at all?

Student Is a Mindset, Not an Enrollment Status

This is the distinction that is most significant to me: a true student is not defined by enrollment. A student is defined by intent. The true student wants to become more capable than they were before they entered the room. They may struggle, fail, misunderstand, fall behind, or need help, but they are engaged in the process of becoming educated. That is fundamentally different from someone whose primary objective is to acquire the credential while minimizing the learning required to obtain it.

Stoicism has a useful concept for this: prohairesis, the faculty of choice. Epictetus places enormous importance on the part of us that chooses how we respond, what we value, and what kind of person we are trying to become. Education ultimately reaches that boundary. I can expose you to knowledge, challenge your assumptions, require difficult work, and provide every reasonable form of support. I cannot choose intellectual engagement for you. At some point, the decision to become more capable belongs to the learner.

AI makes that choice stark because the same tool can serve completely opposite purposes. One student can use AI to avoid thinking: generate the answer, polish it, submit it, and move on. Another can use the same system to ask better questions, explore alternatives, challenge assumptions, expose weaknesses, verify claims, and push beyond what they could have accomplished alone. One uses AI to escape the intellectual work. The other uses it to intensify the intellectual work.

The difference is not the machine. The difference is Intellectual Agency: Use AI aggressively, but do not surrender understanding, judgment, verification, or final responsibility. A genuine student can delegate enormous amounts of work to AI without delegating the intellectual ownership of that work. They still need to understand what came back, judge whether it is appropriate, verify what matters, and take responsibility for the result. The student who does that may rely heavily on AI and still learn more than someone who refuses AI entirely. The student who does none of it may produce beautiful work and learn almost nothing.

I reject the simplistic divide between “students who use AI” and “students who do their own work.” That distinction is naive and obsolete. The meaningful divide is between people who use AI to become more capable and people who use AI to avoid becoming capable. One leaves the interaction stronger. The other leaves it more dependent.

The machine does not decide which one you become.

You do.

Being enrolled makes you a student on paper. Choosing to learn makes you one in reality.

I Can Build the Path. I Cannot Walk It for You.

Stoicism does not ask us to become indifferent. It asks us to be precise about responsibility. Education should do the same. So I ask my students a simple question: Are you responsible for your learning?

I ask that question because, to be clear, I am not responsible for whether you choose to learn.

My responsibility as an instructor is to teach well, inspire, set serious standards, design meaningful work, demand evidence, give honest feedback, and refuse to certify competence that has not been demonstrated. My responsibility is to build an environment where learning is possible, where cheating is a poor substitute for understanding, and where AI is used as leverage rather than as an escape hatch.

What I cannot do is want another adult’s education more than they do.

That choice is theirs.

I will not spend my career pretending that enough surveillance, enough restrictions, enough detection software, or enough rules can manufacture a student out of someone who has decided not to become one. I will protect the standard. I will protect the credential. I will do my part.

Then the learner has to do theirs.

AI has not changed that ancient fact. It has only made it harder to ignore.

The instructor can create the path, provide the tools, and demand evidence.

The student still has to choose to walk it.

Why Are You Competing With the Machine?

John Henry is one of the great American folk legends: the steel-driving man who was so strong and skilled that when a steam-powered drill threatened to replace workers like him, he challenged the machine.

He won.

Then he died.

Whether every detail of the story is true is beside the point. The story survived because the symbolism is relevant. John Henry represented extraordinary human strength, pride, discipline, and craftsmanship. There was nothing weak about him. The tragedy was that he chose to prove his value by competing with the machine on the machine’s terms—at the very task it was designed to dominate.

We keep making the same mistake.

You are probably making that mistake.

You would not try to outrun your car to prove you are good at transportation. You would not refuse a forklift and carry pallets by hand to demonstrate your strength. You most likely do not wash your clothes in a river, wash every dish by hand, cut firewood without a chainsaw, or hunt your dinner with a spear because doing the work manually makes the result somehow more authentic.

We invented machines precisely because machines can perform certain kinds of work faster, longer, at a greater scale, and more consistently than we can.

Yet the moment the machine begins doing intellectual work, many people suddenly rediscover the moral virtue of inefficiency.

“I wrote this without AI.”

“I coded this myself.”

“I don’t use ChatGPT.”

Good for you. So what?

What exactly are you proving?

There are legitimate reasons to work without AI. You may be training a skill, testing yourself, learning fundamentals, enjoying the process, or deliberately practicing without assistance. In those cases, doing the work manually is the point.

I go to the gym to lift heavy things to stay in shape. I practice martial arts to remain capable. I read and study to remain intelligent and educated. I often tell my students, “I’m less interested in the final answer, as I am in the process you used to get there,” precisely because they are students; we are learning and training. No one is saying, “Don’t be strong, don’t be smart, don’t be capable.” Quite the opposite, I am a strong advocate of maintaining all of those things.

But when the objective is simply to produce the strongest result efficiently, when the point is production, refusing useful leverage is not automatically craftsmanship. Sometimes it is just unnecessary labor dressed up as virtue, and oftentimes it's dumb and a waste of time and energy.

We have already accepted this everywhere else. Nobody demands that an accountant stop using spreadsheets to prove they understand arithmetic. Nobody tells an engineer to abandon CAD because drawing by hand requires more skill. Nobody tells a researcher that using a search engine invalidates the research because previous generations had to walk through library stacks.

The machine changes the work. We adapt.

AI is simply the newest machine to cross that line.

And instead of asking how to use it well, too many people are still standing beside the steam drill, hammer in hand, insisting that the important thing is that they drove the spike themselves.

That did not end especially well for John Henry, and it won’t for you either. The technology is new, the message is ancient; adapt or move aside for those who do.

So why are you competing with AI?

“I Didn’t Use AI” Is Not a Medal

I am increasingly irritated by people who announce, proudly, that they did something “without AI,” as though abstaining from a tool automatically makes the work better, more authentic, or more intelligent.

It does not.

Sometimes it means you practiced a skill. Sometimes it means you tested yourself. Sometimes it means you deliberately chose a manual process because the process itself mattered. I do that too.

And sometimes it just means you worked harder than necessary.

Those are not the same thing, and that is what I refuse to do.

If I am writing to improve my writing, I may deliberately work without AI. If I am coding to sharpen a specific skill, I may do the same. If I am testing whether I still understand an algorithm, a language, or a mathematical technique, using the machine would defeat the purpose.

That is training. I spend a great deal of my life training intellectually and physically. But when it’s time to perform and produce, I am not training; I’m working—I am producing, and then I work as efficiently as possible.

If the actual objective is to produce the best analysis, the best software, the best document, the best design, or the best decision I can produce, then deliberately refusing useful leverage is not automatically a virtue.

It may simply be inefficiency, and oftentimes it’s just a waste of time and energy.

No one says, “I drove here without using GPS,” and expects applause. No one proudly announces that they completed a financial model without a spreadsheet or researched a topic without a search engine. We do not assign moral superiority to the carpenter who refuses power tools or the engineer who refuses simulation software.

Yet with AI, people suddenly want credit for doing things the hard way.

Why?

Part of it is understandable. AI is new enough that people still associate manual production with authenticity and machine assistance with cheating. But that distinction is already falling apart. In many forms of knowledge work, the meaningful question is no longer whether AI participated. It is whether the person using it actually understood, evaluated, improved, and ultimately owned the result.

That is a much higher standard than simply saying, “I did it myself.”

In fact, “I did it myself” tells us surprisingly little. You may have done mediocre work yourself. You may have misunderstood the problem yourself. You may have missed obvious alternatives yourself. You may have spent six hours producing something that someone else produced better in one hour by using AI intelligently.

Good for you.

Manual effort does not magically transform weak thinking into strong thinking. The real accomplishment is not proving that you can avoid the machine. The accomplishment is proving that you can use the machine without becoming dependent on it, fooled by it, or intellectually subordinate to it.

That is what deserves respect—and so does the person capable of doing it.

I am not impressed that you refused the tool. I am interested in whether you know how to use it well.

The Problem Is Bad Use, Not Use

The mistake in most arguments about AI is that they focus on whether the tool was used rather than whether it was used competently. We do not normally think this way about technology. We do not ask whether a carpenter used a miter saw; we ask whether they know how to use one without destroying the work or themselves. We do not praise a warehouse worker for refusing a forklift; we expect them to operate it safely and effectively. We do not tell people to stop driving because cars are dangerous; we teach them to drive, license them, establish rules, and hold them responsible for what happens behind the wheel.

AI should be treated the same way. The standard should not be abstinence. The standard should be competence.

That means understanding what the tool can do, where it fails, when its output should be trusted, when it should be challenged, and when it should be ignored completely. It means recognizing that a fluent answer is not necessarily a correct answer, that generated code can be elegant and wrong, that a polished argument can rest on false assumptions, and that a convincing analysis can still be nonsense. Using AI well requires judgment precisely because AI can produce bad work that looks exceptionally good.

AI does not give us permission to become dumb or incompetent simply because the machine can do more of the work. It means we need to be smarter to guide the machine and preserve our Intellectual Agency while also using the machine to produce more than we could alone.

This is why I also reject the opposite extreme. Saying “use AI” does not mean “hand everything to AI and stop thinking.” That is no more intelligent than refusing the tool altogether. If you cannot evaluate the result, verify what matters, recognize failure, or take responsibility for the final product, then AI has not made you more capable. It has made you dependent on a capability you do not possess.

For me, intellectual agency means using AI aggressively, but not surrendering understanding, judgment, verification, or final responsibility. Let the machine draft, calculate, code, search, compare, summarize, critique, and generate alternatives. Make it do every piece of work it can do better or faster. But when the work comes back, I still have to know what I am looking at. I still have to decide whether it is good enough, whether it is correct, whether it belongs in the final product, and whether I am willing to put my name on it.

That is what competence with AI looks like. It is not proving that you can perform every task manually, and it is not blindly accepting whatever the machine produces. It is knowing when to use the machine, how to control it, how to recognize when it is wrong, and how to extract more value from it than someone who merely types a request and accepts the answer.

We already understand this principle everywhere else. Powerful tools increase the importance of skill because they increase both what a competent operator can accomplish and the damage an incompetent operator can cause. A chainsaw in skilled hands is vastly more useful than an axe; in unskilled hands, it is vastly more dangerous. AI is no different except that the material it cuts through is intellectual work.

So stop asking whether someone used AI.

Ask whether they know how to use it.

Stop Competing. Start Driving.

John Henry’s strength was real. His skill was real. His pride in his craft was real. None of that saved him from the mistake at the center of the story: he chose to prove his value by competing with the machine on the machine’s terms. That is precisely what people are doing when they treat “I didn’t use AI” as proof of superiority. They are measuring human worth by refusing leverage and then congratulating themselves for doing manually what the machine can increasingly do better and faster.

I have no interest in winning that contest. I want to remain capable, educated, skilled, and intellectually independent—but when it is time to work, I am going to use the best machine available and use it as aggressively as I can without surrendering control of the result. That is not weakness. That is what humans have always done when technology advances: we stop trying to outperform the machine at the task it was built to dominate and learn to operate the machine instead.

John Henry picked up the hammer. Then he died. I would rather learn to drive the drill.

The dividing line is not AI versus no AI. It is competence versus incompetence—with a much more powerful machine in the middle.

Disclaimer: Yes, this was produced with AI—proudly.

Everything I Told You Before Still Holds

I wrote the first So, You Want to Be a Programmer? in 2020. I wrote Part II in 2024. Both were written before generative AI became what it is now, and both were trying to answer essentially the same question from different directions: what does it actually take to succeed in this profession?

Part I was about what you need inside yourself. Attention to detail. Logical and mathematical thinking. A love of problems, puzzles, and figuring things out. A willingness—preferably an eagerness—to spend the rest of your career learning. And, above all, enough passion for the discipline to keep doing all of that year after year.

None of that changed; those are still the core traits you must possess, maybe even more so.

AI did not make attention to detail less important. It made it easier to generate enormous amounts of code that require more attention to detail.

AI did not make logical thinking less indispensable. It made it easier to produce plausible solutions that have to be examined logically.

AI did not make problem-solving less important. It made implementation cheaper, which pushes more of your value toward understanding the problem in the first place.

And AI certainly did not make lifelong learning less important. If anything, that requirement has become brutal and unforgiving. Programming was already a profession where you could wake up one morning and discover that something you had spent years mastering was suddenly obsolete. Now the tools changing the profession are themselves evolving at extraordinary speed.

The old requirements survived and, in fact, became more significant.

Part II approached the profession from the other side. I tried to disabuse new programmers of the fantasy that professional life consists of sitting alone somewhere, blissfully writing code for eight hours a day. It never did. It never will. Professional software development was already dominated by requirements, meetings, documentation, testing, debugging, research, experimentation, refactoring, integration, redesign, and trying to determine what someone actually meant when they asked you to build something.

Even then, I argued that coding was one of the smallest parts of the job, and that observation aged extremely well.

Then AI arrived and became extraordinarily good at the part everyone outside the profession thought was the job: writing code.

In Part II, I ended by saying that if you survived everything I had described, perhaps you were not really becoming a programmer at all. I crossed out the word and replaced it with software engineer.

At the time, that was partly rhetorical. I underestimated how quickly it would become the entire point. I thought I was being clever. Turns out I was being prophetic.

The qualities required to be a good programmer did not disappear. The profession moved upward around them. Attention to detail became scrutiny. Logical thinking became evaluation. Problem-solving became problem framing. Learning became continuous adaptation. Programming skill became one tool inside a much larger engineering discipline.

Passion still matters, perhaps more than ever, because anyone who thought this was a profession where they could learn a language, acquire a marketable skill, and coast for twenty years has chosen the wrong century.

So if you read Parts I and II and thought, That still sounds like me, good.

Keep going, but understand what happened while you were reading.

The qualities required to be a programmer survived. The job called “programmer” did not survive—at least not in the form we used to recognize.

Coding Was Already the Smallest Part of the Job. Now AI Does Much of It.

In Part II, I argued that coding was already one of the smallest parts of professional software development. A programmer’s day was dominated by requirements, meetings, testing, documentation, debugging, research, integration, refactoring, redesign, and trying to figure out what the business actually wanted. Writing truly new source code was only one component of a much larger engineering process.

That was true before generative AI.

AI did not eliminate that process; it inserted itself into nearly every part of it. Today, AI can analyze requirements, compare architectures, generate prototypes, write code, explain APIs, debug, generate and critique tests, refactor systems, document code, review pull requests, research technologies, identify failure modes, and propose alternative designs.

That is a much bigger change than “AI can code.”

AI is simply how software engineering is done now.

Too many people still treat AI as another item in the programmer’s toolbox: learn Python, learn Git, learn SQL, and now learn ChatGPT. That misses the scale of the change. AI increasingly sits across the toolbox. It participates across the development process, which means “learning AI” cannot mean memorizing a few clever prompts—not if you expect to remain useful and employed.

In Part I, I compared programming to an endless series of story problems. Someone gives you an incomplete, contradictory business problem and expects software to come out the other end. The programmer’s real job was never merely translating that request into source code. It was figuring out what the request actually meant, finding what was missing, imposing structure, resolving contradictions, identifying failure conditions, and turning a messy real-world problem into a coherent computational one.

AI is becoming extraordinarily good at producing the implementation once that problem has been framed properly. That makes the reasoning around the implementation more important, not less. Give AI vague requirements, weak architecture, bad assumptions, or incomplete constraints, and it can produce an impressive amount of polished code implementing the wrong thing at extraordinary speed.

As implementation becomes cheaper, merely producing implementation becomes less valuable. More of the human contribution moves toward deciding what should be built, how it should be structured, what constraints matter, how correctness will be established, and whether the resulting system actually solves the problem.

This is why I increasingly tell students to stop thinking of themselves as coders. That does not mean they should stop learning to code. You cannot evaluate generated software if you cannot read code, understand algorithms, reason about execution, recognize poor structure, or identify bad assumptions. In fact, after a decade or two in which deep computer science foundations became decreasingly necessary to make a living as a “coder,” AI has made those foundations important again.

You still need data structures, algorithms, operating systems, databases, networking, architecture, testing, security, performance, and software design. AI does not make that knowledge obsolete. It makes that knowledge the difference between someone who can intelligently use AI and someone who is merely dependent on it.

AI itself must now become part of that foundation. Compilers, IDEs, version control, search engines, and the Internet all changed how programmers worked. We adapted to every one of them because refusing the better tool eventually became absurd. So it must be with AI.

If your definition of programming is primarily the manual production of source code, you are entering a profession that is rapidly eliminating the value of what you planned to sell.

If you understand programming as the disciplined solution of computational problems, the picture is very different.

AI has not removed the need for the software engineer; it has removed the need for the “coder.” And it has given the software engineer who actually knows what they are doing extraordinary leverage.

The New Requirement: Do Not Surrender Intellectual Control

This brings us to the genuinely new requirement for anyone who wants to be a programmer in the age of AI.

You have to learn how to use a machine that may be better than you at significant parts of your own profession without surrendering intellectual control of the work to it.

That is harder than it sounds, because AI can make you look much more capable than you actually are. A mediocre programmer can now produce impressive code, sophisticated architectures, extensive tests, excellent documentation, and convincing technical explanations. The output may be substantially better than anything that programmer could have produced independently.

That is useful leverage. It is also dangerous camouflage.

The quality of the work no longer tells us how much capability belongs to the human presenting it. You can produce exceptional software with AI while understanding the system deeply, understanding it partially, or barely understanding it at all. From the outside, those three programmers may look remarkably similar—right up until something goes wrong, the requirements change, the architecture has to scale, the generated solution contains a subtle defect, or someone asks a question the AI did not anticipate.

Then the difference becomes obvious.

This is the problem I describe as Intellectual Agency: use AI aggressively, but do not surrender understanding, judgment, verification, or final responsibility. I am not interested in preserving manual labor for its own sake. If AI can write a function faster than you, let it. If it can generate the tests, draft the documentation, inspect a stack trace, compare two architectures, or refactor a module in thirty seconds instead of the three hours it would take you, use the leverage. There is no virtue in wasting human effort on work a machine can perform better.

But there is an enormous difference between delegating the work and delegating ownership of the work.

If AI writes code, you still need to understand what that code does and enough of the underlying theory to engage with it intelligently. If AI proposes an architecture, you still have to judge whether that architecture fits the system, the constraints, the organization, the expected load, and the future direction of the product. If AI tells you something is correct, you still have to verify the parts that matter. And if you merge it, deploy it, recommend it, or ship it, the responsibility is yours.

“AI chose it” is not an engineering justification.

Neither is “the tests passed” if you do not understand what was tested. Neither is “it works,” if you cannot explain why it works, where it might fail, or what assumptions the implementation depends on. AI can generate plausible answers all day. Engineering begins when someone takes responsibility for determining whether those answers deserve to be trusted.

That is why the programmer of the AI age needs more foundational knowledge, not less. Without enough computer science and engineering knowledge to evaluate what AI produces, you cannot reliably distinguish strong work from sophisticated-looking garbage. The more capable AI becomes, the easier it becomes to operate beyond your own depth without realizing you have done so.

That is a terrible place for an engineer to be.

Do not confuse the machine’s competence with your own.

This distinction is going to separate valuable software engineers from increasingly disposable AI middlemen. If your entire contribution is to receive a specification, hand it to AI, accept what comes back, and hand the result to someone else, then ask yourself a brutally simple question: why do we need you?

This is the new professional discipline. The old programmer needed to know how to produce the solution. The AI-era software engineer increasingly needs to know how to direct, interrogate, evaluate, verify, improve, and ultimately own solutions that may have been largely produced by something else.

That requires a strange new kind of confidence and humility at the same time. You must be willing to exploit a tool that can outperform you in specific tasks without becoming intimidated by it, impressed into submission by it, or dependent on it for judgments that properly belong to you. You do not need to beat AI at everything it can do. That would be pointless. You need to remain intellectually capable of controlling what happens when you use it.

Delegate the work. Do not delegate the ownership.

If you can do that, AI is an extraordinary force multiplier. It can make an already capable engineer faster, broader, more productive, and able to attack problems that would once have required far more time or a much larger team.

If you cannot, AI may still make your output look impressive.

For a while.

So, You Still Want To Be A Programmer?

Then understand what you are signing up for.

You still need the old traits: attention to detail, logic, problem-solving ability, curiosity, discipline, and a genuine appetite for lifelong learning.

Now add architecture, systems thinking, verification, judgment, AI fluency, and intellectual agency.

Python is not the career. C++ is not the career. Java is not the career. AI is not the career either. The career is solving computational problems with whatever combination of theory, software, architecture, AI, and engineering judgment gets the right result.

If you want to be valuable, you cannot merely produce code. AI does that.

You have to know what should be built, why it should be built that way, whether what came back is correct, and whether you are willing to own the result.

If that excites you, good.

You might still want to be a software engineer.

Just understand that the job is no longer primarily about programming.

AI is the programmer now. Your job is to become the engineer who knows what the programmer should do.

Sovereign Over What?

Sovereign AI is becoming one of those terms that everyone seems to understand until they are asked to define it.

The concept did not begin as shorthand for “run an LLM on your own server.” Its roots are broader: technological sovereignty, data sovereignty, national infrastructure, jurisdiction, strategic autonomy, and the ability to retain meaningful control over increasingly critical computational systems.

In 2023, Luca Belli described AI sovereignty as a country’s capacity to understand, develop, and mobilize AI while retaining control, agency, and self-determination over those systems. More recent work from Stanford’s Institute for Human-Centered AI extends the concept beyond governments, defining it in terms of a state or enterprise acting deliberately according to its strategic interests across the development, deployment, and governance of AI. Stanford also makes an important qualification: the term remains poorly defined, with interpretations ranging from near-complete technological self-sufficiency to strategic interdependence.

That ambiguity is important because an increasingly common interpretation reduces sovereignty to deployment topology:

On-premises is sovereign. Cloud is not.

That is not a useful engineering definition, nor is it correct.

The European Commission’s Cloud Sovereignty Framework makes the same broader point from another direction. It evaluates strategic control, legal and jurisdictional exposure, data and AI, operations, supply chain, technological autonomy, security, and compliance—not simply where a server is located.

The emerging pattern is clear: sovereignty concerns control and dependency across a system, not merely ownership or location of components.

That distinction is especially significant in AI because the model is only one component. A real AI system may include models, prompts, retrieved data, policies, identity systems, databases, tools, execution environments, logs, orchestration, external APIs, human approvals, hardware, networking, and update mechanisms. Hosting the model yourself tells me something important about one component. It tells me very little about the rest.

A locally hosted model with unrestricted filesystem access, uncontrolled tool execution, poor credential isolation, externally transmitted logs, and no meaningful audit trail is not made sovereign by the location of its weights.

Conversely, an external dependency does not automatically prove the absence of control. The relevant questions are what that dependency is permitted to do, what information it receives, how replaceable it is, what jurisdiction governs it, and what happens when it fails or changes.

This is why I use a deliberately operational definition:

AI sovereignty is the effective ability of a specified owner to define and enforce the conditions under which an AI system uses data, exercises authority, depends on external systems, and continues operating.

Sovereignty engineering is the engineering of the controls required to establish and preserve that condition—not simply deciding where the model lives, where data is transmitted, or where inference occurs.

Each relevant dimension must be explicit. Specified owner matters because sovereignty is meaningless without identifying whose control is at issue. Define and enforce matters because a policy that exists only as a prompt is not a control boundary. Conditions matter because sovereignty is rarely absolute. And continues operating matters because control over a system that disappears when a vendor changes a product, revokes an API, modifies a model, or suffers an outage is limited control.

So the first serious question should not be:

Is the model local?

It should be:

Sovereign over what?

Data? Execution? Infrastructure? Models? Tools? Credentials? Updates? Operational continuity? Jurisdiction? The supply chain?

The answer may be all of them or only some. But until those boundaries are stated, sovereign AI is a label, not an architecture and not a solution.

This is also not a wholly new engineering problem. AI sovereignty inherits decades of arguments about internet sovereignty, cloud sovereignty, data residency, jurisdiction, vendor dependence, and technological autonomy.

What has changed is the object being controlled, not the underlying concern. An AI system does more than store and transmit information. It consumes context, generates probabilistic outputs, retrieves additional information, selects tools, and may be permitted to take actions.

The general engineering principle is old.

The specific contract needs new terms.

A Firewall Is Not an Architecture

The most common mistake in current discussions of sovereign AI is to treat physical or network locality as if it were the entire architecture.

Running a model on-premises may satisfy an important requirement. Air-gapping a system may satisfy a stronger one. Open weights may improve inspectability and reduce dependence on a vendor. Private infrastructure may improve data control.

But none of those properties, by themselves, establishes sovereignty.

A system can be entirely local and still be badly governed. It can expose credentials, write to systems it should only read, accept retrieved content as trusted instructions, execute tools without meaningful authorization, leak sensitive information through logs, or depend on opaque updates and unverified software.

The model may never leave the building while control has already been lost elsewhere in the system.

A firewall answers one question:

What network traffic may cross this boundary?

It does not answer what the model may read, what the application may execute, which tools can be invoked, who authorizes consequential actions, which instructions are trusted, who can update the system, or what dependencies remain outside the organization’s control.

This is not a new security principle. Zero-trust architecture exists precisely because network location is not a sufficient basis for trust. NIST SP 800–207 rejects implicit trust based merely on location or ownership. AI does not invalidate that principle; it makes it more important.

The same distinction applies to open-weight models. They may enable local inference, independent deployment, inspection, modification, and migration away from a vendor. But access to weights does not automatically provide training provenance, software supply-chain integrity, operational security, governance, or control over the surrounding system.

Likewise, private inference does not necessarily mean private operation. A system may run inference locally while transmitting telemetry, logs, embeddings, metadata, diagnostics, or application data elsewhere. The relevant question is not merely where inference occurs, but where information flows and who controls those flows.

This matters even more as AI systems become agentic. A model-driven system may interpret context, choose tools, generate parameters, select actions, and propose multistep behavior dynamically.

That changes the security problem.

The model should not define its own authority, and that has nothing to do with the model’s location; it has to do with engineering in accessing the model—regardless of its location.

A model may recommend opening a file, executing a command, or calling an external service. It should not decide whether those actions are permitted. Those decisions belong to the system surrounding the model.

This distinction between capability and authority is fundamental. A highly capable model may have almost no authority, while a weak model with excessive authority can create a dangerous system. Model capability should therefore never automatically increase execution authority.

The same principle applies to model interchangeability. Different workloads may legitimately use different models, but changing an inference provider should not silently change what data may leave the system, where it may be retained, which tools may be invoked, which actions require approval, or which jurisdictions have been accepted.

The model may change. The authority boundary should not.

Several other terms are also routinely conflated. Provenance identifies where an input, model, configuration, or output came from. Traceability lets us reconstruct the path through which a result was produced. Auditability lets an independent reviewer inspect evidence of that process. Explainability concerns whether behavior can be meaningfully explained, while interpretability concerns whether some internal mechanism or representation can be understood.

These are related capabilities, but they are not synonyms. Owning a model does not automatically make it explainable, logging every inference does not make it interpretable, and complete traceability does not prove that the system was correctly authorized. Operating behind a firewall establishes none of them by itself.

The engineering mistake is to take one useful control and promote it into a complete theory of sovereignty. Local execution, air gaps, open-weight models, and private infrastructure can all be valuable controls, and in some environments they may be essential. But none is sufficient on its own.

A firewall can be part of the architecture.

A firewall is not the architecture.

Sovereignty Is an Engineering Contract

We have seen this pattern before.

Every major expansion of networked computing produces a version of the same fear: once sensitive information leaves a physically controlled environment, control has been lost. We heard it with online banking, electronic medical records, cloud computing, remote administration, SaaS, and large-scale data platforms.

The concern was never irrational. External systems introduce real dependencies, attack surfaces, and legal and operational questions. What changed was not that those risks disappeared, but that we learned to engineer acceptable conditions under which those systems could be used.

Modern organizations routinely transmit financial data, medical information, authentication credentials, intellectual property, and operational data across infrastructure they do not physically own. We do not treat transmission itself as proof that control has been surrendered. We ask who receives the data, how it is protected, what may be retained, who is authorized to act, what jurisdiction applies, what can be audited, and what happens during failure.

That is the engineering contract.

AI does not repeal that contract. It extends it.

The general principle is old; the specific contract needs new terms.

One concerns context. AI systems consume unusually rich and unstructured information: proprietary strategy, customer data, source code, correspondence, retrieved documents, operational state, and combinations of information that may become sensitive only when assembled together. The relevant question is not whether a network connection exists, but what information is permitted to cross it, under what conditions, and for what purpose.

Another concerns authority. AI systems increasingly select tools, generate parameters, choose workflows, retrieve information, and propose or initiate actions dynamically. Capability must not imply permission.

A third concerns trust boundaries. Retrieved documents, external data, tool responses, and model outputs are inputs to the system. None should be able to redefine the policy under which the system operates. An instruction embedded in a document remains data unless a trusted mechanism grants it authority.

A fourth concerns dependency. An external inference provider may be entirely acceptable within a sovereign architecture, but the dependency must be explicit. The organization should know what data is transmitted, what guarantees exist, what happens if terms or behavior change, and what capabilities remain if the provider disappears.

Finally, the contract must survive change. Models are replaced, APIs evolve, providers change defaults, tools are added, and orchestration becomes more capable. A boundary that is correct today can become incorrect after a routine update. Replacing a model must not silently broaden data access, adding a tool must not implicitly grant new authority, and local inference must not fall back invisibly to an external provider.

For a given workload, the engineering contract should therefore define four core boundaries:

Data boundaries specify what information may be used, transmitted, processed, and retained.

Authority boundaries specify what the system may read, write, execute, modify, or delegate, and which actions require approval.

Dependency boundaries specify which external systems are accepted, what guarantees they must satisfy, and what happens when they fail.

Operational boundaries specify who may update, reconfigure, disable, audit, recover, and replace components.

Those boundaries must be enforced outside the model’s discretion.

A prompt telling a model not to reveal confidential information is not equivalent to preventing the transfer. A system instruction telling an agent not to execute dangerous commands is not equivalent to restricting the execution interface. Asking a model to remain within a directory is not equivalent to filesystem containment.

Prompts influence behavior. Controls enforce authority.

A sovereign architecture therefore places policy in mechanisms the model cannot simply reinterpret: identity and access controls, network policy, tool permissions, filesystem restrictions, approval gates, data-routing rules, execution sandboxes, and audit mechanisms appropriate to the system.

This does not mean every workload requires maximum isolation. A public-information summarizer, a hospital decision-support system, an industrial controller, and a defense application should not have identical contracts. Their requirements differ because their data, authority, consequences, dependencies, and threat models differ.

The useful question is not whether a system is “local enough” or “private enough.” It is whether the architecture satisfies its declared contract.

And that contract must be testable.

Sovereignty that exists only in documentation is aspiration. Sovereignty that survives adversarial and failure testing is an engineering property.

Sovereignty is not the absence of dependencies. It is control over which dependencies are accepted, what authority they receive, and what happens when they fail or change.

Let the Requirements Choose the Deployment

Once sovereignty is treated as an engineering contract, the local-versus-cloud argument becomes much simpler.

The deployment should follow from the requirements. It should not define them.

Too many discussions begin with a preferred architecture and work backward: the model must be local, the system must be air-gapped, the organization must own the hardware, or external inference must be prohibited.

Sometimes those conclusions are correct. But they are conclusions, not premises. A better sequence is:

Define the workload. Identify the protected assets. Establish the non-negotiable boundaries. Eliminate architectures that violate them. Compare the remaining options. Verify the result.

If information cannot legally or operationally leave a controlled environment, external processing may be excluded immediately. If operation without outside connectivity is mandatory, local execution may be required. If physical control demands extremely low latency, local inference may again be the correct choice.

Another workload may legitimately use an external provider under explicit technical, contractual, and jurisdictional controls. A third may use a partitioned architecture in which sensitive data and deterministic operations remain local while approved tasks use external inference.

All three can be rational designs.

None is sovereign merely because of its topology.

A deployment model is an output of the sovereignty analysis.

Underlying technology will continue to change. Models will improve. Hardware will change. Local inference will become practical for workloads that currently require external compute. External providers will introduce new controls and deployment options. Dependencies that are unacceptable today may become acceptable, while others may become unacceptable later.

A sovereignty architecture should survive those changes.

If an organization can replace one model with another without changing its data policy, execution authority, approval requirements, logging rules, or accepted dependency boundaries, then the model has been correctly treated as a component of the system rather than the definition of the system.

This also separates locality from independence. A system can run entirely on local hardware while depending on external package repositories, model updates, proprietary drivers, licensing infrastructure, or remote administration. Conversely, a system can use an external inference service while retaining control over most of its data, workflows, tools, policies, and operational decisions.

The question is not whether a dependency exists. It is whether the dependency has been identified, bounded, accepted, and tested.

This is the distinction between optimization and authority.

Optimization chooses the best option within the allowed set. Authority defines the allowed set.

Authority comes first.

Control Is the Point

The argument for sovereign AI becomes weaker when sovereignty is reduced to a deployment slogan.

Local models, private infrastructure, air gaps, open-weight models, and cloud services can all be appropriate under the right conditions. None is sufficient by itself to establish sovereignty.

Sovereignty is far better understood as an engineering property than as a hosting preference. The question is whether the owner can define and enforce the conditions under which the system uses data, exercises authority, accepts dependencies, and continues operating.

Complete technological independence is rarely realistic. Modern systems depend on hardware vendors, operating systems, software libraries, networks, suppliers, standards, and jurisdictions. Sovereignty is therefore not the elimination of every dependency. It is the deliberate management of dependency and authority.

Sovereign AI should not become a rejection of cloud computing, foundation models, or external services. Those are tools. The engineering question is whether they satisfy the contract for the workload.

Sovereign AI is not established by where the model is located or whether the system crosses a network boundary. It is established by sovereignty engineering. It is established by control.

State what you control. State what you depend on. Enforce the boundary. Verify that it holds.

That is soveriegn.

Sovereign AI Is An Engineering Contract was originally published in IQumulus on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Professional Engineering Workflow

This is a workflow for software engineers—not a method for replacing software-engineering knowledge with AI-generated code.

It assumes that the human directing the work can evaluate architecture, understand implementation, assess tests, recognize security boundaries, and decide when a technically plausible improvement is not worth making. The essential requirement is the ability to understand, challenge, verify, and take responsibility for the resulting system.

A small incident during recent development illustrates why that qualification matters.

I was building a command-line file catalog as a pilot for this workflow. Conversational AI helped develop the design, and a repository-aware coding agent implemented it. The application ran. The tests passed. Both AI systems initially accepted a repository interface that required this sequence:

repository = SQLiteCatalogRepository(path)
repository.initialize()
entries = repository.list_entries()

I questioned the contract. Why could construction succeed while leaving the object unprepared for its normal operations? Why did the application layer need to remember a separate initialization step before using the persistence layer?

Explicit resource lifecycles can be appropriate. Here, however, the extra step served no useful application requirement. It introduced an avoidable ordering dependency: callers had to know not only what operation they wanted but also how to prepare the repository before requesting it. For this application, construction should either establish a usable repository or fail clearly.

The tests confirmed that the prescribed sequence worked. They did not establish that it was a good interface.

I identified the design problem, the coding agent implemented the correction, and the conversational AI reviewed the result. Subsequent reviews surfaced other concerns, some worth addressing and others not. I remained responsible for making that distinction.

That is what I mean by intellectual agency. It is not approving generated code because it looks professional or because a second model agrees. It is retaining enough understanding to reject the premise, change the design, or decide that further improvement would cost more than it delivers.

The human must not merely be in the loop. The human must be qualified to both close the loop and challenge the closing of the loop.

A nontechnical product owner may understand the business problem exceptionally well. That expertise is valuable, but it does not automatically qualify someone to accept architectural decisions, security controls, failure behavior, or production readiness. Without qualified technical judgment, a collection of capable AI tools can accelerate the production of software that nobody involved understands well enough to defend.

My objective is therefore not to remove the engineer. It is to increase the engineer’s leverage without surrendering ownership.

As of a few months ago, I was already using multiple forms of AI assistance: conversational AI, repository-aware coding agents, and AI integrated into my IDE. At first, my productivity skyrocketed, as did my code quality. However, as projects grew in scope, I realized I was shotgunning my work with AI. Whichever AI was handy, fastest, and currently context-aware—that's who got the job.

The problem was that these tools overlapped, participated in different proportions, and did not consistently share a reliable account of the project. Architectural conversations accumulated design rationale, code fragments, and assumptions about implementation. Coding agents changed the repository. I made further adjustments directly in the IDE, often with inline AI assistance. Each interaction could be useful while the overall process became less coherent.

One option would be to consolidate the work into a single AI environment. That is a valid configuration, but it does not suit how I work. Over the past year of intensive AI-assisted engineering, I have found that different tools suit different kinds of work. I do not want to lose those strengths; I want to coordinate them more deliberately.

The solution was not simply another agent, fewer agents, or more elaborate prompts. It was a clearer division of responsibility, durable project context, explicit authority, and a shared technical reference point.

The tools contribute different capabilities and different review perspectives. Under my direction, those perspectives become a system of checks and balances. The repository holds the current code and accepted engineering contracts. The human engineer remains responsible for deciding what to build, how to judge it, and when to stop.

Rebuilding the Workflow Around Repository Truth

The change was not to replace my tools. It was to define their responsibilities, where they obtained project knowledge, and how their contributions became accepted engineering work.

An ongoing conversation can preserve valuable context: why a design was chosen, which alternatives were rejected, and what the project should become. But continuity is not an accurate record of implementation. When a discussion depends on what the code actually does, the answer must come from inspecting it — not remembering an earlier version.

The repository became the shared technical reference point for every participant.

The working tree and diffs expose implementation and proposed changes. Git records accepted checkpoints. Tests provide behavioral evidence. Documentation records intent, constraints, and rationale that code alone cannot reliably explain.

I established four documents with distinct responsibilities:

Ordinary build and dependency configuration remains authoritative — in the Python pilot, pyproject.toml. This is not a parallel AI-specific engineering system. It is normal engineering infrastructure made explicit enough for humans and agents to share.

Each document owns a distinct concern and refers to the others rather than duplicating them. Otherwise, the solution to conversational drift merely creates more places for information to become inconsistent.

These are living agent development contracts, not setup artifacts. Implementation may expose a mistaken assumption or inadequate boundary. I decide whether the design changes, and the documentation follows the accepted decision. An agent does not gain architectural authority simply because implementation becomes difficult.

“Source of truth” does not mean “infallible.” Code can be wrong, tests incomplete, and documentation stale. It means disagreements have an inspectable, versioned reference point rather than competing memories scattered across conversations.

Against that foundation, the three AI roles become clear.

Conversational AI is my architecture and high-level engineering partner. I maintain a continuing architectural conversation to explore requirements, challenge assumptions, compare designs, and review completed work. Its accumulated context preserves rationale and continuity, but implementation-specific judgments still require live repository inspection.

The repository coding agent is my implementation engineer. It receives a bounded objective, consults the repository contracts, implements, and tests. I control scope, sequencing, and stopping points; it exercises judgment within those boundaries. I treat its working context as session-oriented. Knowledge needed beyond a session must survive in the repository, not depend on conversational recall.

IDE-integrated AI assists while I work directly in the code. Completions, explanations, local edits, debugging, and test assistance augment my hands-on engineering. I use its immediate coding context without depending on it to retain the broader architectural conversation.

These different context horizons are deliberate. The long-running architectural conversation preserves reasoning, but can also accumulate stale assumptions. A fresh coding session reconstructs the project from repository evidence and may expose discrepancies that conversation has overlooked. Conversely, the architectural partner can identify broader consequences that a task-focused implementation session misses. IDE assistance contributes another, more localized view, but does not generally have broader architectural knowlege.

Together with my judgment, that gives me four perspectives — not four independent guarantees of correctness. The checks and balances come from comparing those perspectives and resolving disagreements, not merely collecting more opinions.

In my engineering the roles are filled by ChatGPT, Codex, and GitHub Copilot inside PyCharm. These products are examples, not requirements. Another engineer may combine roles or use different tools. The guiding principle: Each layer must earn its coordination cost.

This is not a hierarchy in which one AI manages another. I interact with each directly. Their common reference is the repository and its governing documents, not a chain of private conversations.

Nor do those documents enforce their own authority. Instructions describe how an agent should behave; permissions and execution controls determine what it can actually do.

The result is a deliberate division of labor, not gratuitous agent usage. Each AI serves a purpose and a scope. The repository makes their work coherent; the human engineer makes the decisions.

Testing the Workflow: What Failed, What Worked

I tested the workflow in two settings. First, I started fcat, a small file-catalog CLI involving filesystem access, SQLite persistence, reconciliation, error handling, and tests. It was substantial enough to require real engineering decisions but small enough to inspect completely. Completing every planned feature was not the objective; establishing a usable development process was.

Next I applied the process to local-agent, an existing application which is substantial and intended to be released publically. I preserved its current state, added agent instructions and coding standards, and asked a fresh coding-agent session to explain the architecture from repository evidence. That inspection exposed stale documentation and a practical defect: even the help command could fail if configuration or logging was broken. After reviewing the findings and documenting the architecture, I directed the coding agent to fix that specific problem. This tested both parts of adopting the workflow: understanding an existing project and continuing its development under human control.

The entry paths differed: a new project begins with a design; an existing project begins by recovering what exists before deciding what to preserve or change. Both converged on the same operating process.

Getting there exposed four important process failures which required correction before this process could be validated as accurate, efficient, and productive.

1. Capability was mistaken for authorization.

When I asked the conversational AI to define a task, help me configure Codex, and then let me begin development, it performed the entire sequence itself. It configured and launched Codex, supplied the task, and monitored implementation. From my perspective, the architectural partner had simply become the implementation agent. I lost the direct interaction and controlled progression I intended to test. The correction was explicit: discussing a task does not authorize its execution, and access to another agent does not authorize operating it on my behalf.

2. Delegation needed the right granularity.

A broad instruction to implement a feature allowed too many decisions to arrive at once. At the other extreme, exhaustive prompts reduced Codex to executing another AI’s implementation recipe. Neither arrangement served my purpose. I needed to choose the engineering checkpoints while leaving the implementation agent room to solve the problem within each one. Sometimes that meant a complete component. Sometimes it meant only an executable skeleton, with behavior deliberately left unimplemented.

3. Review needed a stopping condition.

The repository-lifecycle example already described showed why passing tests did not settle design quality. But I also deliberately explored the opposite failure: repeatedly asking agents to find architectural weaknesses. Each review produced plausible concerns. Fixes introduced more structure, which created more opportunities for criticism. We could have continued indefinitely while accomplishing little. My responsibility was not to route every finding into another task. It was to decide which problems warranted correction, which could wait, and which proposed improvements would cost more than they delivered.

4. Documentation required deliberate maintenance.

Working implementation did not automatically produce an accurate project description. Commands appeared while documentation still called them future work; descriptions remained tied to earlier development stages. The answer was a bounded consistency audit: inspect and report, let me evaluate the findings, authorize the relevant corrections, and verify the result. Documentation changed with accepted behavior, without giving the agent permission to rewrite the project’s goals whenever it found a discrepancy.

The solution to all four failures was the careful and deliberate construction of the agent contract files described above detailing deliberate boundaries and roles, coupled with expertly designed prompts from an experienced engineer.

The positive development cycle emerged when I built fcat’s scan feature incrementally with properly constructed agent contract files. I first requested the command skeleton and inspected its dispatch structure. Next came the file scanner and isolated tests. I added temporary output to inspect the results, connected the service, and only then introduced persistence and reconciliation. The completed feature received architectural review, documentation updates, verification, and a stable commit.

Throughout, I worked directly with the coding agent and used AI assistance in the IDE. The architectural conversation returned at meaningful review boundaries, not after every edit. The point was not that every feature must begin with stubs. It was that I controlled which engineering question we answered next and when we had answered it sufficiently.

What emerged was neither autonomous development nor supervision of every generated line. It was bounded delegation, deliberate checkpoints, and acceptance by an engineer who understood the system.

The Modern AI Coding Workflow

After project setup or architecture recovery, both paths converge on the same coding loop:

Prompt → Inspect → Decide → Implement → Verify → Accept → Update the Contract → Commit.

These are engineering checkpoints, not separate conversations or paperwork required for every edit. The purpose is to make progress reviewable without turning development into continuous coordination.

Establish the task. Begin from the current repository, not an agent’s recollection of it. Confirm the working state, relevant contracts, and any pre-existing changes. Refresh that context at meaningful boundaries: a new task, a changed branch, an external edit, or a revised architectural decision — not ceremonially before every modification.

Then define the objective, scope, acceptance criteria, and executor. Durable decisions belong in the repository. The task prompt supplies what is specific to the current work rather than repeating the operating instructions already documented there.

Delegate within those boundaries. The coding agent determines implementation details within the authorized scope. I choose the sequence: a skeleton, an isolated component, an integration step, or a complete feature. The increment should be large enough to accomplish something useful and small enough that I can understand and evaluate its consequences.

Only one participant actively edits a working tree at a time. When I take over in the IDE, the implementation agent stops writing. Planning is not execution permission, and discovering additional work does not authorize undertaking it.

Verify against the objective. Review the actual changes, run the relevant tests, and examine failure behavior and authority boundaries in proportion to the risk. The question is not, “Can another reviewer find an imperfection?” It is, “Does this change satisfy the task, preserve the agreed constraints, and leave any material problem that prevents acceptance?”

The agent’s report is evidence, not the acceptance decision. Another AI perspective can help, but I must still understand the result and adjudicate disagreements. A finding may justify a correction, deliberate deferral, or rejection as unnecessary complexity. Another review cycle should answer a specific unresolved concern — not merely search for more work.

Close the increment. Once the work is accepted, synchronize any affected documentation and commit the stable state. The repository must be sufficient for the next participant to understand the implementation and its accepted constraints without reconstructing my conversations.

Routine coding can then continue between me, the implementation agent, and the IDE. I return to the architectural conversation for consequential design questions and meaningful review boundaries, not to relay every small exchange. Otherwise, coordination becomes the work instead of supporting it. What’s important to realize, with proper process, the repository and commit messages, along with the agent contract documents create a universal knowlege base. In this fashion, when I return to the architectural conversation the agent does not have to “catch up,” the converstational agent has a global view at all times.

The resulting principle is:

Trust capability. Constrain authority. Verify outcomes. Control scope. Know when to stop.

This is a tested approach to my own engineering practice, not a universal tool prescription or a claim of validation across large teams and production environments. Its value depends on whether the responsibilities remain clear, the repository remains trustworthy, and the human can still explain and defend the system. Tools and their capabilities will change; their usefulness must continue to justify their place.

What I can assert is from three decades of experience, with this development model, I can accomplish the same output of a 3–5 person team and at higher quality. Further, as AI capability increases, I expect this output pace to accelerate.

That said, the goal is not to maximize agent activity or minimize human involvement. It is to accelerate implementation work and quality while preserving the judgment that makes the work coherent.

I remain the engineer — not a messenger between systems that are making decisions I no longer understand.

AI increases engineering leverage. It does not transfer engineering ownership.

[ When the local-agent project is launched publically, it will contain working example of the agent contract and the commit history. The link to the repository will be made available here. ]

The Wrong Optimization

There is a recurring argument in enterprise AI right now: most business and government workloads do not require enormous foundation models. They require smaller, cheaper, more efficient domain-specific models, ideally running privately on infrastructure the organization controls.

There is some truth in that argument, especially around the private infrastructure.

Private and sovereign deployment is a legitimate need—and in some environments, essential. For governments, regulated industries, defense, finance, healthcare, and organizations handling proprietary data, control over infrastructure, data, and inference can be strategically important. And for a narrowly bounded task, a small specialized model may indeed be cheaper and faster than a much larger general-purpose model.

But this leads to the wrong long-term conclusion.

The problem is not the engineering logic. The problem is the time horizon: it optimizes around a resource constraint that is disappearing extraordinarily quickly.

In computing, what counts as “too large,” “too slow,” or “too expensive” is rarely fixed. It is a temporary relationship between an application and the hardware available to execute it. We have watched that relationship collapse repeatedly with memory, storage, CPU cycles, network bandwidth, and cloud compute. Entire generations of engineering practice were built around conserving resources that later became cheap enough to treat almost casually.

AI inference appears to be following the same trajectory.

A recent analysis from Epoch AI estimates that since 2023, the cost of achieving a fixed level of AI performance across several mathematics, science, and reasoning benchmarks has fallen by roughly 47 percent per quarter—about thirteenfold per year on average. The authors appropriately caution against extrapolating that rate indefinitely, but the magnitude of the trend is difficult to ignore. (Epoch AI)

Hardware is moving in the same direction. NVIDIA reports substantial reductions in inference cost across successive GPU generations, with improvements coming from both hardware and the surrounding inference software stack. (NVIDIA)

And increasingly, big does not even mean computationally big. Pruning, quantization, sparsity, and sparse-activation architectures are separating nominal model size from the resources required to run it. SparseGPT, for example, showed that very large language models can tolerate substantial weight pruning with surprisingly little degradation on evaluated tasks, while mixture-of-experts architectures activate only a fraction of total model capacity for a given token. (SparseGPT)

What counts as an “unacceptably large model” is therefore moving from both directions: hardware is getting better while models themselves are getting cheaper to execute.

The architectural implication is clear. If a large general-purpose model costs twenty times as much as a specialized model, efficiency may dominate the decision. If that ratio falls to two times, the calculation changes. If it approaches parity, the question changes completely.

The comparison is no longer merely cheap versus expensive. It becomes cheap, narrow capability versus slightly more expensive general capability with far greater flexibility, reuse, and optionality.

And the latter may be economically superior even when it remains computationally less efficient.

Computational efficiency and economic efficiency are not the same thing.

A specialized model has costs beyond inference: training data, development, evaluation, deployment, retraining, monitoring, governance, integration, and maintenance. A foundation model already deployed within a common architecture may use more compute for a particular task while still producing a lower total cost of ownership.

We have seen this pattern before—over and over.

Before the smartphone, we built specialized devices for specialized functions: calculators, GPS receivers, MP3 players, digital cameras, PDAs, handheld organizers, and mobile telephones. The smartphone did not replace them because it was the theoretically optimal implementation of every function. It replaced them because the marginal cost of carrying excess general-purpose capability became negligible.

A smartphone is absurdly overpowered if all you want to do is calculate a tip. Yet almost no one argues that we should carry a dedicated calculator because it is computationally more efficient.

The excess capability became economically irrelevant.

That is the lesson here. The argument is not that a massive foundation model is necessary for every bounded task. It is that as the marginal cost of excess general-purpose capability approaches insignificance, there is progressively less reason to remove that capability in the first place.

What looks wasteful when compute is scarce becomes valuable optionality when compute is abundant.

The historical pattern is remarkably consistent: general-purpose capability begins scarce and expensive, specialization emerges to work around that scarcity, the general platform becomes cheap and abundant, and specialization moves upward into software and applications.

We are watching that happen again with machine intelligence.

This does not mean model efficiency becomes irrelevant. Some workloads will always demand extreme efficiency because of latency, power, throughput, hardware constraints, or transaction volume. But that is different from saying the future belongs to increasingly specialized domain models.

The strategic question is whether model efficiency will remain important enough to justify putting the specialization—and therefore much of the intellectual property—inside the model itself.

I would strongly bet against it.

Specialization is moving somewhere else.

Foundation Models Were Always Supposed to Be Just That— Foundations

The term foundation model is often used casually (and incorrectly) as a synonym for “very large model,” especially in popular discussion of LLMs.

That misses the point.

When Stanford researchers introduced the term in 2021, they described models trained broadly, generally at scale, that could be adapted to many downstream tasks. The important word was foundation: the model was not the finished product. It was the common base upon which other systems would be built.

Traditional machine learning encouraged us to think in terms of task-specific models. A financial problem suggested a financial model. A legal problem suggested a legal model. A medical problem suggested a medical model.

In that architecture, specialization lived primarily inside the model.

Foundation models change where specialization can live.

The emerging architecture is closer to: Foundation model + domain context + tools + policy + orchestration = specialized system

The specialization no longer has to be encoded entirely in model weights. It can be introduced at runtime through the information, tools, constraints, and environment supplied to a broadly capable model.

Fine-tuning remains one way to specialize a foundation model, but it is no longer synonymous with specialization. Retrieval, structured context, tool access, domain ontologies, memory, system instructions, workflow rules, and validation layers can all specialize behavior while leaving the underlying model untouched.

Instead of building a dedicated financial model—or fine-tuning a foundation model to behave like one—we can increasingly place a general model inside a specialized financial system.

A recent paper, Context Is King: How In-Context Specification Shapes the Geometry of Concepts, provides an intriguing piece of evidence for this direction. David and Fomin showed that capable language models can construct and use conceptual structures specified in context even when those structures conflict with strong relationships learned during pretraining. Larger models in the families they studied did this more cleanly than smaller ones.

That does not prove that domain-specific training is unnecessary or that context can replace fine-tuning in every application. But it demonstrates something more fundamental: the behavior and internal representations used by a sufficiently capable model can be substantially determined by its operating context rather than solely by what was fixed into its parameters during training.

That means specialization can increasingly become a runtime property of the system rather than a training-time property of the model.

And runtime specialization is easier to change.

• If regulations change, change the policy layer.
• If financial data changes, change the retrieved context.
• If a different database becomes authoritative, change the tool connection.
• If business rules change, change the orchestration.
• If a better foundation model becomes available, you can often replace the model without rebuilding the entire system above it.

Compare that with specialization embedded deeply in model weights, where change may require new training data, retraining, reevaluation, redeployment, version management, and another governance cycle.

Fine-tuning will not disappear. There will remain workloads where adjusting model weights is useful or necessary. But it is becoming one specialization mechanism among many rather than the defining one.

What has changed most rapidly is the sophistication of the layers above the model. Retrieval has improved. Tool use has improved. Context windows have expanded. Agentic orchestration has become practical. Structured outputs, policy enforcement, memory, verification, and routing are becoming ordinary architectural components.

More and more of what makes an AI system specialized now exists outside the model. This is why foundation model should be taken literally. A foundation is not the building. It is the part you build everything else on.

The model provides capability. The system provides specialization.

The Model Is Becoming Infrastructure

If specialization increasingly lives in the system, then the strategic value of the model itself changes.

The model still matters technically. A weak model constrains the system around it, and models differ materially in reasoning, latency, context handling, tool use, modality support, reliability, and cost.

But technical importance is not the same thing as durable differentiation. Databases, CPUs, cloud platforms, and operating systems are sophisticated and indispensable. Yet most application companies do not create strategic advantage by building their own database engine, processor, or operating system.

They build on top of them.

Foundation models are moving in the same direction.

As capable models become cheaper, easier to deploy, more interchangeable, and increasingly abstracted behind common interfaces, the competitive question shifts from “Which model do we own?” to “What have we built around it?”

That suggests a simple design principle:

Build your moat in the layers that survive when you replace the model.

That is where proprietary value increasingly lives: data, retrieval, tools, permissions, workflows, policy, verification, evaluation, orchestration, human escalation, and the accumulated knowledge of how an organization actually operates.

The underlying model may change.

The system should survive.

Model-routing architectures already point in this direction. Microsoft Foundry, for example, can abstract model selection into a routing layer, choosing among models based on factors such as capability, latency, and cost rather than embedding a single model permanently into application logic. (Microsoft)

That is more important than simply saying “use the largest model available.” The application talks to an intelligence layer. The intelligence layer determines what should execute the task. A simple extraction may go to a small model. Routine reasoning may go to a mid-sized model. Complex analysis may go to the strongest available foundation model. A tightly bounded workload may still use a specialized model.

The application does not need to care, and that is what commoditization looks like. The underlying technology does not become unimportant.

It becomes infrastructure.

Nor does this mean small or specialized models disappear. There will always be workloads where latency, power, throughput, privacy, hardware constraints, or sheer transaction volume make a narrow model the correct engineering choice. If a five-million-parameter classifier perfectly handles a billion repetitive events per day, replacing it with a massive reasoning model would be wasteful.

The more interesting question is what happens to the middle.

On one side are tiny, highly efficient models solving tightly bounded machine tasks. On the other are increasingly capable foundation models operating inside specialized systems. The category that may become hardest to justify is the expensive, purpose-built domain model whose primary advantage is that it knows one field better than the general model. That advantage becomes less compelling as general models improve, inference costs fall, and domain specialization moves into context, tools, and orchestration.

The market begins to bifurcate:

• bounded machine task → small specialized model
• open-ended cognitive task → general foundation model + specialized system

The middle gets squeezed from both directions, and this is why the larger change is not really about model size.

It is about the level of abstraction at which AI engineering is being done.

Traditional machine learning asked, “What model should we train?” The first generation of foundation-model engineering asked, “Which model should we fine-tune?”

The emerging question is broader: “What combination of models, context, data, tools, policies, verification, workflows, and humans should solve this problem?”

That is a different discipline.

It is less about model engineering and more about intelligence systems engineering because systems must outlive models. Build the system around the assumptions and peculiarities of one model, and the model becomes part of your technical debt. Build specialization above an interchangeable foundation layer, and the system can evolve as the models underneath it improve.

The goal is not merely to use a foundation model.

The goal is to architect the model as a replaceable component.

The best model available today will not be the best one available next year. Model families will change. Architectures will change. Hardware will change. Pricing will change. Some models will disappear entirely. A well-designed AI system should absorb those changes rather than be invalidated by them.

Models will continue to matter. Some will be larger, some smaller, some specialized, and some general. Engineers will continue optimizing all of them.

But increasingly, that is infrastructure work.

The strategic value is moving upward.

The durable question is no longer, “What model should we build?”

It is:

What system can we build when intelligence itself becomes a commodity?

The AI Model Is Not the Product was originally published in IQumulus on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few months ago, I read Matthew Maniaci’s essay, The Biggest, Most Important Reason to Never Use AI. I disagreed with much of it, but I also thought it was unusually thoughtful. Maniaci was not simply repeating the familiar argument that AI is bad because it threatens jobs, creativity, copyright, or the environment. His most interesting argument was personal. He likes doing many of the things AI might automate: writing drafts, editing, analyzing data, working with budgets, learning systems, tailoring emails. He summed it up in one sentence that stayed with me:

“Hell, I just like using my brain.”

That is a fair statement, and one I happen to agree with, but from the opposite view—it is the biggest, most important reason to use AI.

I should also be open about my bias. I am unapologetically pro-AI. I have been working with intelligent systems since the 1990s; my first professional title in 1999 was Intelligent Systems Engineer, my first AI patent dates to the early 2000s, and AI and machine learning eventually became the concentration of my PhD research. I build these systems, study them, teach them, consult in them, and use them extensively. I am not approaching this question as a reluctant convert wondering whether AI might be useful. I have spent most of my professional life assuming that increasingly capable machine intelligence was coming and trying to understand what we should do with it.

But Maniaci’s essay made me think because his objection was not really about capability. He was asking something more personal: if I outsource the little acts of thinking that make up my day, am I outsourcing part of my humanity with them? That question stayed with me. My comment on his essay eventually helped lead to another piece I wrote, I Said I Used AI for Everything. Now I Really Do, but the underlying disagreement kept bothering me because I realized that my answer was almost exactly the reverse of his.

I just like using my brain too.

And that is precisely why I do not want to spend so much of it maintaining calendars, reconciling accounts, processing insurance paperwork, arranging travel, moving information between applications, tracking forms, managing subscriptions, filing taxes, organizing receipts, resetting passwords, coordinating email threads, and performing the thousand other small administrative acts modern life has somehow made every individual responsible for performing.

Maniaci makes many other points about the downsides of AI, and we could honestly debate those, but I am making a much narrower argument here about one specific reason I use AI so aggressively: it gives me back part of the finite intellectual attention that modern life has steadily consumed with administration.

Somewhere during the Information Age, we became extraordinarily capable and extraordinarily burdened at the same time. Technology gave ordinary people powers that once required entire organizations and then quietly transferred much of the clerical work of those organizations onto the individual. We became our own accountants, secretaries, schedulers, travel agents, bookkeepers, researchers, records clerks, benefits administrators, communications departments, and IT support.

I think that period deserves a name: The Administrative Age.

And if we are smart enough about what comes next, AI may be the technology that finally lets us leave it behind.

The Administrative Age

To be clear, administration is not new. Ancient states kept records, collected taxes, counted populations, issued decrees, managed armies, and built bureaucracies. Medieval merchants kept accounts. Governments, churches, militaries, and large households have always required people to organize information and coordinate activity. Nor should we romanticize premodern life. Most people throughout human history spent vastly more of their time than we do performing repetitive physical labor simply to remain alive.

But something different happened in the modern era, and especially during the Computer and Information Age. Administration became democratized. The Information Age did not eliminate clerical work. It distributed it.

The king had clerks. The merchant had bookkeepers. The executive had a secretary. The wealthy traveler had an agent. Large organizations maintained filing departments, accounting departments, travel departments, switchboards, records offices, purchasing departments, and entire layers of employees whose purpose was to make organizational complexity disappear for someone else.

Then technology made ordinary people extraordinarily capable, and much of that work quietly migrated to us.

Today, an ordinary adult is expected to be his own secretary, scheduler, accountant, bookkeeper, travel agent, insurance clerk, tax preparer, researcher, records manager, purchasing department, benefits administrator, communications coordinator, customer-service representative, compliance officer, and IT department. We manage passwords and password managers, two-factor authentication, insurance portals, medical portals, school portals, banking interfaces, tax websites, airline reservations, hotel reservations, subscriptions, renewals, receipts, warranties, calendars, appointment systems, software updates, account settings, permissions, notifications, identity verification, benefit elections, expense reports, payment systems, email threads, cancellations, confirmations, registrations, and the inevitable password reset required to access the password manager containing the password for the portal we needed in the first place.

Health became appointments, authorizations, claims, records, portals, forms, billing systems, and insurance correspondence.

Education became registrations, calendars, learning-management systems, school portals, notifications, forms, logins, submissions, and account management.

Travel became searches, reservations, confirmations, check-ins, apps, passports, visas, insurance, boarding passes, cancellations, loyalty programs, and payment systems.

Money became statements, transfers, budgets, subscriptions, taxes, receipts, alerts, authentication, renewals, and financial dashboards.

Work became email, calendars, project-management systems, reporting, compliance, documentation, authentication, scheduling, forms, and constant coordination between systems that know almost nothing about one another.

Even leisure has become administrative. We create accounts to watch television. We maintain subscriptions to listen to music. We make reservations to eat dinner. We install apps to park a car. We authenticate ourselves to read a newspaper. We manage profiles, memberships, renewals, notifications, preferences, updates, and payment methods merely to participate in activities that are supposed to be the part of life occurring after the administration is finished.

This is the Administrative Age.

And this is where I part company with the idea that performing all of this ourselves is somehow a celebration of the human mind. Yes, it uses your brain. So what?

Filling out a tax form uses your brain. Reconciling accounts uses your brain. Comparing insurance policies uses your brain. Coordinating calendars, processing claims, tracking receipts, managing reservations, resetting passwords, transferring information between incompatible systems, and composing the fifteenth routine email of the day all require cognition.

But using your brain is not the same thing as developing it, enlarging it, or using it on something worthy of it.

A mind can be completely occupied and intellectually underused at the same time. Attention has an opportunity cost. The hour spent processing insurance paperwork was an hour you did not spend learning a language. The evening spent reconciling documents was an evening in which you did not read the book sitting beside you. The time spent coordinating appointments, tracking receipts, managing accounts, and moving information between systems was also time in which you did not develop a skill, pursue a difficult problem, have a long conversation, visit somewhere new, make something, study something, or simply sit quietly enough for an interesting thought to develop.

Administrative work consumes cognition. That does not mean it develops cognition. Even if you want to argue it does, there is the opportunity cost lost to demonstrably more worthwhile pursuits. I cannot accept that filling out a health insurance form or polishing a household budget builds cognition better than reading a difficult book, practicing a new skill, solving a genuinely interesting problem, learning to paint, or just sitting in peace and thinking.

The Information Age gave ordinary people capabilities that previous generations could scarcely have imagined. But it also made each of us the unpaid administrative staff of an increasingly complicated life.

That was an extraordinary bargain when the alternative was not having the capability at all.

I now argue that it does not follow that we should keep paying that administrative price forever.

I’m done paying it.

How the Information Age Created the Trap—and How AI Could Break It

The irony is that the Information Age created much of the administrative burden while simultaneously giving us the tools that made that burden possible. Computers made individuals extraordinarily capable, but they did not remove the need for individuals to operate the machinery. They made the machinery more powerful, more numerous, and more interconnected while leaving the human being responsible for coordinating it all.

For decades, that was simply how computing worked. You wanted something done, so you first had to decide which application to use. Then you had to understand the interface, navigate the menus, find the right file, enter the appropriate information, move data between systems, interpret the output, and remember where everything lived. The computer could perform extraordinary calculations and process enormous amounts of information, but the human remained responsible for translating intention into procedure.

The machine was powerful, but the human was still the integration layer.

That is the trap the Information Age created. It automated individual tasks without automating the coordination between them. Your calendar did not understand your email. Your bank did not understand your tax software. Your insurance portal did not understand your medical records. Your travel app did not understand your work schedule. Your project-management system did not understand the conversation that created the project in the first place. I do not mean you couldn’t connect them or share information between them; I mean they do not understand each other.

Each system became more capable, but the burden of connecting them with understanding remained with you. The human had to understand both what needed to happen and how the machinery had to be operated to make it happen. AI changes that relationship because it can begin one level higher.

Instead of beginning with, “Which program do I need? Where is the information? What sequence of operations will make this work?” we can increasingly begin with the more human question: “What am I trying to accomplish?”

That is a much larger change than simply replacing one app with another. For years, computers have gradually become easier to use because they have required us to know less about how the machinery works. We no longer need to know how information is stored to find it, how a phone network works to call someone, or how a banking system processes transactions to move money. Each step has allowed us to focus less on the mechanism and more on what we are trying to accomplish. AI may be the next step in that progression: instead of telling the computer every step to perform, we increasingly just tell it what we want done—and it just does it.

Imagine the near-term future: no more looking up receipts, finding reports, reading instructions, filling out forms, checking receipt emails. Instead it can just be, “Computer, submit my insurance claim.” Done.

That is why I think AI may matter far more as a coordination technology than as an answer machine. If it can understand the intent, find the relevant information, interact with the appropriate systems, and carry out the mechanical steps between intention and result, then the human no longer has to serve as the connective tissue between every piece of digital machinery.

That is the opportunity.

The Information Age gave us extraordinarily powerful machinery and then made us responsible for operating all of it. The AI era may be the point at which the machinery finally becomes capable of administering itself.

If so, we should let it.

The Escape Is Not Guaranteed

AI could end the Administrative Age, but it could just as easily industrialize it—if we let it. Technology has a habit of filling the capacity it creates. Email made communication easier, so we created vastly more email. Digital forms made paperwork cheaper, so organizations created more forms. AI could make it nearly effortless to generate reports, requests, messages, compliance checks, follow-ups, and administrative demands at an enormous scale.

The opportunity is therefore not simply to automate administration but to eliminate as much unnecessary administration as possible. If AI saves us three hours only so we can fill those hours with thirty more administration obligations, nothing has been won.

AI can give us time and attention back. We have to be smart enough not to immediately give them away again.

What Is a Human Mind For?

Maniaci wrote, “Hell, I just like using my brain.”

So do I.

That is precisely why I do not want to spend so much of it administering the machinery of modern life. I do not want my finite attention consumed by forms, portals, scheduling, reconciliations, passwords, confirmations, routine correspondence, and the endless coordination required merely to keep everything moving. Those things may require cognition, but requiring cognition does not make them worthy of it.

If AI can maintain the calendar, reconcile the accounts, coordinate the systems, move the information, track the obligations, and handle the administrative machinery, good. Let the machine administer the machinery. That is not surrendering agency. It is reclaiming attention from work that never deserved so much of it in the first place.

My vision is not a life in which humans think less. It is a life in which we are finally free to think about better things: difficult problems, ideas, books, languages, art, science, teaching, relationships, places, experiences, and questions that cannot be reduced to another form or workflow. AI should not make us less human. Used well, it can clear away enough administrative noise to give us more room to be human.

But the technology can only return the attention. It cannot tell us what that attention is for. That decision remains ours.

The question is not whether AI can save us time. It can.

The question is whether, once we get that time back, we remember what a human mind is actually for.

The Administrative Age—Could AI Be the Way Out? was originally published in Age of Awareness on Medium, where people are continuing the conversation by highlighting and responding to this story.

About a year ago, I wrote an article called I Use AI for Everything. I Couldn’t Be Happier About It.

At the time, I meant it.

I was using AI to help me code, teach, research, write, consult, plan, think through problems, study philosophy, organize projects, and handle the ordinary friction of daily life. My argument was simple: AI was not replacing me. It was multiplying me.

I really thought I was fully exploiting the technology and operating somewhere near the cutting edge. I have since discovered that I was not even close.

Now, I do not simply use AI for more things. I have started organizing my life with it and around it. AI has moved from tool to infrastructure, from application to operating layer, and increasingly toward something that looks very much like an operating system.

A year ago, AI was something I brought into individual tasks. I had a problem, a question, a project, or a decision, and I used AI as part of the process. Today, AI acts as a coordination layer across those processes. It works across documents, calendars, email, financial information, teaching systems, code, research, and long-running personal projects. I use persistent AI environments with different purposes, rules, and responsibilities. I have built an AI command center to help me decide what deserves my attention and what does not, and I have begun building local AI systems that interact directly with the computer itself.

At this point, using AI simply to answer questions seems like one of the least interesting uses of the technology. Treating a modern AI system as nothing more than a better search engine is a little like using a nuclear reactor to warm up your coffee. It works, but it misses the more important point.

AI is no longer something I merely open, consult, and close. It persists across projects, maintains context, coordinates information, surfaces problems, and increasingly helps manage what happens next. It has become part of the underlying machinery through which I work and organize my life.

That change has forced me to think much more seriously about what this technology becomes when it is deeply integrated—not as a chatbot, not as a product, and not as a collection of clever tools, but as life infrastructure.

That is what this post is about.

From AI Tool to Personal Operating System

The most significant change is that AI no longer waits for me to bring it a neatly packaged problem. I have begun giving it enough persistent context to understand the larger system in which problems exist. Increasingly, I do not stop what I am doing, explain a problem from scratch, and ask for help. I simply work, while AI maintains enough surrounding context to recognize the problem, understand its relationship to everything else in motion, and help resolve it as part of the process.

One example is what I call my Command Center. It is not a glorified to-do list. It is a persistent operating environment for managing projects, deadlines, dependencies, competing priorities, unfinished commitments, and the constant stream of small decisions that consume attention. It already knows what I am working on, what is time-critical, what is strategically important, what is waiting on someone else, what can be deferred, and what probably should not be done at all.

More importantly, I have instructed it not merely to organize whatever I give it, but to challenge me when I am prioritizing badly, creating unnecessary work, responding to false urgency, procrastinating on important work, or allowing vague intentions to masquerade as actual next actions. That changes the relationship entirely. Instead of asking, “What should I do today?” in isolation, or already knowing what I should do and asking, “Help me do this,” I can ask AI to reason about a task in the context of everything else already in motion.

My AI command center works with calendars, email, documents, project files, financial information, and other connected sources. The difference between generic advice and context-aware assistance is enormous. Previously, a request such as “Help me plan my week” was barely meaningful. The AI would first need to know what I was working on, what deadlines I had, what appointments were already scheduled, what I had postponed, what I was waiting on, what constraints existed, and what actually mattered. Otherwise, it could give me generic advice that was technically reasonable and operationally useless.

That time is over. Now each Monday morning I can simply say, “Plan my week,” and the important context is already there. The system already knows the projects in motion, their current status, my calendar, outstanding emails, pending commitments, approaching deadlines, dependencies, unresolved problems, and priorities established over time. It also has context I have deliberately provided about my preferences, personal constraints, recurring obligations, and operating patterns.

I do not need to reconstruct the state of my life every time I ask for help. That is one of the clearest differences between using AI as a tool and using it as infrastructure. I spend less time explaining the world to AI and more time asking it to reason about that world, because increasingly it is already in that world with me.

The shift is from generic knowledge to reasoning over real state, real constraints, and real consequences.

Taken together, these systems change the basic workflow. The old pattern was: I encounter a task → I open an AI tool → I ask a question → I get an answer. The emerging pattern is different: I operate inside an environment where AI already understands the projects, constraints, information, and systems surrounding the task and can help take appropriate actions to keep everything moving.

That is infrastructure.

That is AI as an operating system.

The value is no longer merely better answers. It is lower coordination cost, better continuity, fewer dropped commitments, faster synthesis, better visibility across projects, and less cognitive effort spent simply remembering where everything stands.

I am not automating my life out of existence. On the contrary, I am reducing the amount of human attention wasted on maintaining the machinery of the life itself.

Reclaiming Human Agency

There is an obvious criticism of all this: if AI is involved in so much of my life, am I giving up agency?

No. In fact, the opposite is happening.

For years, people have complained about the administrative burden of modern life. We are all expected to run our lives like small businesses: manage calendars, answer email, track bills, compare insurance, organize travel, maintain budgets, file taxes, coordinate appointments, remember deadlines, plan meals, manage accounts, fill out forms, and keep a dozen unrelated systems synchronized.

Isn’t that what we have been complaining about for decades? Isn’t that what has gotten worse and worse year after year? None of that is really the point of life, is it?

Well, here is a technology that can take much of that back.

I do not want to make a better grocery list. I want to eat well and shop sensibly. I do not want to spend an evening polishing a budget. I want to spend wisely. I do not want to become exceptionally good at maintaining a calendar. I want to keep my commitments and use my time well. I do not want to spend an hour coordinating an email thread. I want the right people to have the right information so that something useful can happen.

Administrative work is not the goal and never has been, but if we are being honest, administration has consumed an extraordinary amount of modern life. Administration is supposed to be the machinery surrounding the goal, not the goal itself. Yet we have gradually become our own executive administrators, spending enormous amounts of time maintaining the systems required to live the rest of our lives while the amount of attention left for the rest of life becomes smaller.

AI changes that equation; at least it has for me.

Drafting routine emails, reconciling information scattered across documents, organizing schedules, maintaining project state, comparing options, preparing grocery lists from nutritional goals, identifying calendar conflicts, summarizing financial activity, and reminding me that something important has been sitting unanswered for a week are all useful tasks, but they are not where I want my energy to go. They are certainly not where I want my best thinking to go.

What I want is the layer above all that noise. I want to decide what matters. I want to think about difficult problems, build things, teach, write, study, spend time with people I care about, make consequential decisions, and occasionally have enough uninterrupted mental space to pursue an idea simply because it is interesting.

That is why I do not see AI as something that reduces my agency. I see it as something that gives agency back to me.

AI frees me to be more human, not less.

I have been exploring this larger question through an idea I call Intellectual Agency: when AI can participate in almost any intellectual activity, the important question is no longer simply whether AI was involved. The better question is, what does the human still own?

For me, the answer is quite a lot, and it is the part that matters most. The machine can perform more of the coordination. It can maintain context. It can organize information, surface alternatives, challenge assumptions, and perform much of the mechanical work that sits between an intention and its execution. But it does not decide what my life is for.

No.

I give AI context.

I do not give it sovereignty.

I am responsible for the decisions, not the AI. I decide which goals matter, which risks are acceptable, which commitments are worth keeping, which conclusions are trustworthy, and when the machine is wrong.

I have given AI extraordinary access to my life. I have not given it authority over my life. That is the boundary. I increasingly think of AI as the operating system rather than the application. It helps coordinate the machinery underneath everything else, but I am still the operator.

AI is not taking my agency by making my decisions for me. It is giving me back agency by taking over work that never deserved my best judgment in the first place. If the result is that I spend less of my life administering the machinery and more of it doing the things that actually require a human being, I do not consider that a loss of agency.

I consider it getting it back.

From Software Tools to Cognitive Infrastructure

The larger change here is not simply that AI is becoming more capable. It is changing the way I interact with computers at a fundamental level. I am a software engineer, computer scientist, data scientist and hold a PhD in computer science. My life has always been intimately associated with computing, so perhaps this transition feels more natural to me than it does to many people.

If all this seems strange, consider the history of personal computing and the abstraction shift that has been happening since computers first became usable by ordinary people.

The burden has traditionally been on the user to understand enough of the machinery to translate an intention into a procedure. If you wanted to accomplish something, you first had to know which application to use, then understand the conventions of that application, then navigate its menus, commands, file structures, and settings well enough to make the machine do what you wanted. Even as software became easier to use, that basic relationship did not change very much. The human still had to convert the goal into the computer’s language.

That traditional model could be expressed simply as human → application → command → result. Early generative AI did not overturn that structure; it mostly added a new kind of application. You opened a chatbot, asked a question, received an answer, and then returned to whatever software environment you were using before. That was useful, but conceptually it remained another tool.

What is emerging now is much more significant: human → AI coordination layer → applications, data, models, agents, and actions. The important shift is that I increasingly do not have to begin by deciding how to perform the task. I can begin by stating what I am trying to accomplish.

That distinction sounds small until you actually begin working this way.

I have taken this further by bringing AI directly into the computer itself. I build my own harnesses around local language models, creating a private agentic computing environment on my laptop. The local system can interact with files, repositories, scripts, applications, and the operating environment while also calling more capable cloud-based systems when appropriate. The result is not simply an AI application running on my computer. Increasingly, AI becomes one of the primary interfaces through which I operate the computer. Increasingly, the AI is the computer.

Instead of asking myself which search tool I should use to locate a document, I can say, “Find the document where I discussed this.” Instead of manually assembling information from several places, I can say, “Tell me what changed.” Instead of thinking first about applications and procedures, I can begin with intent.

The interface is no longer primarily the application; the interface is the intention.

In one sense, this is simply the next step in the history of computing abstraction. Early computers required people to communicate much closer to the language of the machine. Higher-level programming languages moved programmers farther away from hardware. Graphical user interfaces moved ordinary users farther away from command syntax. Search engines allowed people to find information without knowing where it was stored. AI moves the abstraction upward again, allowing us increasingly to express goals rather than procedures.

The applications do not disappear, nor do databases, files, spreadsheets, browsers, operating systems, or programming languages. They move down a layer and become part of the infrastructure beneath an intelligent system capable of reasoning about what I am trying to accomplish.

That matters because many real problems do not belong to any single application. A problem may exist across email, a calendar, a document, an account, a project, and another person waiting for a response. Traditional software divides those things into separate tools because each application owns one part of the problem. AI is uniquely useful precisely because it can work across those boundaries, maintain context, interpret intent, connect information, and coordinate systems that were designed in isolation from one another.

That is the point at which AI begins to look less like a software product and more like cognitive infrastructure.

I still write code, open terminals, use applications, and perform tasks manually when that remains the fastest or most precise way to work. None of those things are disappearing. What is changing is where the interaction begins. I am less frequently forced to begin with the question, “Which program do I need, and what sequence of commands will make it do this?” I can increasingly begin with the more human question: “What am I trying to accomplish?”

That is why describing AI as just another application increasingly misses the point. The deeper transition is not from one piece of software to another but from computers that require humans to express intentions in the computer’s terms toward computers increasingly capable of meeting humans in ours. Once that capability extends across enough applications, enough information, and enough of the operating environment, AI no longer looks like another tool sitting on the desktop.

It begins to look like the layer through which the desktop itself is operated.

What Happens Next

I do not think the next stage of AI will be defined by people opening a chatbot more often. I think the opposite will happen. AI will become less visible as a separate product and more deeply embedded in the systems we already use. It will maintain more context, work across more applications, act with more autonomy, and increasingly operate in the background rather than waiting for a prompt.

I remember when the Internet was something you “got on.” The Internet was a tool you picked up, used, and put down. Now the Internet is simply there—always. We used to live outside the Internet and connect when we needed it. Now we live inside it. We do not ordinarily think about whether we are connected; we simply are.

So too will it be with AI.

What I am building now on my laptop as a hobby and experiment will eventually be integrated directly into operating systems. Computers will ship with AI integrated into them. So will phones. Cars. Televisions. Almost everything with a computational layer will acquire an intelligent layer above it, and many of the applications we consciously open today will recede beneath that layer.

The practical effect will be that the boundary between “using AI” and simply “using a computer” will continue to disappear. Calendars, email, documents, finances, code, research, communication, and operating systems will become increasingly connected through AI systems capable of understanding intent and acting across those boundaries. Local models will matter more as well, particularly where privacy, control, responsiveness, and direct interaction with the machine are important.

Soon, I suspect the interesting question will no longer be how often someone uses AI. It will be how much of the surrounding computational environment has become intelligent enough that the distinction is no longer useful.

What I am doing deliberately today will eventually become ordinary.

The Human Still Owns the Life — Even More So

A year ago, I thought the most significant thing about AI was that it multiplied what I could do. I still think that is true, but I understand the consequence differently now. The real value is not merely that I can produce more, analyze faster, or manage more complexity. It is that I can spend less of my attention maintaining the machinery required to keep everything moving and more of it on the things that actually deserve human attention.

The point of using AI this deeply is not to remove myself from my own life. It is to remove unnecessary friction between intention and action. I do not need to personally perform every administrative step in order for the decision to remain mine, just as delegating work to another human being never meant surrendering ownership of the goal.

AI can organize, summarize, monitor, remind, compare, search, draft, coordinate, and increasingly execute. It can help me see more of the system at once than I could reasonably hold in my head. What it cannot do is determine what any of it is for.

That remains mine.

I decide what matters, what deserves my time, what obligations I accept, which risks are worth taking, what kind of work I want to do, what I want to build, who I want to spend time with, and what kind of life I am trying to construct. AI can help me operate toward those ends, but it does not choose the ends.

I have given AI extraordinary access to my life, but I have not given it authority over my life. The machine can increasingly operate the machinery. I remain responsible for the direction.

If anything, that leaves me with more of the part that was always supposed to be human.

The Objection: AI Will Beat You Anyway

I keep making essentially the same argument about AI: stay ahead of it. Learn more. Go deeper. Become the architect instead of the coder. Strengthen the mathematics, science, engineering, judgment, and higher-order thinking that remain valuable as AI absorbs more routine work.

And eventually someone responds:

But for how long? AI will become better at architecture too. Better at science. Better at reasoning. Eventually it will surpass you anyway.

My answer is simple: so what?

Maybe they are right. In fact, I expect AI to continue moving upward through more of what we currently consider sophisticated human work. I think AGI is coming sooner rather than later, and I consider eventual superintelligence entirely plausible. Perhaps AI eventually surpasses us across nearly every intellectual domain.

But that is a prediction about tomorrow, not a strategy for today.

Suppose someone had told a medieval warrior, “Stop training. Throw away your sword and shield. Better weapons are coming.”

That would not have been foresight. It would have been stupidity.

You use the best tools available now. You develop the strongest capabilities that matter now. You watch the terrain change, prepare for what may come next, and adapt when it arrives.

If AI eventually makes my current expertise obsolete, becoming less capable today would not have saved me.

That is where this stops being merely an argument about AI and becomes an argument about preparation under uncertainty.

The No-Regrets Bet

There is a simple way to think about preparation under uncertainty: choose the course of action that leaves you stronger and more resilient across the greatest number of plausible futures.

Consider a common climate-change argument. Suppose a skeptic were ultimately correct about some major causal claim, but in preparing for the threat, we reduced pollution, improved efficiency, conserved resources, and developed cleaner technologies anyway. What exactly was lost? Even if part of the prediction proved wrong, much of the preparation still left us better off.

AI presents the same choice.

• Suppose AI progress slows considerably. Becoming a better mathematician, scientist, engineer, programmer, strategist, or thinker was obviously worthwhile.
• Suppose AI keeps advancing and pushing the human competence frontier upward. Deeper knowledge, greater adaptability, and stronger judgment help me keep moving with it.
• Suppose AI eventually becomes so capable that my expertise provides no meaningful economic advantage at all. Being less intelligent, less educated, and less capable would not have prevented that outcome.

If AI eventually makes my expertise obsolete, ignorance would not have saved me. Greater knowledge may even expose options I cannot see from where I stand today.

This is fundamentally Stoic. Epictetus begins the Enchiridion by dividing reality into what is within our power and what is not. I do not control how quickly AI improves, what models corporations release, what governments regulate, what industries disappear, or what the labor market looks like ten years from now. Those things are terrain.

What is at least partly mine is how I meet that terrain: what I learn, how well I think, how effectively I use the tools available to me, how resilient I become, and how quickly I adapt.

Stoicism does not promise that preparation guarantees victory. That would confuse action with outcome. It asks us to see reality clearly, train deliberately, act where action is possible, and stop demanding guarantees the universe never offered.

The warrior trains because training improves his position in battle, not because the gods signed a contract promising that he will survive it.

That is the no-regrets bet. Across almost every plausible future short of complete human cognitive obsolescence, being smarter, stronger, more capable, and more adaptable improves my position. And if complete obsolescence arrives anyway, I would rather meet it as the strongest version of myself I managed to build than as someone who surrendered years earlier because defeat was theoretically possible.

The Obstacle Becomes the Way

Marcus Aurelius goes further than telling us merely to endure obstacles. In Meditations 5.20, he writes:

The impediment to action advances action. What stands in the way becomes the way.

That distinction is core to my philosophy of both AI and life.

The Stoic response is not always to work around an obstacle. Sometimes you study the obstacle until you discover that the answer is inside it—that the thing limiting you can be transformed into the means by which you advance.

I learned this long before AI.

I am dyslexic and dysgraphic. Seeing language and sequences out of order was an obstacle until I learned to exploit the same tendency as an ability to examine problems from multiple directions. Where another person naturally follows a line left to right, I am comfortable reversing it, rotating it, and attacking it from another angle. I used that not only to master English but also later to learn Greek, where flexible word order has no effect on me. Word order is always strange to me, so none of it is particularly strange.

The obstacle becomes the way.

I was also too tall and long-limbed to fight the way smaller, faster fighters did. I spent years trying to overcome that and failing until my instructor told me to stop trying to be fast. Become enormous. Become so strong that the other man may hit first, but you hit last—because it ends when you hit back. I went from a gangly 160-pound teenager to a 275-pound man with four black belts.

The obstacle becomes the way.

My thinking is naturally rigid, procedural, and algorithmic. I could have spent my life wishing I were a more instinctive free thinker. Instead, I turned that rigidity into logic, mathematics, programming, and systems analysis.

The obstacle becomes the way.

AI should be approached exactly the same way.

If AI is better than you at routine programming, do not quit programming. Use AI to become capable of designing and building systems you could never have built alone.

If AI writes faster and better than you, do not stop writing. Use that speed and quality to explore more ideas, attack your own arguments harder, revise more aggressively, and spend more of your effort deciding what you actually mean.

If AI can analyze more information than you can hold in your head, do not surrender analysis. Use it to extend the reach of your judgment.

The thing threatening to make the old version of your skill obsolete may be precisely the thing that allows you to build the next version of that skill.

Do not merely endure the obstacle. Recruit it. For me, AI is not just the thing moving the frontier; it is also the weapon I use to move with it.

When the Game Actually Changes

The strongest objection remains: what happens when AI moves upward again?

Today it may replace routine coding. Tomorrow it may outperform humans at architecture, planning, scientific analysis, medicine, validation, and increasingly sophisticated forms of judgment.

Fine. Then the frontier moves again.

If the machine becomes better at coding, move toward architecture. If it becomes better at architecture, move toward problem framing, systems judgment, strategy, or whatever higher-order work remains. If the frontier keeps moving, keep adapting.

The point is not to discover some magical sanctuary of human ability that AI can never touch. I do not know whether such a sanctuary exists. The point is to remain capable, useful, and adaptable for as long as the environment permits it.

There may eventually come a point where the change is no longer incremental. If AGI or ASI reaches a level where human cognitive labor has little or no economic value, then we are no longer discussing programming careers, engineering careers, or whether someone should learn more mathematics.

That is not a career-planning problem.

It is a civilization problem, and no one has a reliable guidebook for that world.

Stoicism is not a prophecy machine. It is a discipline for acting rationally under conditions we do not control. I will not use a hypothetical future paradigm as an excuse to weaken myself in the present one.

If the rules change, I will learn the new rules. If the battlefield changes, I will take to the field as the strongest version of myself I can build. If the entire structure of human work collapses, then we all have a problem larger than professional strategy. I’ll worry about dealing with that if and when it happens—stoically and prepared.

Play the Strongest Hand You Can

I do not know how capable AI will become, how quickly it will get there, or what parts of human work it will eventually absorb.

Neither does anyone else.

I hold a PhD in AI and have worked professionally in and around this field for almost three decades, and I can assure you: nobody knows where this ends. Not the people announcing that AI will take over the world next Tuesday, and certainly not the people declaring that AI has already peaked (hint: it hasn’t). We have opinions, some far better informed than others, but they remain opinions.

Pretending otherwise is prediction masquerading as certainty.

What I do know is that I can affect the condition in which I meet that future. I can learn more, think better, strengthen my judgment, train harder, exploit the tools available to me, and become more adaptable.

That does not guarantee victory.

Stoicism never promised victory.

It asks a different question: What is yours to do now?

Preparation is mine. Training is mine. Judgment is mine. Adaptation is mine. The outcome never was.

Perhaps AI eventually surpasses everything I can do.

Okay.

Being weaker would not have prevented that.

I cannot control the hand the future deals me, but I can make damn sure I am a better player when the cards arrive.

Prepare for the world that is coming. Adapt when it arrives. Above all, never confuse uncertainty about victory with a reason to surrender before the fight begins.

I Was Going to Write a Very Different Post

About a month ago, I was socializing—with humans, something I rarely do and certainly do not do particularly well—when someone said something that pressed several of my buttons at once:

AI has destroyed the value of hard skills. The future is soft skills. We should be teaching networking and relationship building, not math and science.

My immediate reaction: That's perfectly backward.

AI was commoditizing soft skills. It could already write the diplomatic email, fix your tone, prepare the presentation, make you sound thoughtful, and coach you through the conversation. Hell, it’s even becoming our friends, our therapists, and our girlfriends. Hard skills are what remain valuable in the age of AI, not what AI replaces. Math, science, engineering, architecture, deep technical knowledge—those were going to matter more, not less.

And somewhere in my head, the post attacking this person’s idea started writing itself.

That argument came naturally to me because I have built most of my career on hard skills. My networking is mediocre. My relationship-building is worse. I have always preferred being useful to being likable. I wield hard skills like a scythe. They cut through an enormous amount of bullshit with cold efficiency—and I like it.

Years ago, a boss reportedly said about me, “I hate that guy, but I can’t get rid of him. He’s too smart.” When the comment made its way back to me, I wasn’t offended. I was delighted. That was almost exactly where I wanted to be—too smart to care.

You don’t hire me because I smile at the right people, because we went to the same school, or because I pretend to enjoy cigars with the boss. You hire me because I solve problems. I build things that work. I solve problems other people cannot solve, and I get them done on time and under budget.

And from that perspective, AI appeared to prove my case.

AI has made my hard skills enormously more valuable, not less. It lets me move faster as a programmer, scientist, engineer, professor, and consultant. It eliminates trivial cognitive overhead and lets me spend more of my time on architecture, analysis, theory, judgment, and difficult problems.

AI did not replace the things I know.

It multiplied what I can do with them.

AI Was Also Fixing the Things I’m Bad At

Ironically, AI also compensates for many of the things I am bad at. It improves my emails. It softens language I would otherwise make unnecessarily sharp. It helps me prepare for meetings, present ideas more effectively, and navigate interactions I would rather avoid entirely.

My conclusion seemed obvious: AI was commoditizing soft skills. Even I can sound diplomatic now—when I choose to. And that was key: AI put power in my hands that I lacked.

I freely admit that my weakness in networking and organizational politics has cost me. I have watched people with substantially less technical ability pass me professionally as if I were standing still.

A CTO once explained to me why people like me often do not become CTOs: the job is largely political. He did not need to know how to build everything; he needed enough technical judgment to know when someone was bullshitting him.

Okay, fine. I concede that point.

But my point remained: somebody still had to build things.

So my planned argument was going to be simple: forget this sudden obsession with soft skills. AI can help you communicate. AI can help you present yourself. AI can even help barbarians like me appear considerably more civilized than we actually are.

Reality demands something that works, and when that happens, somebody still needs to know the math.

Then I read Rohan Mistry’s AI Didn’t Kill Jobs. It Killed the Idea That Hard Work Matters.

His argument was deliberately brutal: AI has made formerly scarce skills abundant. If everyone can use AI to produce competent-looking work, skill and hard work stop differentiating people the way they once did, and connections, visibility, and access become increasingly decisive. In his formulation, AI did not merely threaten jobs; it made hard skills less valuable and social connections more important.

I thought the post was exaggerated.

I still do.

But it hit much harder than I wanted it to because underneath the exaggeration was a point I had missed.

He had not convinced me that hard skills were dead and networking had won.

He had convinced me that I was thinking about the boundary in the wrong place.

AI Did Not Kill Hard Skills. It Killed Mediocre Hard Skills.

AI did not make hard skills less important. It made mediocre hard skills less valuable.

That changes everything.

Before AI, there was economic value in being merely competent at many technical tasks. You could know enough programming to implement someone else’s design, enough analysis to prepare the report, enough statistics to run the standard model, enough technical knowledge to execute a clearly defined task.

I can’t tell you the number of mediocre programmers I’ve worked with who survived only because mediocre code was still above most people’s ability. I can’t tell you the number of so-called data analysts I’ve known I wouldn’t trust to calculate a tip on a $10 meal. They survived because, the truth is, the average person could not do their work, as mediocre as it was. They lived in a sweet spot, just the other side of the competence boundary, just smart enough to be useful. They didn’t need soft skills; they just needed mediocre hard skills.

Now AI has crossed that boundary with terrifying speed and precision and is rapidly swallowing territory.

AI can lift weak or average technical output far enough that many more people can cross the threshold of apparent competence. Work that once required a reasonably skilled human can increasingly be produced by an average human directing a very capable machine.

That does not eliminate competence. It changes where competence begins. The bar has moved upward — way upward.

And this is where Rohan’s argument becomes uncomfortable. Once a much larger group can produce output that looks good enough, the differentiators inside that group change. Reputation matters. Visibility matters. Relationships matter. Organizational politics matter. Who knows you matters.

Networking did not become more important.

Its reach expanded.

The territory in which social capital can compensate for differences in technical ability became much larger because AI compressed many of those differences.

You could argue expanded reach makes something “more important,” but that’s not the same thing as saying hard skills disappeared. It means something else entirely.

It means mediocre hard skills stopped protecting you.

So if that’s you, mediocre, then yeah, you better get good at socializing really fast. As they say, if you can’t dazzle them with brilliance, baffle them with bullshit.

But the Expert Gets AI Too

There is another side to this equation that gets ignored whenever someone announces that expertise is obsolete, and this is what I think Rohan’s argument missed.

The expert gets AI too. I get AI.

Give an average programmer AI and you may get competent code.

Give an exceptional software architect AI and you get an exceptional architect who can explore more designs, prototype faster, inspect more alternatives, test more aggressively, and operate at a scale that previously required a team.

Give an average analyst AI and you may get a respectable report.

Give an excellent mathematician, scientist, or quantitative researcher AI and you get someone who can interrogate more hypotheses, write more code, explore more models, automate more tedious work, and spend more time on the problems that actually require expertise.

AI is not merely a leveling technology. It doesn’t just democratize.

It is also a multiplier—in the right hands.

That creates a strange polarization: average competence becomes easier to imitate while exceptional competence becomes more powerful to possess.

And this is where the claim that “hard skills don’t matter anymore” completely falls apart.

AI can generate an equation. Someone still has to know whether the equation makes sense.

AI can generate an architecture. Someone still has to recognize that it will collapse under load.

AI can produce an analysis. Someone still has to know whether the assumptions invalidate the result.

AI can produce ten thousand lines of beautiful code that solve the wrong problem.

Eventually reality gets a vote, and like it or not, reality is often governed by people who understand real work, solve real problems, and get things done.

The bridge either stands or it does not. The model predicts or it does not. The system scales or it does not. The experiment survives replication or it does not.

Bullshit may have a larger operating range now. Rohan is right about that.

But it also still has a failure boundary.

Soft Skills Did Not Disappear Either

There was one other mistake in the post I originally intended to write. AI can commoditize a surprising amount of what we call soft skills, but it cannot commoditize all of them. That’s the part I was missing.

AI can write the email. It cannot build ten years of trust.

AI can improve your presentation. It cannot manufacture a reputation.

AI can coach you through a conversation. It cannot make someone choose you because they know how you behave when a project is on fire.

AI can automate soft-skill production. It cannot fully automate social capital.

That is the distinction that hit me like a cartoon anvil when I read Rohan’s post.

The technically brilliant person who can also communicate, lead, earn trust, and build relationships remains more powerful than the technically brilliant person who cannot. I know this firsthand because I have spent much of my career proving the second case.

So no, the lesson is not to abandon soft skills.

But it is certainly not to abandon hard skills either.

The lesson is that the comfortable middle is disappearing.

As with most things in life, the extremes are wrong, and the truth lies somewhere in the middle. Rohan’s post is not correct. The post I was going to write would not have been correct.

Understanding is a three-edged sword: your side, their side, and the truth.

— Kosh, Babylon 5

The position I finally arrived at is this:

AI commoditizes mediocre hard skills, amplifies exceptional hard skills, and expands the territory in between where soft skills and social capital can determine who wins.

So What Should You Learn?

Go deeper.

Do not respond to AI by deciding that mathematics no longer matters because ChatGPT can solve equations. Learn enough mathematics to know when ChatGPT is wrong.

Do not stop learning programming because AI can generate code. Learn enough computer science and software engineering to design systems, recognize bad architecture, understand complexity, and know when generated code should never reach production.

Do not abandon statistics because AI can run the model. Learn enough statistics to know whether the model should have been run in the first place.

And yes, learn to communicate. Build relationships. Become someone people trust. Those things have always mattered, and AI has expanded the territory in which they can affect outcomes.

But do not mistake the expansion of that territory for the death of expertise. AI did not lower the value of knowing things deeply. It raised the threshold for what “deeply” means.

The Price of Admission Went Up

The mistake is thinking that AI killed expertise.

It didn’t.

It killed a great deal of the economic protection that came from being merely competent. That may be uncomfortable, and it should be.

The average technical worker now competes with other average workers who all have access to the same extraordinary machine. Networking, visibility, and social capital can carry people further across that flattened middle than they could before.

But above that middle, the game changes again—dramatically.

Someone eventually has to know. Someone has to recognize the subtle error. Someone has to make the architectural decision. Someone has to understand the mathematics, the physics, the system, the science, or the domain deeply enough to take responsibility when the machine confidently produces something wrong.

AI did not make experts with real hard skills obsolete. Quite the opposite, AI has given true experts armor and weaponry unlike anything we’ve ever had. We aren’t less valuable; we’re more valuable, scarcer, more useful, and more dangerous.

So if AI can already do everything you know how to do, do not conclude that hard skills no longer matter. Draw the more uncomfortable conclusion:

You do not know enough yet.

AI did not kill hard skills.

It raised the price of admission to being an expert.