AI is moving the first working version of software closer to the person who imagined it.
For more than fifty years, one of the first programs a new programmer has been asked to write has done almost nothing. It prints two words: “Hello, world.” The earliest known version is generally traced to a 1972 Bell Labs tutorial by Brian Kernighan, and the example later became a tradition through the C programming language. It is modest by design: before asking the computer to calculate, remember, draw, or play, you first prove that you can make it speak.
There is something generous about such a small beginning. A blank screen answers you. The machinery is connected. You have crossed the first threshold. But the tradition also contains an old truth about software creation: before making the game, tool, or experience that brought you to the computer, you had to learn how to address the computer on its own terms.
A teacher thinking about a vocabulary game does not naturally begin with a programming language. She begins with a child who remembers words better through pictures, loses patience after two wrong answers, and stops playing when an exercise starts to feel like a test. A designer may begin with an interaction she wants to feel less awkward. An operator may begin with a routine that makes no sense every Tuesday afternoon. Their ideas arrive as situations, not specifications. The promise of AI is not that it can print “Hello, world” more quickly. It is that the first thing a person makes can begin to resemble the thing they came to make.
Before You Could Make the Idea, You Had to Translate It
Software is exact because it has to be. A person can say that a game should become “a little easier” after a child struggles, but a computer needs the phrase unfolded into decisions. What counts as struggling? Does easier mean fewer choices, more time, a stronger hint, or a different word? When does the rule reset? What should happen if there is no image for the next question? The vagueness of the human intention has to become the precision of a system.
For most of software’s history, that translation had to happen before the person with the idea could encounter much of the idea itself. Intentions became requirements; requirements became components, states, and data models; those became code, databases, and deployed services. Each layer solved a real problem. Together, however, they placed a long technical sentence between “I want this to happen” and “let me see what happens.”
In 1985, Edwin Hutchins, James Hollan, and Donald Norman gave interaction design a useful way to think about this gap. In their paper Direct Manipulation Interfaces, they described “semantic distance” as the relationship between what a user intends and the expressions an interface requires. A small distance does not mean that the underlying system is simple. It means the person can act in terms that feel closer to the task itself, and can understand the result without continually translating between two worlds.
The paper was not about AI app builders, but its distinction reaches directly into the present. When a person wants to move a shape, dragging it across a visible surface places the action near the intention; entering numerical coordinates places it farther away. When a person wants to change how a vocabulary game responds, describing the response while looking at the game is nearer to the intention than first representing the entire experience as unfamiliar syntax and architecture.
This is not an argument against programming. The precision encoded in programming languages, frameworks, and infrastructure is what makes dependable software possible. The difficulty begins when a person must pay the full cost of that precision before they can receive meaningful feedback about the idea. Translation becomes not only part of making, but a condition for being allowed to begin.
The First Working Version Used to Arrive Late
Ideas rarely emerge complete from thought. A novelist discovers a character by hearing what the character says on the page. A furniture maker learns from the weight of a joint. A filmmaker sees that a transition which made sense in a script feels wrong in the edit. Creative judgment does not simply precede the artifact and command it into existence; it develops by responding to what has been made.
Software has often made that conversation unusually expensive. A sketch can reveal layout, and a prototype can imitate a sequence of screens, but many important questions do not appear until the thing works. Does the game become tedious after the fourth round? Does the tool remember the right information? Is a response fast enough to feel connected to the action that caused it? Does the experience invite another attempt, or make failure feel final? Behavior cannot always be judged from a picture of behavior.
When the first usable version arrives late, creative learning arrives late with it. A team may spend weeks refining a coherent description of the wrong interaction. A person working alone may never begin, because the amount of technical work required to ask the first creative question is too high. The loss is not only time. It is the feedback that might have changed the idea before the idea hardened into a plan.
This is why shortening software creation matters even when speed itself is not the goal. The important change is not completing the same process in fewer hours. It is moving a working, changeable artifact to an earlier point in the process, when the creator still has room to be surprised by it. The first version can stop behaving like a late proof of execution and start behaving like an early instrument of thought.
Approachable Tools Have Always Changed Who Could Begin
In 1987, Apple released HyperCard, created by Bill Atkinson, and included it free with new Macintosh computers. A HyperCard project was built from a metaphor people could see: stacks of cards containing text fields, pictures, checkboxes, and buttons. A person could arrange these objects directly, connect cards, store information, and make an interactive work without beginning inside a conventional programming environment.
HyperCard was not a toy that eliminated technical depth. Behind its visible objects was HyperTalk, a scripting language that let creators add more elaborate behavior. People could begin by placing a button on a card, then learn to describe what should happen when the button was clicked. The surface offered an immediate object; the scripting offered a path further in.
That sequence mattered. HyperCard could support address books, teaching materials, games, presentations, and prototypes because it did not require every creator to understand the entire machine before seeing a recognizable result. Even the original Myst was built as a HyperCard stack, though its sophistication should not be mistaken for evidence that craft had disappeared. The larger lesson is that an approachable entrance can coexist with extraordinary work.
HyperCard also showed that the form of a tool shapes the population of ideas that gets made with it. When cards, links, fields, and buttons are available at the beginning, a person can think through relationships among visible things. They can try a sequence, click it, notice the break, and change it. The technical system is still there, but it meets the creator through an object that already resembles the work.
Every approachable tool chooses what to bring nearer and what to leave deeper in the system. HyperCard brought interface objects and simple behaviors nearer. Spreadsheets brought calculation nearer by making formulas act on visible cells. Website builders brought pages and layouts nearer. AI now brings another layer toward the surface: the ability to describe intended behavior before knowing the exact formal expression that will produce it.
AI Moves the First Working Version Earlier
Natural language changes where translation happens. A creator can describe the situation first: show one word at a time; let the child choose an image; after two wrong answers, make the next round easier. The system still has to turn those instructions into components, rules, and state. But the creator can take part in that translation while looking at something that works, rather than completing it entirely before anything works.
This is a more important shift than the spectacle of producing an interface from a single prompt. A generated interface can be visually convincing while misunderstanding the experience. A button may exist but do the wrong thing. The game may technically run but become impossible after one round. The value of the first version is not that AI has declared the work complete; it is that the creator finally has a specific object to question.
Once the object exists, ordinary language becomes more precise. “Make it friendlier” is difficult to act on because friendliness has no single behavior. After using the first version, the creator may be able to say: keep the picture on screen after a wrong answer, remove the red flash, and let the child try once more before showing the word. Contact with the artifact turns an intention into a decision.
This creates a loop that resembles direct manipulation at a different level. Instead of dragging a visible object and immediately seeing its new position, the creator describes a behavioral change and sees how the experience responds. The action is not always immediate, perfectly predictable, or reversible, and natural language is not a substitute for understanding the result. Still, the semantic distance is smaller because the conversation can remain closer to the purpose of the work.
AI therefore does more than accelerate implementation. It changes the order in which implementation and judgment can meet. Previously, much of the implementation had to be settled before a creator could exercise judgment on a functioning experience. Now a rough implementation can arrive early enough to help create the judgment that will shape the next one.
“I Can Do This” Begins With Something You Can Change
People are often told that a new tool is “for everyone.” The phrase is meant as an invitation, but it can feel strangely unpersuasive. A label does not dissolve the distance between a person and a medium. Someone begins to believe they can make a film, a song, a chair, or a program when an action of theirs changes the material and they can recognize their own decision in the result.
The important moment is not simply “the AI made something for me.” That can leave the person in the position of a customer receiving an opaque result. The stronger moment is: I asked for a change because I understood what the work needed; the work changed; and I can judge whether the change was right. The person may not yet know how every part was constructed, but they are no longer outside the act of construction.
This is where “I can do this too” becomes more than encouragement. It names an experience of causality. A creator notices that the choices are too obvious, the feedback comes too late, or the rhythm feels punitive. They decide what should happen instead. When that judgment becomes visible in the next version, creative identity grows out of evidence.
Coding ability does not divide the people for whom this matters. An experienced engineer can also be kept from testing a small idea by the time required to scaffold, connect, and deploy its first version. A person who has never programmed may face more of that distance, but the underlying creative problem is shared: no one should have to pay the full software-engineering cost before learning whether an idea works in use.
Eazo Starts Where the Idea Is Still Ordinary Language
Eazo’s Create experience is built around that earlier beginning. A person can start with natural language or images and work with AI toward a functioning App. The point is not to ask them to disguise a product specification as a prompt. It is to let an idea enter the process while it still sounds like the person who had it: a situation, an intended response, an image, or a rough description of what someone should be able to do.
Imagine, for example, that someone wants to make the vocabulary game described earlier. This is not a customer case or a claim about a finished Eazo App; it is the kind of idea that reveals what an early working version is for. The creator asks for one word to appear at a time, a set of images for the child to choose from, and an easier next round after two wrong answers. Eazo helps give those relationships a form that can be opened and used.
The first version may immediately reveal what the original description could not. Perhaps the incorrect images are so absurd that the answer is obvious. Perhaps the pause after each choice is long enough for the child to lose the thread. Perhaps the large score at the top turns play into a visible record of failure. None of these problems means the idea was bad. They mean the creator has reached the part of making where the idea can answer back.
Now the next request can be grounded in experience: choose images that are easier to confuse; respond as soon as the child taps; replace the score with a small trail that grows after each round; use a gentle hint after the second mistake. Each instruction carries more judgment than the original prompt because it comes from using the work. The creator is not merely asking AI to generate again. They are directing a revision.
This is the Eazo relationship that matters for this essay: an ordinary intention can become a first working version; the person can open it, use it, notice something specific, and change it. The shorter distance does not lie only between a prompt and generated code. It lies between a person’s judgment and the next version in which that judgment can be tested.
A Shorter Distance Does Not Mean a Finished Product
Moving the first working version earlier can make software creation feel startlingly immediate. It can also make a rough result look more complete than it is. A polished screen says little about how an App behaves with unexpected input, protects private information, recovers from failure, or changes when an external service stops responding. The distance to a first version may shrink much faster than the distance to a trustworthy one.
This distinction matters most when another person begins to rely on the work. A vocabulary game used in a family has different consequences from a tool handling medical records, financial decisions, or children’s personal data. Both deserve care, but the second category brings obligations that cannot be satisfied by conversational ease. Security, accessibility, privacy, testing, monitoring, and maintenance do not become decorative because generation is fast.
AI does not make expertise irrelevant. It changes when expertise has to enter the process. A creator may be able to test the central interaction before understanding deployment or data architecture, then bring deeper technical knowledge to the parts that require it. An engineer may use the same early version to discover requirements that no specification would have exposed. The sequence can become more flexible without the standard becoming lower.
Nor is every unsatisfactory result best solved by another prompt. Sometimes the creator needs to inspect the implementation, rethink the premise, test with the people affected, or accept that the tool cannot yet support what the idea requires. Being able to begin does not guarantee being able to finish. It gives the person better evidence about what finishing would demand.
The responsible claim is therefore narrower than “anyone can build anything.” More people can reach a working version while their ideas are still open to change. That version can make the hidden questions visible. What happens next still depends on judgment, knowledge, effort, and the consequences the software will carry.
The First Program No Longer Has to Say Hello
“Hello, world” endured because it makes a difficult threshold feel small. Two words confirm that the language, compiler, machine, and person have managed to meet. For generations of programmers, that tiny answer has marked the beginning of a longer education in what a computer requires.
AI does not make that education obsolete, and it does not exempt software from precision. What it can change is the order of the introduction. A person may meet the medium through the vocabulary game, the awkward weekly routine, or the interaction they cannot stop thinking about. Instead of demonstrating that they can speak to the machine before touching the idea, they can begin a conversation with the idea itself.
The decisive moment will not be the first impressive generation. It will come when the person opens the unfinished version and finds something they want to change: this choice is too easy, this pause is too long, this response misunderstands the child. They know what should happen next, and they have a way to make that decision part of the work.
The first program no longer has to say hello. It can ask a question, remember an answer, make someone laugh, or fail in a way that teaches its creator what the idea was missing. That is when “I have an idea” becomes “I am making it.”