We had to learn what we were building.
When this started, the language was fuzzier. There was an app, there were models, there were project files, and there was a lot of hope that if the interface was good enough the workflow would hold together.
It did not hold together by accident. We rebuilt parts of the application more than once because the early versions taught us what was missing. We learned terms the practical way: dogfooding, AI harness, tool contracts, provider boundaries, acceptance tests, run evidence. They stopped being abstract words once the product depended on them.
The useful shift was realizing that Vicode could not be a thin wrapper around a model. The model is the engine. The app is the harness around it: the thing that decides what the model can see, what it can touch, how it asks for permission, and how a human can inspect the work afterwards.
Open model work made the problem more interesting.
Supporting local and hosted models means caring about the open model world as it actually is. One model might follow a JSON shape cleanly. Another might almost do it. Another might write the right intent in the wrong format. Sometimes the problem is not intelligence. It is protocol.
We tried several paths through that: stronger tool instructions, structured output experiments, repair passes, JSON rebuilding, capability probes, and provider-specific transport work. At one point even ideas like logit bias were on the table because the failure mode looked deceptively small: the model knew what it meant, but the application needed something parseable and safe.
That is why the model and provider screens matter. Vicode is built for people who care which model is running, where it is running, what it is good at, and whether it can actually participate in an agentic coding loop. Ollama is one important path in that work, and the model catalog browses Hugging Face GGUF variants alongside the Ollama library, because open model work is not one provider or one runtime.
A model is not the product
The model can reason and write. The application has to decide what context it sees, what tools it can use, when it needs approval, and how a person reviews the result.
Local models are not one thing
Open model work made the product honest. Different models respond differently to JSON, tool calls, summaries, and repair instructions. Vicode has to handle that without pretending every model behaves the same.
Dogfooding finds the real bugs
Using Vicode to build Vicode exposed the rough parts faster than polished demos did: stale assumptions, unclear boundaries, weak evidence, and places where the app needed to stop and ask.
Testing became part of the product
We learned to care about the boring proof: focused unit tests, browser checks, live-provider runs, diagnostics, and screenshots that show what actually happened.
Dogfooding changed the standard.
The most useful tests were not always the clean ones. They were the awkward runs where the app had to open a real workspace, use real context, ask to write files, recover from a bad turn, or explain why it refused something. That is where a product becomes honest.
We learned to separate what the model said from what the app could prove. A completed answer is not the same as a completed task. Vicode needed to show its work: what it ran, what it changed, and what proved the task was actually done.
That is the difference we want people to feel. Not just “a chatbot that writes code,” but an app for project work with AI, built under the pressure of maintaining our own projects.
