TL;DR
“AI writes all the code now. Even developers barely read it. So why build a product that helps non-coders understand scripts? Can’t they just ask the agent?”
Not really.
When what you’re building is a process, the process is the artifact - and you can’t verify an artifact you can’t see. Script.it makes the process itself visible: the steps, the data, the logic.
Here’s the take:
The objection
“Isn’t chat enough?” is a great question.
Developers increasingly accept AI-generated code without reading it. Products like Lovable and Bolt build entire apps and never show you a line of code. The direction of travel seems obvious: the code disappears in favor of the chat.
So why are we visualizing scripts?
It all starts with intention
When you want to use AI to create a video, you want to see the video. When you want it to create a deck, you want to see the deck. You wouldn’t be satisfied verifying the artifact only by asking about it.
When you build an app with Lovable, you don’t care about the code, because your intent is not to “write code.” It is to create an app. So they show you the app and let you click around and use it to verify it’s what you wanted. You wouldn’t ship an app you’d never seen or used - only talked about.
On Script.it, your intention is to build an automatic process. That is the artifact.
How do you “see” and verify that process?
You can obviously have a text file explaining the process, but that's not the same as seeing the process itself, because language is inherently ambiguous.
We’re not building an interface to read code as much as a surface to read the process.
Outputs are not enough
“Fine - but can’t I just look at the results? If the output is good, who cares how it happened?”
For simple one-off tasks, mostly yes. You inspect the output and you’re done.
For a complex process, not so much.
When you set a process loose to be automatically triggered, you’re not looking to verify an output. You’re verifying a machine that produces outputs - with branches, edge cases, things that stay constant across runs, and things that change with every input.
You won’t be there for run number 47.
Outputs tell you what happened in the past. Structure tells you what will happen in the future.
A common language
There’s a second reason you can’t just trust the conversation:
- The agent can be wrong. Asking the agent to explain its own work is self-reporting. You don’t verify a system by interviewing the component you’re trying to verify. Runtime data and structure are ground truth.
- You can be unclear. Your instructions were in natural language, and natural language is ambiguous. The only way to know the agent built what you meant - not what you said - is to look at what it actually built.
Which brings us to the deeper problem: how do you even talk about a process?
“Just ask the agent” assumes you know what to ask.
Language requires nouns. A developer has a shared language with an agent: files, functions, classes, services. That’s why developers can use agents to build complex things without writing - or looking at - code.
A non-coder staring at an opaque automation has none. They can’t ask about different parts of the process if they don’t have names for them. It’s like asking the agent to fix the second paragraph of slide 7 in the deck, or the color grading of the second shot in the video. These are shared concepts to establish communication around.
Script.it’s primitives are that missing vocabulary: shared concepts that you and the agent can both point at, like steps, triggers, and outputs.
The new spreadsheet
We believe scripts will become as ubiquitous as spreadsheets. The spreadsheet used two simple primitives - cells and formulas - to create a billion programmers. Script.it tries to do the same by creating a new programming language to codify processes.
Company as a Codebase, continued
We’ve written before that the way to transform the workplace is to accelerate and democratize scripting - to build the company as a codebase that runs autonomously.
If people are going to architect their company’s processes and make the important calls, they need direct, hands-on access to those processes to verify and improve them. They’ll do it through a shared view of the process - one they can use with agents and with each other.