The Intent Revolution

There's something profoundly stupid about the relationship between humans and computers, and I think we've been living with it for so long that we've stopped questioning it.

We have machines capable of billions of calculations per second. Machines that can simulate entire worlds, generate photorealistic imagery, design aircraft, and model the behavior of biological organisms. We can take a collection of ones and zeroes, push them through some carefully arranged silicon, and somehow end up playing Quake. That's an extraordinary accomplishment, especially when you consider that a considerable portion of humanity still struggles to make a printer work.

And yet, despite all this computational sophistication, we've somehow decided that the human being should be responsible for understanding the machine.

We spend years teaching people how to operate computers. We create certifications, training courses, instructional videos, and entire professions dedicated to explaining why the magical thinking rectangle has decided not to cooperate today. When somebody wants to make a tool that doesn't already exist, we tell them to learn programming, purchase specialized software, or hire someone who understands the obscure incantations necessary to convince a processor to do something useful.

I have a rather different idea.

What if we stopped teaching humans to think like computers and started building computers that could understand how humans think?

Not through another chatbot. Not through increasingly elaborate artificial intelligence systems that generate thousands of lines of code nobody understands. I'm talking about fundamentally changing how we design software, how we interact with machines, and how ordinary people create the tools they need.

I call it Intent-Based Computing, and I think it's a direction the entire technology industry should be pursuing.

Congratulations, Your Accounting Software Has Developed a Problem

I've spent much of my professional life fixing computers, and if there's one thing the experience has taught me, it's that modern software is remarkably good at knowing something has gone wrong and remarkably terrible at explaining what.

Consider QuickBooks Desktop, an accounting application used by businesses that would generally prefer to spend their time running a business rather than investigating the spiritual well-being of their database server.

An employee arrives at work, sits down, opens QuickBooks, and attempts to access the company file. Yesterday, everything worked perfectly. Today, they're greeted by an error message.

H202.

Well, that certainly clears things up.

For the uninitiated, H202 is an error associated with QuickBooks' multi-user connectivity. In practical terms, the software is having trouble communicating with the computer hosting the company's accounting data. Simple enough, until you begin investigating what actually caused it.

Perhaps the QuickBooks Database Server Manager isn't functioning properly. Perhaps the firewall is blocking communication. Perhaps the network descriptor file contains incorrect information, or the server's hostname isn't resolving correctly. Perhaps the network connection itself is unavailable. Maybe somebody changed the hosting configuration. Even after resolving the connection problem, you might encounter separate file permissions, locking, or corruption issues.

Intuit's own troubleshooting instructions involve running multiple utilities, checking network configurations, examining services, and working through several possible causes. They even provide a tool called File Doctor, which is an amusing name for something that's presumably expected to make house calls to your accounting database.

Now, I understand why these problems occur. I've diagnosed enough of them over the years. Networks are complicated, databases are complicated, and Windows occasionally behaves as though someone has insulted its ancestors.

But consider the absurdity from the employee's perspective.

They wanted to open their accounting records.

That's all.

Somewhere beneath that error message is a chain of operations. The software needs to find a server, establish communication, access a file, authenticate appropriately, and interact with a database service. Each step has specific requirements, and many of those requirements can be tested individually.

Instead of providing a meaningful explanation of which dependency failed, the application presents a broad category of failure and leaves the human to investigate.

Imagine a different experience.

You attempt to open your company file, and the computer explains that it cannot complete the request because the database service on the server isn't responding. It shows that the server itself is reachable, the shared folder is accessible, and the necessary permissions are present. It identifies the failed service, explains its purpose, and offers to restart it if you have the appropriate authorization.

If it cannot determine the exact cause, it tells you what it tested, what succeeded, what failed, and what remains unknown.

Suddenly, we're no longer diagnosing an obscure software error. We're repairing a broken relationship between understandable parts of a system.

That's the difference I want to see.

And QuickBooks is hardly the only offender. Consider a printer that Windows insists is offline while it's sitting three feet away, powered on, displaying a perfectly healthy network connection. Maybe the address changed. Maybe the print spooler is stuck. Maybe the port configuration is wrong. Maybe the driver has developed a personal vendetta against the operating system.

You don't know. You're just trying to print a shipping label.

Or perhaps you've encountered the delightful Windows message informing you that a file cannot be modified because another program is using it. Which program? What is it doing? Can it release the file? Does it actually need to be open?

Apparently, that's classified information.

