Context Is the New Code
When the Proposal Arrives as Working Software
Imagine sending a client the usual technical and commercial proposal, with an appendix describing what the system will do. Normally, you wait for the client to say yes, and only then do you start building. But what happens when that same appendix, instead of remaining a document, becomes the starting point for something tangible?
At the next meeting, you are no longer bringing a promise. You are bringing working software, ready to show on screen.
The conversation changes. It is no longer, "Can this be done?" It becomes, "Move this button and change that color." The proposal and the prototype are produced from the same source material, in the same afternoon.
This is not a hypothetical scenario. It happened, and it is worth explaining how.
Three Questions in Twenty Years
For years, the value of the people who built software was thought to lie in the hands on the keyboard. Then, for a brief period, some believed it lay in prompts, the supposedly magic instructions given to an artificial intelligence.
Both answers are now incomplete.
The question that matters has become a different one: can you describe the problem clearly and bring the right source material?
Anyone who holds the context of a domain, the salesperson with the proposal, the technical specialist with the documentation, the entrepreneur who knows the client, is now one step away from a working prototype without first routing everything through a development team.
The raw material is no longer code. It is what you already have sitting in a file somewhere.
From an Attachment to an App, by Talking
In this case, the starting material was not a formal specification or a technical design. It was the product's functional documentation: a list of the operations the system could perform, together with their parameters. The kind of appendix that could accompany almost any proposal.
The instruction given to the AI was simple and expressed in plain language: analyze these files, work out what they describe, and build a complete application that uses all of these functions, adding the features that applications of this kind usually lack.
Context plus objective. No technical jargon.
Before long, a real working interface emerged: the main screens, commands with the appropriate safety confirmations, real-time data visualization, and an activity log. Not a static mock-up, but an application that could actually be used.
From there, the software grew through conversation.
"Make the interface more modern and remove the emoji." A complete redesign.
"Add Italian and English." It became bilingual.
"Review the website of a similar product and add the features that make sense." The AI read a competitor's documentation, selected what was realistic, and added it.
Then came the most revealing request: "Build a second version that is identical to this one, but connected to a different system."
The result was the same interface with the engine underneath replaced. A twin product connected to another data source, while everything the user could see and interact with remained unchanged.
The Carpenter Who Has Never Seen Your Home
This is where it is worth pausing on the underlying idea, because that is the part that lasts.
Three shifts took place.
The first is the shift from writing code to curating context. The value no longer lies in the hands doing the typing, but in the domain material you bring and the clarity of the objective. A well-prepared technical and commercial proposal is already half the work, because it defines what the product does, who it is for, and within what constraints.
The second is the shift from software as a construction project to software as a conversation. Not a monolithic project delivered months later, but a dialogue in plain language, where each request becomes a feature or a refinement.
The third is the new role of the human: director, not typist. You bring the context, make the calls at each fork in the road, and validate the result.
It is like moving from building a piece of furniture yourself, with timber and tools, to describing it to an expert carpenter who has never seen your home.
Your value no longer lies in knowing how to plane the wood. It lies in knowing what piece of furniture is needed, where it will go, who will use it, and whether what comes back is right.
What Does Not Disappear, but Shifts
It would be dishonest to stop at the excitement, and fortunately the limitations are the most interesting part.
Expertise is still required, not necessarily to write the code, but to provide the right context and judge the result. Garbage in, garbage out.
Human verification remains essential because AI produces plausible outputs that are sometimes wrong. In the real case, the work went through checks, fault-finding reviews, and live tests before anyone said, "This is good enough."
When the AI was asked to critique its own work, it identified several weaknesses and proposed corrections. That was useful, but a person still had to decide what to change and take responsibility for the result.
The decisions that carry real weight, including security, privacy, and product direction, remain human responsibilities.
Rigor does not disappear. It moves from the act of writing code to the work of framing the problem and validating the solution.
What This Means in Practice
All of this means different things depending on where you sit.
If you run a business, the material you already have, proposals, product sheets, price lists, can become fuel for prototypes. You can validate an idea with a client before investing in full development.
If you work in sales, you can walk into a meeting with a demo built from the client's own documentation, because what people can see and use is easier to sell.
If you work in consulting, the deliverable changes. It is no longer limited to slides; it can include working prototypes.
If you cannot code, the new literacy is not programming. It is the ability to describe context and objectives clearly, and to recognize a good solution when you see one.
If you build software, the work shifts toward architecture, verification, security, and direction: less typing, more judgment.
For years, the bottleneck was knowing how to build. Today, that bottleneck has moved. The problem is no longer primarily how to make something, but knowing what to build and for whom.
The oldest part of the craft becomes central again: knowledge of the domain and the customer.
There is, however, one detail I have left out of this story.
The prototype was not written by a single artificial intelligence working alone. It was built by a coordinated team of AI assistants: one built, one reviewed, and one tested.
Learning how to orchestrate that team is a different skill, and perhaps the more consequential one.
I will cover that in the next article.