Prompted Into Motion

What Vibe Coding Taught Me About Architecture, Expertise, and the Limits of AI-Assisted Building

When I first started experimenting with vibe coding, I was not trying to build a startup.

I was trying to investigate a question.

I wanted to understand how conversations with large language models unfolded over time. Not primarily at the level of content, but at the level of interaction: language signals, rhetorical intensity, and the subtle dynamics that shape the relationship between user and system across a conversation.

That idea eventually became the beginning of what I thought of as a cognitive analysis engine.

I was completely non-technical. I did not know how to write production code. I did not understand software architecture in any serious way. I had no background in deployment, security, data pipelines, or system design. What I had was a clear conceptual problem, a growing set of categories, and access to AI tools that could translate instructions into working code.

So I began. I wrote instructions. I created an agent.md file. I prepared supporting markdown documents with context, definitions, and intended behavior. I do not remember every file name now, but I remember the feeling. I was trying to give the system enough structure to understand what I wanted. I was not coding in the traditional sense. I was directing, correcting, refining, and insisting until something emerged.

I came to think of it as prompting into submission.

And the strange thing is that it worked. At least at first.

I was able to produce a working prototype far more easily than I would have thought possible. The system took in conversation data, analyzed it according to the categories I had defined, and began producing outputs that resembled the thing I had imagined. For someone without technical training, that was astonishing. A few years earlier, the idea would have remained trapped in a document. Now it could become something I could click, test, and modify.

That was the power of vibe coding. It gave motion to an idea before I had the technical ability to build it myself.

But that was also the problem. I could make the system move before I understood the machinery.

The Prototype and Its Limits

The first version of the cognitive analysis engine felt like proof that something was possible. It could process interaction data. It could identify patterns. It could generate structured outputs that approximated the kind of analysis I wanted to perform.

But as soon as I stepped back from the excitement, a more uncomfortable fact became obvious. I did not really know what it was doing.

I knew what I had asked it to do. I knew what I wanted the output to mean. I knew how the system appeared from the outside. But I did not understand the internal logic well enough to trust it, did not know where it was fragile, where it was improvising, or where the architecture itself was wrong.

A prototype can demonstrate direction. It can show that an idea has shape. But a prototype is not the same thing as a trustworthy system, and a functioning output is not the same thing as understanding.

In the beginning, my process was mostly force and iteration. If something broke, I prompted again. If a feature did not work, I described the intended behavior more clearly. If the model misunderstood the architecture, I corrected it. Over time, the tool became more functional, and there is a real skill in that — being able to define a desired behavior and guide a system through rounds of correction is not nothing. It allows people without technical training to participate in building at a level that was previously unavailable to them.

But it can also create a dangerous illusion. The system begins to feel understood because it responds. It begins to feel mastered because it obeys. That feeling can conceal ignorance. I was not building from first principles. I was pushing the system toward a desired result. I could recognize when the output matched my intention, but I could not always evaluate whether the underlying structure was sound.

I could describe the destination better than I could inspect the bridge.

That gap became impossible to ignore once I started asking how the prototype should be evaluated.

Designing the Design

At first, I thought the next step was to improve the tool. Then I realized the more important step was to test it.

If the cognitive analysis engine was going to examine conversations and interpret interaction dynamics, I needed some way to know whether its outputs were meaningful. It was not enough for the tool to produce a report. I needed to know whether the report had any grounding.

That pushed me into benchmark design, which immediately exposed another layer of ignorance. I did not simply need to know whether the system worked. I needed to define what working meant. What exactly was being analyzed? What counted as evidence? How would I know whether a detected signal was real, overstated, or hallucinated by the system? How could I separate language structure from content judgment?

The moment I tried to design a benchmark, I discovered that I first had to design the design. The problem was no longer how to prompt the system into producing an output. The problem was how to create the conditions under which the output could be evaluated responsibly. A tool can be useful when it produces a result. A research instrument has to be legible, calibrated, and accountable.

I had started with a prototype. I had arrived at methodology.

Once I understood that, I began thinking less like someone trying to get software to work and more like someone trying to design an analytic system. I had to separate layers I had previously allowed to blur together. Language signals were one layer. Rhetorical intensity was another. Interaction dynamics were a third. Each required different definitions, different extraction rules, and different interpretive constraints. Collapsed into one general judgment, the output would feel insightful while becoming analytically useless.

I started building input pipelines and working on orthogonal analysis, so the system would not treat every interesting feature of a conversation as evidence of the same thing. I drafted blueprints for the report the system would eventually produce. I began articulating a system ethics: what the tool should not claim, what it should avoid diagnosing, where uncertainty should be preserved.

This was no longer vibe coding. It was architecture, and the architecture was harder than the code. The code could be generated and the interface could be improvised, but the underlying structure of the analysis had to be designed by someone willing to be wrong about it in private, repeatedly, before claiming it in public. The system needed categories, boundaries, constraints, and a philosophy of use. Without that, the product would become a machine for generating confident-looking interpretations of human interaction — which was exactly what I did not want to build.