The real issue isn't that computers fail. Anything sufficiently complicated will occasionally fail. The issue is that we've normalized computers communicating failures in terms of their own implementation rather than the intentions of the people using them.

The computer knows something about what went wrong. The human knows what they were trying to accomplish. Why have we designed the interface to communicate neither particularly well?

We've Built the Entire Industry Backward

Think about how other tools work.

A carpenter doesn't need to understand the molecular structure of steel to use a saw. A musician doesn't need to understand semiconductor physics to operate a guitar amplifier. A driver doesn't need to understand fuel injection timing to accelerate onto a highway.

These tools translate human intentions into mechanical or electrical actions. Their controls correspond to concepts the operator understands.

Computers are theoretically the ultimate expression of this idea. A general-purpose machine that can become almost any tool we can imagine should be the most adaptable instrument humanity has ever created.

Instead, we've developed a culture in which people are expected to adapt themselves to the software.

Need to organize customer information? Learn the database application's workflow. Need to automate a repetitive process? Learn a scripting language or purchase an automation platform. Need to build something unusual? Congratulations, you're a software developer now.

We have made remarkable progress in graphical user interfaces, but much of that progress has focused on making existing functionality easier to access. We replaced command lines with buttons, filesystems with folders, and text commands with icons. These were genuinely important advancements, but they did not fundamentally change the relationship.

The machine still dictates what operations are available and how they must be performed.

A graphical interface often makes it easier to do what the software's creator anticipated. The moment you want something different, you encounter the machinery underneath.

And that, I think, is where we've missed an extraordinary opportunity.

The purpose of a computer should not be to provide a collection of predefined applications. Its purpose should be to help a human accomplish something.

The distinction sounds philosophical, but its implications are enormous.

What If You Could Just Build the Tool You Needed?

Let's imagine you're running a small repair shop.

You need a way to track parts. Nothing particularly elaborate. You want to know what you have in stock, what needs ordering, which customer a part belongs to, and whether something has already been installed.

You understand this problem perfectly well because you encounter it every day.

You know that receiving a shipment increases inventory. Installing a part decreases it. Ordering something for a customer creates an expectation that the item will eventually arrive. When stock drops below a certain quantity, somebody should be notified.

You've already worked out the logic.

What you probably haven't done is translate that logic into database schemas, application code, APIs, event handlers, and whatever JavaScript framework the internet has decided to worship this afternoon.

Why should you have to?

Imagine opening a computing environment that offers functional building blocks instead of demanding that you write software.

You start with an Inventory block. It represents a collection of things with quantities, descriptions, and locations. You connect it to an Orders block because receiving an order needs to update inventory. You attach a Customers block so particular items can be associated with particular people. Then you add a Notification block that watches stock levels and alerts you when something needs attention.

Each piece does something recognizable. Each connection represents a relationship you can understand, and the environment explains what information moves between them.

You assemble the system, test it with a few imaginary transactions, and adjust anything that doesn't behave as expected.

Then you use it.

You haven't written a traditional computer program, but you've created software that solves your problem.

The computer handled the machinery. You handled the idea.

This is what I mean by Intent-Based Computing.

It's not about removing technical complexity from existence. It's about placing that complexity where it belongs, inside the components responsible for managing it, and presenting people with the concepts that actually matter to their objectives.

A person who understands inventory should be able to build an inventory tool.

A person who understands music should be able to construct a musical instrument.

A person who understands the rules of a game should be able to assemble a playable game without first mastering graphics programming, memory management, and collision detection.

The technical expertise needed to create those reusable capabilities would still exist. But everybody wouldn't need to acquire that expertise before using them creatively.

Everything Is a Geode

I'm autistic, and one of the ways I've learned to navigate complicated subjects is by reconstructing them into smaller pieces that make sense to me.

Traditional technical explanations frequently present information according to the structure of the underlying machinery rather than the purpose of the system. Sometimes that works beautifully for me. Other times, I can understand every individual component and still have absolutely no idea why somebody connected them together.

Electronics schematics are an excellent example.

I can understand what resistors, capacitors, transistors, and integrated circuits do. But give me a sufficiently complicated schematic and I may struggle to distinguish the designer's intention from the electrical implementation. Why does this signal split here? Why are these particular components arranged together? What is this entire section actually supposed to accomplish?

The schematic may be electrically correct and still fail to communicate those answers.

So I break it apart.

This group of components generates power. This one filters a signal. This one amplifies it. Another section compares voltages or controls an output. Once I identify the purpose of each section, the circuit becomes a collection of understandable mechanisms rather than a maze of interconnected symbols.

