Just like this blog, we can make some things without much software around them. That makes me wonder: why do we need all this software to do what we want?
Of course not everything can just be a prompt. Some tools still need structure, controls, and a visible interface. But more software can be prompt-based than most people assume.
Sometimes a chat is enough
Some software can be a chat. You describe what you want, the system looks at the current state, and then it makes or changes the thing for you.
That is already how this blog works. I write ideas in chat, the agent turns them into HTML and CSS, and then the files become the site. The interface is not a big dashboard. The interface is the conversation.
The same idea can apply to other small tools. A todo list could work this way. A weblog like this can work this way. A little personal wiki can work this way too, a bit like the Karpathy LLM wiki idea.
Start with something small and change it later
One thing I like about this approach is that you do not have to fully design the structure up front. We can start with some design, fill it with blog posts based on your ideas, and then adjust the structure as we learn what we actually want.
That feels very different from traditional software. Usually you build a system, and then you are stuck inside the structure you created. Menus, fields, templates, and workflows all start to harden into place.
With prompt-based software, the structure can stay softer. We can change the page layout, add a section, rename a piece of navigation, reshape an archive, or turn a rough note into a finished post. The software does not have to stay fixed just because the first version existed.
The useful part is flexibility
Typing natural language into a box is the least interesting part. The output can become real working software, or real working content, without a lot of extra machinery.
- Describe a new page and get a new page.
- Ask for a cleaner layout and get updated CSS.
- Change the structure after the site already exists.
- Keep the result simple enough to inspect by hand.
A real example from today
Today I worked on a simple but useful case. There is a calendar with the days people have leave. What we need to know is how many days or hours that adds up to inside the sprint.
Before, I would have said we need to write some kind of software that connects to the official service we use. But now we can start with a prompt: starting today and for the next two weeks, count the hours and days of leave for the people on the calendar that we have.
Then we get a result, adjust it, fix the intermediate steps, and ask for a total. When the formatting and calculation are right, the next step becomes obvious: make a skill.
This is why I keep coming back to prompts first. We do not always need to begin by building software. Sometimes we can do the work in prompts first, then turn it into a reusable tool when the pattern is clear.
Not everything should be a prompt
I do not think every application should turn into a chat window. Some tasks are better with direct manipulation, visible controls, or stable tools that people can learn once and trust.
But there is a big category in the middle: software that mostly exists to help you describe, shape, edit, and reorganize something. That kind of software is a good fit for prompts.
Why I think this matters
Prompt-based software lets you start with intent instead of setup. Instead of learning an application first, you begin with what you want to make. Then the structure can follow.
For personal tools especially, that feels right. We can make software that works how we want, and keep changing it as our needs change, instead of locking ourselves into the first structure we happened to build.