Asking ChatGPT to write an email, explain a technical problem, or draft a piece of code is a different activity from building something other people can use without sitting next to you. The first is a conversation with a model. The second is software: an interface, data, rules, and a destination for the result.
People blur them because both involve typing English at a model. The test is simple. If the work happens once, or rarely, and a person can check the output before it matters, use the assistant. If the same work has to happen on a schedule, for more than one person, with memory and permissions, you are looking at an application.
Ken Ashe uses assistants and coding agents constantly. The systems he publishes at KenAshe.ai are what those conversations turn into when the job keeps coming back.
Use the assistant when the task is occasional
A one-off caption. A first pass at a letter. A question about why an error message looks like that. A sketch of a function you will read before you run.
In those cases the overhead of an application is wasted. You would spend more time specifying the workflow than you will ever spend repeating the task.
The assistant is also the right tool when the task changes shape every time. A model that has to invent a new approach for each request is doing conversation work. Nailing that into software too early freezes the wrong process.
Build an application when the task repeats
Signals that you have left chatbot territory:
The same workflow happens every day or every week.
More than one person has to follow the same steps.
Data has to be stored and found again.
The model has to read from or write to another system.
You want the output in the same format every time.
Steps exist before and after the model that nobody should have to remember.
At that point a conversation is a cost. Someone will forget a step. Two people will invent two versions of the “official” prompt. The application exists to make the official version official.
Do not confuse a development assistant with the product
A developer can ask ChatGPT or a coding agent to generate a component, explain an API error, or write a query. That output helps build the software. The finished application might call a different model, or no model, in production.
KenAshe.ai itself was built with Claude Code and reviewed by Codex. That is a construction story. The live site is not those tools.
The same split applies to business users. Using ChatGPT to think through a workflow is research. Putting that workflow into an automation with a review queue is the product.
Cost, risk, and the boring middle
Assistants look cheap because you see only the subscription. Applications look expensive because you see the plumbing. Count the human time on both sides. Ten minutes of pasting, every time, for a year, is a system. It is just an unpaid one.
Risk moves the decision too. A draft that stays in your window is cheap to get wrong. A draft that sends, publishes, or updates a customer record is not. If you are not ready to build the guardrail, stay in the assistant and paste by hand. That is not timid. That is proportional.
A practical rule
If you can describe the job as a paragraph you send to a model, start there.
If you find yourself sending a close cousin of that paragraph every day, write the paragraph down as a spec and put it in software.
If other people need the result to appear in a tool they already use, stop pretending the chat window is that tool.
The interesting public examples on Ken’s site all failed that last test as conversations and had to become systems: a morning brief that arrives by email, a Digest that publishes through a gate, a pitch agent that has one job. None of them required abandoning assistants. They required noticing that the assistant had become a bottleneck.
A decision table you can actually use
Occasional, low risk, one person: assistant.
Occasional, high risk: assistant, then a human, and do not store the output in a system of record until a person has edited it.
Frequent, low risk, one person: a saved prompt and a checklist, then a small application if the checklist gets long.
Frequent, high risk, several people: application with a review queue.
If you cannot place the job in that table, you do not understand the job yet. Stay in the assistant until you can.
Prompt libraries are not products
Teams love a shared doc of prompts. The doc lasts until two people edit it and nobody knows which version is official. That is the moment to ship a small application, even if the application is only a form that applies the official prompt and writes the result to a known place.
Ken’s conversation-to-system pattern
Read the build log in that order and the pattern repeats. A job that started as “I can just ask the model” became an email that arrives at 6 a.m., or a pipeline that publishes with a label, or an agent that pitches a real target. The prompt did not disappear. It got a house.
That is the only moral of the ChatGPT-versus-application question. Do not build a house for a guest who is not coming back. Do not keep a daily employee standing in the driveway.
There is a third option that articles sometimes skip: a checklist. Not an assistant, not an application, a list next to the official prompt. For a job that happens weekly and is owned by one person, a checklist can be the whole system for a year. Promote it to software when the checklist starts having branches.