I've started calling these functional building blocks Geodes.

A Geode has a defined purpose. It accepts certain inputs, produces certain outputs, and exposes understandable relationships to other Geodes. Multiple Geodes can combine into larger Geodes, which can themselves become parts of even larger systems.

It's the LEGO principle applied to computing and engineering. A block performs one understandable job, and increasingly sophisticated behavior emerges from arranging blocks together.

A Geode might represent something as simple as converting a temperature reading from Celsius to Fahrenheit. Another might handle authentication for an email service. Another could represent an entire inventory management system assembled from smaller components.

The important part is that the complexity can be expanded or collapsed according to what the person needs to understand.

You shouldn't need to examine how an email connection negotiates encryption just to build a tool that sends appointment reminders. But if you're interested in the encryption mechanism, the system should allow you to inspect that part without forcing you to decipher unrelated functionality.

This is how I naturally approach problems, but I don't think the underlying principle should be considered an autism accommodation alone.

I think it's a better way to communicate complexity to human beings.

And it leads to a fairly simple requirement for software:

Every part of a system should be able to explain what it does, why it exists, and what it connects to.

If I can see how something works, I can begin to understand it. If I understand it, I can change it. If I can change it, I can make it do something its original creator never considered.

That's where technology becomes genuinely empowering.

WYSIWYG, But for the Actual Computer

We've had WYSIWYG editors for decades. What You See Is What You Get. They're the reason ordinary people can create formatted documents without learning the markup languages or printing instructions required to produce them.

You arrange text, change fonts, position images, and see approximately what the finished document will look like. The implementation is handled by the software.

Why hasn't this philosophy become the foundation of general-purpose computing?

We have visual programming languages, node-based editors, automation platforms, and systems built around reusable components. None of these ideas is particularly new, and some implementations are extraordinarily capable.

But there's a recurring problem. Many eventually become conventional programming languages with the syntax replaced by colorful rectangles.

Instead of writing complicated instructions, you're arranging complicated instructions visually. You've replaced the keyboard with a mouse without necessarily changing how the person must think.

A genuine intent-based environment needs to go further.

It should represent the purpose and behavior of a system in a way that people can recognize. The implementation should be accessible when needed, but understanding it should not be a prerequisite for constructing something useful.

Imagine building a simple video game.

You create a world, place a character inside it, give that character movement, and establish the rules governing interactions with the environment. You connect an input component to movement behavior, attach collision behavior to objects, and define what happens when the player reaches a goal.

You can see these relationships. You can inspect them, modify them, and experiment with them.

You don't have to understand how the graphics pipeline transforms geometry into pixels or how a CPU processes machine instructions. You only need to understand the parts of the game you're trying to create.

If you eventually want to develop your own rendering engine, wonderful. The system should accommodate that too.

But you shouldn't have to understand how ones and zeroes eventually become Quake before you're allowed to invent your own game.

And that same freedom should apply to things far less glamorous than video games. Scheduling, inventory management, household automation, data analysis, record keeping, accessibility tools, musical instruments, and thousands of little applications people would create if the process weren't so unnecessarily intimidating.

The goal is not to make programming look easier.

The goal is to make creating functional software fundamentally more accessible.

Artificial Intelligence Isn't the Entire Answer

Inevitably, someone will point out that modern AI systems can already generate software from natural-language descriptions.

And they're right.

I use AI-assisted development myself. It's an extraordinary capability, and I believe it can play an important role in making computers more accessible.

But asking an AI to generate a program isn't necessarily the same as understanding the program you've created.

Suppose you describe your ideal inventory system to an AI. It generates a database, a web interface, several services, and thousands of lines of code. The application works, and you're delighted.

Until something breaks.

Now what?

Can you determine which component failed? Can you change how inventory reservations work without accidentally breaking purchase orders? Can you inspect the way customer information moves through the system? Can you confidently decide whether the application is safe to use?

Or do you have to return to the AI and ask it to make changes to something you never understood in the first place?

We've made software creation easier, but we may simply have exchanged dependence on a programmer for dependence on a machine that generates programming.

I don't think that should be our final destination.

AI should be able to help translate intentions into functional components, suggest relationships, create missing capabilities, and explain unfamiliar concepts. But the resulting system should remain understandable and editable by the human who owns it.

Ideally, AI becomes one of several ways to interact with the environment rather than the only thing standing between the user and the implementation.

You could describe what you want conversationally, construct it visually, or work directly with its underlying code. Different interfaces would operate on the same understandable model of the system.