The real work was not getting the model to say something. The real work was deciding what the model had any right to say.

What the Architecture Revealed

That realization pulled me past the original cognitive analysis engine and into a larger question.

The deeper I went, the clearer it became that I was not only studying how to analyze language in AI conversations. I was studying how human beings relate to intelligent systems at all. If a conversation with an AI system can shape confidence, dependence, agency, and self-understanding, then interaction design is not a surface concern. It is developmental. The way a system responds may train the user. The way a system remembers may shape identity. The way a system asks or answers may strengthen agency or quietly erode it.

I noticed this most clearly in a small decision I had to make about the tool's own outputs. Early versions of the report would state a detected pattern with full confidence: this conversation shows escalating rhetorical pressure. It read well. It sounded like insight. But I had no principled way to say how confident the system should actually be, and once I tried to add that confidence honestly, the report became harder to write and less satisfying to read. The version that told the truth about its own uncertainty was a worse product and a better instrument. That tradeoff was the whole argument in miniature. A system that resolves uncertainty for the sake of feeling useful is teaching the person something, whether or not anyone intended it to.

The prototype, in other words, was never really about conversation analysis. It was a small, contained version of the problem Tree exists to address: what does it mean for an intelligent system to scaffold a person's judgment instead of replacing it, quietly, one confident sentence at a time?

The Limit of Vibe Coding

The more the vision expanded, the less comfortable I became with the idea that it could be prompted into existence.

A person can vibe code a prototype. A person can generate a demo that clarifies an idea. But systems involving privacy, memory, identity-sensitive interaction, agentic behavior, and user trust cannot responsibly be built through prompting alone. They require technical knowledge, engineering judgment, security architecture, testing, and failure analysis — people who understand the machinery deeply enough to know where it breaks.

This became one of the most important lessons of the process: a system I do not understand is not a system I can responsibly ask others to trust.

That sentence changed how I thought about Tree. It did not make the project smaller. It made it more serious, and it clarified the difference between exploration and implementation. Vibe coding was useful for discovering the shape of the problem. It was not enough to build the solution.

If Tree were only essays, I could continue alone for a while. If Tree were only a conceptual architecture, writing and research might be enough. But if Tree is ever going to become software that touches a person's digital life, memory, attention, and decisions, the technical architecture has to be real. It cannot be a pile of generated code held together by prompts I do not fully understand, with a philosophy attached to make it sound considered. The deeper the human stakes, the more serious the engineering must be.

The Question Problem

There was another lesson, and in some ways it was even more humbling.

My lack of technical knowledge did not only limit what I could build.

It limited what I could ask.

At first, I thought the gap was mostly execution. I had ideas, but I needed someone who could translate them into code. That is the common non-technical founder mistake. It treats engineering as implementation labor, as if the idea exists fully formed and the technical person merely makes it real.

That is wrong.

Technical knowledge changes the questions themselves.

An experienced engineer does not only ask whether a feature can be built. They ask how the system should be structured, what should happen when it fails, where the data lives, what permissions are required, what dependencies are introduced, what attack surfaces are created, and what tradeoffs are being accepted without being named.

Those are not afterthoughts. They are part of the idea.

Because I lacked that domain knowledge, the scope and depth of my questions were limited. I could ask about user experience, conceptual architecture, ethical boundaries, and the purpose of the system. Those questions mattered. But I could not always ask the deeper implementation questions because I did not yet know the terrain well enough to see them.

I did not merely lack answers.

I lacked some of the vocabulary required to ask the right questions.

That is where vibe coding can mislead a person. It can make the non-technical builder feel closer to technical competence than they actually are. The AI can produce code. It can explain code. It can debug code. It can even teach. But none of that substitutes for years of targeted contact with a domain.

There is no shortcut around expertise.

There are tools that accelerate learning. There are systems that make experimentation possible. There are new pathways into building that did not exist before. But engineering judgment is not simply the ability to produce code. It is the ability to understand systems across time, under pressure, in failure, and in contact with reality.

That cannot be prompted into existence overnight.

Why Engineers Matter

This is why I am now looking for engineers, programmers, developers, and technical collaborators.

Not because I need someone to build my idea. That framing is too small.

If Tree ever becomes a serious platform, engineers will not be implementation assistants. They will be co-authors of the architecture. They will see problems I cannot see. They will challenge assumptions I do not know I am making. They will know when a concept is technically naive, when a proposed feature creates risk, when a privacy promise requires a different architecture entirely, and when a system should not be built in the form I first imagined it.

That is not a threat to the project. It is the condition of making the project real.

Vibe coding taught me that AI-assisted building is powerful, and that power without understanding can become dangerous quickly. It let me build before I understood, which was useful, because it helped me discover the actual shape of the problem. It also taught me why systems with real human stakes require more than prompts.

Tree began as a philosophical and developmental project. It is becoming a product vision. If it is ever going to move responsibly from writing to software, it will need technical people who meet the architecture with the same seriousness the ideas demand.

Vibe coding helped me reach the boundary of my competence. Crossing that boundary did not require a better prompt. It required humility, expertise, and other people.