And importantly, the model should not confuse a description of what something is supposed to do with proof that it actually does it. Components would still need contracts, testing, permissions, and observable behavior. Computers are entirely capable of being confidently wrong without adding artificial intelligence to the equation.

The future I want isn't one where machines do all the thinking for us.

It's one where machines help us turn our own thinking into something useful.

The Computer Should Be Able to Explain Itself

Let's return to our unfortunate QuickBooks employee.

In a system built around intent, the connection between the accounting application and the company database wouldn't merely be an implementation detail buried somewhere in the software. It would be a meaningful relationship between capabilities.

The application requires access to accounting records. Those records are provided by a data service. That service depends on storage, permissions, and network connectivity.

If the user requests access to the records and the operation fails, the environment can inspect the relationships involved and determine which requirements were not satisfied.

It might not always know the ultimate cause. Hardware fails. Networks disappear. Permissions prevent certain diagnostics. Software developers occasionally produce bugs of such breathtaking creativity that no reasonable diagnostic system could anticipate them.

But the system should be able to explain what it knows.

Instead of reporting a cryptic identifier and sending the user on a scavenger hunt, it should communicate the failure in terms of the original objective.

You tried to open your accounting records. The records are available, but the service responsible for providing access is not responding.

You tried to print a document. The printer cannot be reached at its previously configured address.

You tried to send an email. The message is ready, but authentication with the outgoing mail service failed.

And when the appropriate permissions exist, the computer should offer safe, understandable actions to resolve the problem.

This requires a different approach to software architecture. Components must describe their dependencies, expose meaningful diagnostic information, and communicate failures in ways that preserve the relationship between an operation and its purpose.

It also requires honesty. A system shouldn't invent an explanation merely because the user expects one. If the cause remains unknown, the explanation should distinguish observed facts from educated guesses.

But even imperfect diagnostics built around human intent would be an improvement over the tradition of displaying a hexadecimal number and expecting somebody to Google it.

I say this as someone whose profession has largely consisted of translating machine failures into human explanations.

I'd very much like to live in a world where my computer no longer requires me to perform an exorcism every time a Windows service stops responding.

Software Should Be a Workshop, Not a Shopping Mall

There's a much larger consequence to this philosophy, and I think it's the most important one.

Modern computing has turned most people into consumers of software rather than creators of it.

We browse application stores, subscribe to services, purchase licenses, and adapt our workflows to whatever a developer decided would appeal to the largest number of customers.

If the software doesn't do exactly what we need, we look for alternatives. If none exist, we develop workarounds. Perhaps we maintain an elaborate spreadsheet held together by formulas, conditional formatting, and a prayer.

Sometimes we hire somebody to make custom software. More often, we simply accept the limitation.

But the person experiencing a problem is frequently the person who understands it best.

A teacher knows what information would help them manage a classroom. A mechanic understands the peculiarities of their repair process. A musician knows how they want an instrument to respond. A caregiver understands the routines and requirements of the person they look after.

These people possess valuable knowledge, but we have created a technological environment in which they often cannot express that knowledge as functioning software.

Imagine if we changed that.

Instead of browsing an application store for the least objectionable solution, people could enter a digital workshop and assemble their own. They could start with existing components, adjust their behavior, connect them in unusual ways, and share the results with others.

A teacher might create an attendance system and share it with another teacher, who extends it to manage classroom equipment. A mechanic might build a parts tracker that becomes the foundation of a community workshop's inventory system. A musician might construct an unusual signal processor that inspires an entirely new instrument.

Every new creation could contribute capabilities that other people can reuse.

And because these systems would be assembled from understandable components, modifying somebody else's creation wouldn't necessarily require deciphering their entire implementation.

This is the part that excites me.

Not another marketplace of sealed applications, but an ecosystem of functional ideas that people can take apart, improve, and recombine.

There would still be commercial software. Professional developers would still create sophisticated components and complete applications. Specialized expertise would remain valuable, and some systems would necessarily require strict engineering controls.

But the ability to create useful software would no longer be reserved primarily for people who understand programming languages.

We would be giving people something more valuable than another application.

We would be giving them the means to make their own tools.

Accessibility Shouldn't Mean Less Capability

One of the more frustrating things about accessibility is how frequently it gets treated as a matter of simplifying something until it becomes sufficiently limited for the intended audience.

I don't want a simplified computer.

I want an understandable one.

Those are very different things.

My autism means I don't always process information in the way a system's designer expects. There are problems that other people navigate almost instinctively that I find extraordinarily difficult, and there are complicated relationships I can recognize almost immediately while other people are still trying to determine where to begin.

I often need to reconstruct information into a mental model that makes sense to me. Sometimes that involves visual relationships, sometimes functional blocks, and sometimes a completely different conceptual representation of the same underlying system.

That doesn't mean I need the system to possess fewer capabilities.

It means I need a different way to access and understand them.

I suspect many people experience some version of this, regardless of whether they're autistic. The difference between a novice and an expert is not simply intelligence. It's often the collection of conceptual models they've learned to use.

An experienced technician looks at a collection of network services and recognizes relationships that a beginner cannot yet see. An experienced musician looks at a chord progression and recognizes possibilities that someone learning their first instrument would never imagine.

A good tool should help people develop those models rather than require them to arrive with the models already installed.

Intent-based computing offers an opportunity to make interfaces adaptable to different kinds of understanding. One person might prefer a visual network of functional blocks. Another might prefer a structured description of behavior. Someone else might work through natural language, while an experienced developer may choose to operate directly on the implementation.

These aren't necessarily different systems. They're different ways of understanding and modifying the same system.

And that matters because accessibility should not be an afterthought bolted onto a product after development is complete.

It should be part of the fundamental relationship between humans and machines.

The measure of an accessible tool should not be how little it allows someone to do, but how much it allows them to accomplish.

Arcology Is My Attempt to Build It

I've been exploring these ideas through a project I call Arcology.

Arcology is my attempt to reconsider what an operating system might look like if human intention, functional composition, and understandable relationships were treated as fundamental design principles rather than optional conveniences.

That doesn't mean throwing away everything we've learned about computing. We still need efficient kernels, memory management, device drivers, networking, compilers, and all the extraordinary engineering that makes modern systems possible.

Those technologies exist for good reasons.

What I question is whether their internal organization should dictate the way people interact with them.

I'd like an operating system where functionality can be assembled from reusable components, where the relationships between those components have explicit meaning, and where the environment can help people understand what their creations are doing.

An environment where constructing an application feels more like assembling a functional mechanism than writing instructions for a machine.

Where you can begin with a simple component, inspect its behavior, connect it to something else, and gradually construct increasingly sophisticated tools.

Where the operating system can describe what a component requires, what permissions it possesses, and what might happen when it interacts with other components.

And where the final creation remains understandable enough that its owner can modify, repair, and extend it.

I'm not claiming Arcology has already solved all of these problems. Some of them are extraordinarily difficult. We have to address performance, security, compatibility, error handling, component discovery, and the uncomfortable reality that some human intentions are ambiguous or contradictory.

Nor do I believe every possible application can be reduced to a few cheerful boxes connected by colorful lines. Certain problems require deep technical expertise, and no abstraction can eliminate every underlying complication.

The goal isn't to eliminate complexity.

The goal is to make complexity proportional to the idea being expressed, rather than the machinery required to express it.

If someone wants to build a simple appointment reminder, it should be a simple task. If someone wants to build a distributed database, that is inherently more complicated, but its complexity should arise from the requirements of distributed computing rather than arbitrary limitations of the development environment.

Arcology is one attempt to investigate that philosophy. I expect to make mistakes. I expect to discover assumptions that don't survive contact with reality, and I fully expect some ideas to work better on paper than they do on an actual computer.

That's engineering.

But I don't want the philosophy to depend on Arcology succeeding.

If somebody builds a better implementation, wonderful. If an existing operating system adopts these principles, even better. If the ideas inspire tools I've never considered, then the project has accomplished something worthwhile regardless of what happens to my particular implementation.

Because the point was never really to build another operating system.

The point was to change what we expect from computers.

The Right to Understand

There's a philosophical dimension to all this that extends far beyond convenience.

Software has become part of the infrastructure of human civilization. We depend on it for communication, commerce, education, transportation, medicine, government, and just about every other activity involved in modern life.

And yet the majority of people have little meaningful understanding of the systems they depend on.

That's not necessarily a failure of intelligence or education. It's a consequence of how we've chosen to design those systems.

We routinely create software that hides its internal behavior, conceals meaningful dependencies, restricts modification, and communicates failures in terminology comprehensible primarily to its developers.

Then we tell people they need to become more technologically literate.

Perhaps they do. Understanding technology is valuable.

But technological literacy should not be a one-sided obligation.

I believe people should have the ability to understand what their tools are doing, what information they're using, and why they're behaving in a particular way. They should be able to inspect meaningful relationships, identify the capabilities they've authorized, and modify behavior where it is safe and appropriate to do so.

This doesn't mean giving every application unrestricted access to the machine or allowing every user to bypass necessary security boundaries.

Quite the opposite.

An intent-based environment could make those boundaries easier to understand by expressing permissions as relationships between capabilities.

A component that reads a document shouldn't automatically have permission to transmit that document over the internet. A program that manages appointments shouldn't quietly gain access to unrelated personal information. A component that controls physical machinery should be subject to the safeguards appropriate to its potential consequences.

These requirements should be explicit and inspectable, not buried in agreements nobody reads or implementation details nobody sees.

Meaningful control depends on meaningful understanding.

And increasingly, meaningful understanding depends on how willing technology is to explain itself.

The Revolution Isn't Artificial Intelligence. It's Human Agency.

We spend an extraordinary amount of time discussing what artificial intelligence will eventually be capable of doing.

Will it write our software? Will it design our machines? Will it replace our jobs? Will it become more capable than the people who created it?

Those are important questions, but I think we're missing another one.

What happens when ordinary people gain the ability to turn their own ideas into working technology?

Not merely through an AI service that produces mysterious software on their behalf, but through systems they can understand, inspect, and control.

What happens when a child can build a game because they understand its rules? When a small-business owner can build a management system because they understand their business? When someone with an unusual cognitive style can construct complicated tools using representations that make sense to them?

How many inventions have never existed because their inventors weren't programmers?

How many good ideas have been abandoned because the people who conceived them lacked the resources to turn them into functioning software?

How many hours of human life have been spent fighting systems that could have explained themselves more clearly?

We tend to measure technological progress by how much more capable our machines become. Faster processors, larger memory capacities, more sophisticated algorithms, and increasingly impressive demonstrations of automated intelligence.

I think we need another measure.

How much more capable do those machines make the people using them?

A computer that can perform a trillion operations per second is impressive. A computer that helps someone accomplish something they previously couldn't is useful.

And a computer that allows someone to create entirely new tools without requiring them to become a computer scientist might be genuinely transformative.

The distinction matters because I don't believe technology should be an end in itself. Its value comes from what it enables human beings to accomplish.

I don't want everyone to become a programmer.

I want programming, as we currently understand it, to stop being the price of admission for creating useful software.

A Declaration of Intent

I think Intent-Based Computing needs to become something larger than a design experiment. It needs to become a philosophy that developers, educators, engineers, researchers, and ordinary computer users can recognize and demand.

Its principles should be straightforward.

Intent should come before implementation. A computer system should represent what a person wants to accomplish, not merely the sequence of operations required to accomplish it.

Complexity should be composable. Sophisticated capabilities should emerge from smaller, understandable components with meaningful relationships.

Behavior should be explainable. Software should communicate what it does, why it does it, what it requires, and what went wrong when it cannot accomplish its purpose.

Creation should be accessible. People should be able to assemble functional tools using concepts they understand, without being forced to master the internal architecture of computers.

Ownership should include understanding. People should be able to inspect, repair, modify, and extend their tools rather than remain permanently dependent on their original creators.

These principles aren't a rejection of existing computer science. They're a challenge to make the extraordinary accomplishments of computer science more directly accessible to the people those accomplishments are supposed to serve.

We've already proven that computers can do astonishing things.

Now I'd like us to prove that people can do astonishing things with computers without first dedicating their lives to understanding them.

I've always wanted to leave the world a little better than I found it. Maybe Arcology becomes something important. Maybe it remains an experiment that contributes a few useful ideas. Maybe someone reading this will recognize a better way to accomplish what I'm describing and build something that makes my work look primitive.

I'd consider that a success.

Because this isn't about owning an idea or establishing another technology empire. It's about encouraging a different expectation of the machines we've invited into almost every part of our lives.

I want a future where computers are workshops for human imagination instead of collections of products we're permitted to operate.

Where a problem doesn't require a professional translator between the human and the machine. Where the knowledge someone possesses about their own work, hobbies, and daily life is enough to begin constructing tools that support it.

Where understanding is an architectural principle, not an optional feature.

And where the distance between I have an idea and I made something that works becomes as small as we can reasonably make it.

A hundred years of computing has taught us how to make machines execute instructions.

Perhaps the next hundred years should be about making those machines understand our intentions.

Not because people should stop learning how computers work, but because understanding the machine should be a choice, not a requirement for participating in the world we've built around it.

The computer was supposed to be the tool. The human was supposed to be the creator.

I think it's time we remembered that.