Don't vibe code. Architect the system.

Founder + system = business

I turned a passion project into a pilot-ready product in 13 months — using AI, working a full-time job, and building all of it myself. It's an AI tutor that watches how an engineering student solves a problem instead of just checking the answer they land on, and it goes into its first university course this fall.

I'm Jason Clement. PhD in mechanical engineering, former engineering professor, and my day job is medical devices. I am not a software engineer.

The AI wrote most of the code. It did not make the decisions. This page is how I split those two things — free, complete, nothing gated.

The honest part

Vibe coding works. Then it stops.

I started the way most people start: describing what I wanted and letting the tool build it. In one evening I had a working site. Within weeks it had logins, a database, and a chat tutor. That is not a trick and it is not a toy — it is genuinely the fastest way to find out whether an idea is worth anything.

What nobody tells you is where the ceiling is. Not that there's a ceiling — where. You find it the way I did: something breaks, you describe the fix, it half works, you describe it again, and three days later you are further from working than you were on Monday. Nothing warned you. The tool was as confident on day sixty as on day one.

This isn't a knock on the tools, and they're honest about it themselves. Researchers built a benchmark out of real production traces from one of these platforms — ordinary product requests, the kind you'd actually type. The best models finished under half of them correctly on the first attempt. One platform's own engineering write-up puts it more bluntly: most models get worse when extending their own code, and errors compound.

So the ceiling isn't the tool being bad. It's that the thing you're building has started making demands that "describe it and see" can't answer — and you are the only one who can say what those demands are.

Layer one

If you're vibe coding right now, four rules

No system, nothing to install, nothing to adopt. These work tonight, in whatever tool you already have open, and each one raises the ceiling a little.

Talk it all the way through first

Before you ask for a single thing to be built, open a chat and describe the idea like you're explaining it to a smart friend who doesn't know your world. Who is this person. What are they doing right before they need it. What happens when it goes wrong. Then ask it to push back — to poke holes in the business, argue the user won't behave that way, tell you what you're assuming.

Your job in that conversation is not to be right. It's to supply the part it cannot know: how your field actually works, what people actually do, what "good" actually means where you come from. This is the advice I gave my sister-in-law about her business idea before she wrote anything down, and it's the first thing I did with mine.

It shows up in the numbers, too. My median message to an AI is 37 words — but the ones that actually moved the project ran 500 to 1,800, and there were only a few dozen of them. The short ones fix typos. The long ones decide what gets built.
Make the plan outlive the chat

Most of these tools now have a plan or discussion mode that describes what it's about to build before it builds it. Use it — you will find a wrong assumption almost every time, and catching one in a paragraph costs a minute where catching it in working code costs an afternoon. But notice where that plan lives: in the conversation. Conversations end, and the next one starts from nothing. Copy the plan into a file you keep. Correct it there. Paste it back at the start of the next session. What made the difference for me wasn't planning — it was that the plan was still there in November.
Harvest your corrections

Your tool almost certainly has somewhere to put standing instructions — a rules file, a knowledge panel, custom instructions. Some of them create one for you and read it automatically. What none of them do is fill it in when the AI gets something wrong about your field. That part is yours, and it's the highest-return fifteen seconds on this page: one line each time — what it said, what's actually true, and why. Mine has sixty-six rules in it now, every one of them from a mistake that actually happened. Skip it and you will re-argue the same point every week for as long as you use the thing.
Decide what it isn't allowed to decide

Before you start, name the two or three calls that are yours: what "correct" means in your field, which failures are unacceptable, who this is actually for. Write them down. Then notice how often you were about to let a confident paragraph make one of them for you.

Layer two

What the ceiling looked like for me

My project needed two languages — a web front end, and a Python engine doing the actual mathematics. A published app could only expose one public address, so I ran the two halves as two separate projects that talked to each other over the open internet. Every deploy was a manual re-publish. I was paying for two machines that couldn't properly see each other.

There was probably a way to keep them together that I never found. That's the actual lesson: nothing told me I had just made an architecture decision. I typed a request, got something that worked, and only discovered months later what I had committed to.

For anyone wondering whether the discipline below actually produces anything: for a single textbook problem, the system works out more than a hundred thousand distinct valid ways to solve it before any student opens it — so when a student takes an unusual route, deterministic code recognises it rather than the language model guessing. Roughly three thousand automated tests run against that behaviour, and it went through a security and privacy review before a single student touched it.

That wasn't the tool failing. I'd chosen it for its AI, and by then I had stopped using that AI and was building locally. My system had outgrown what a speed-first tool manages for you — which is a good problem to have, and the point where the four rules above stop being enough.

So I did two things, and they are the whole method in miniature. I let the AI teach me the operations I didn't know — services, networking, environment variables, deployments — because that half it is genuinely better at than me. And I made the architecture call myself, because that half is mine. Everything below is the machinery that keeps that line in the right place.

Layer three

The system, one piece at a time

Five documents. Each is a real working file from my own build, stripped of anything specific to my project — every page says at the top what it came from. They stand alone, so take one and ignore the rest. If you only do one, do the first. It needs no code and no repository, and you will have something worth arguing with by tonight.

Make it yours

Build your version

The templates are mine. The value shows up when they meet your expertise — so this fills in the adaptation prompt with your details and shows you the first questions your AI will come back with.

Then paste it into whatever AI you use, and have the conversation. It will start by asking you things only you can answer. Answer them properly — that's the whole exercise. You are not collecting a template; you are showing it your expertise.

Nothing you type here is sent anywhere. The prompt is assembled in your browser. There's no server behind this box, no analytics, and no third-party script on this page — and its security policy sets connect-src 'none' and form-action 'none', so the browser itself refuses to make a network request or submit a form. A tracker added here by mistake would fail rather than send quietly. Spellcheck is off on these fields too, since some browsers send what you type to their own servers. (Loading the page is logged by the web host, as on any site: address, time, browser. What you type into this box is not.) Check the response headers if you'd like.

Help me write the role for an AI advisor I'll use repeatedly. I want a
scoped role with a real stance, not a general assistant.

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
The advisor I need: [THE ADVISOR YOU NEED]

Work through it with me in this order — ask, don't assume:

1. THE LANE. Before drafting anything, ask me what decisions I actually want
   help with, and what I do NOT want this advisor touching. Push me to name
   at least two things that are out of scope. An advisor that can weigh in on
   everything weighs in on nothing.

2. THE CREDIBILITY. Ask me what experience would make me actually trust this
   advice, then write the role description to claim exactly that and nothing
   more.

3. THE FRAMEWORK. Ask which established framework this advisor should work
   through, and build it into the role as a required method rather than a
   suggestion. If I don't know, offer me the two or three that genuinely fit
   my situation and explain the difference — for example a lean canvas for a
   business model I haven't tested, jobs-to-be-done for understanding what
   people are actually hiring my product for, a Mom Test discipline for
   customer conversations so I stop collecting compliments, unit economics if
   the question is whether this can make money, or a RACI if the question is
   who decides what. Recommend one; don't just list them.

4. THE STANCE. Ask me whether I want this advisor to help me execute or to
   attack my thinking, and write the stance accordingly. Make it specific
   enough to change its behavior — "be honest" changes nothing.

5. THE SOURCES. Ask what documents it must read before every answer, and
   include the instruction to read my decision log every time.

6. THE LIMITS. Write the "you do not" list, including the point where I need
   a licensed professional in my field rather than an AI.

Then give me the finished role as one block I can paste in as a system prompt
or project instruction. After that, tell me the two questions I should ask it
first to find out whether it actually holds.

Help me write the decision-routing table for my own work — the explicit list
of what an AI may decide alone and what always comes back to me.

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
Who it affects if it goes wrong: [WHO IT'S FOR]
What going wrong looks like: [WHAT GOING WRONG LOOKS LIKE]

Work through this with me:

1. Start from the two lists below, then interrogate me about MY field. Ask
   what decisions in my domain carry consequences a non-expert would not
   see coming — the ones where a reasonable-looking choice is actually
   wrong for a reason you'd have to be in my field to know. Those go in the
   left column, and I want them named specifically, not as a category.

2. Ask me what's irreversible in my work, and what's merely expensive.
   Irreversible always routes to me. Expensive-but-reversible is a judgment
   call, and I want to make it deliberately rather than by accident.

3. Ask whether my field has decisions that are legally or professionally
   mine to make and cannot be delegated to any tool — a licensed sign-off, a
   clinical judgment, a regulatory determination, a fiduciary duty. Put those
   in a third category labeled "cannot be delegated at all, by anyone," and
   say why.

4. Challenge my right column. For each thing I said an AI can decide alone,
   ask what the worst realistic outcome is if it decides wrong and I don't
   notice for a month. If that answer is bad, move it left.

5. Give me the finished table as one block I can paste at the top of any AI
   session, plus one sentence I can say out loud to explain the boundary to
   someone else.

Do not populate my field's specifics from your own assumptions. Ask me.

I'm about to run a pre-build specification conversation using the structure
below, and I want you to tailor it to my field first.

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
Who it's for: [WHO IT'S FOR]
What going wrong looks like: [WHAT GOING WRONG LOOKS LIKE]

Do three things:

1. Rewrite section 3 ("what correct means") using the actual standard of
   correctness in my field. Name the specific standard, tolerance, regulation,
   professional guideline, or accepted practice that governs it — not a
   generic "meets requirements." If my field has more than one and they
   conflict, ask me which applies.

2. Rewrite section 4 ("how it fails") as a structured failure-mode analysis in
   the style of an FMEA: for each failure, the mode, the effect on the person
   downstream, roughly how likely, and whether it announces itself or fails
   silently. Prioritize by "bad AND silent," not by likelihood alone. Draw on
   the failure modes that actually occur in my field — ask me if you don't
   know them.

3. Add a section 0 that establishes context before we start, using the frame
   most standard in my field for a new effort. If you're not sure which fits,
   offer me two and let me choose — for example a lean canvas if this is a new
   business, a jobs-to-be-done statement if I'm replacing an existing
   workflow, or a user-needs-and-design-inputs list if this is a regulated or
   safety-relevant product.

Then ask me the questions one at a time. Do not answer them for me, do not
propose a solution, and do not write code. If I give you a vague answer, tell
me it's vague and ask again.

Help me build a corrections file for the AI mistakes that matter in my
domain, and set up the loop that keeps it working.

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
What going wrong looks like: [WHAT GOING WRONG LOOKS LIKE]

Step 1 — Predict the failures. Before I give you any examples, tell me the
five kinds of claims where an AI is most likely to be confidently wrong in my
specific field, and where a non-expert would not catch it. Be concrete: name
the actual concepts, units, standards, regulations, or rules of thumb that get
mangled. Then tell me, for each, what the wrong answer would cost if it
shipped.

Step 2 — Interview me. Ask me for corrections I've already had to make. For
each one, don't just record it — ask me WHY it was wrong, in the terms my
field uses, until the reasoning is written down well enough that someone
outside my field could apply the rule correctly to a new situation.

Step 3 — Write them in this format: name, one-line description, the rule,
**Why:** with the specific incident and cost, **How to apply:** concretely.
One rule per entry. Keep each under 120 words.

Step 4 — Set up the loop. Tell me exactly how to feed this file back into
every session I run, and give me a two-line summary I can paste at the top so
the AI knows what the file is. Then tell me which of my rules should skip the
file entirely and become an automatic check instead, and what that check would
be.

Do not invent corrections you think I probably have. Ask.

Help me design the documentation set for my project. I'll be feeding it to an
AI assistant as context on every session, so it has to be organized for a
reader who has no memory of yesterday.

My field: [YOUR FIELD]
What I'm building: [WHAT YOU'RE BUILDING]
Where I am now: [WHERE YOU ARE NOW]

Do this in four steps, and ask me questions rather than guessing:

1. Tell me which categories of knowledge a project like mine actually needs
   written down. Start from the seven-type taxonomy below, then add, merge, or
   drop types based on my field specifically. If my field has documents that
   are expected or required by convention, regulation, or a professional
   standard — a protocol, a design history file, a method statement, a care
   plan, a spec sheet, a runbook — name them explicitly and tell me where they
   fit. Do not add types just to be thorough; each one must earn its place.

2. For each type, tell me the ONE fact class that lives there and nowhere
   else. Then stress-test it: name the three facts in my project most likely
   to end up duplicated in two documents, and tell me which document should
   own each one.

3. Draft my one-page "rules of the product" document — what this is, who it's
   for, what must always be true, what must never happen, what we're
   deliberately not doing. Interview me for the content; do not invent the
   domain rules. Where I'm vague, push.

4. Give me the index: the read-first order, and one row per document I should
   eventually have, marked with which ones I need this week versus later.

Keep the whole set as small as it can be while still having one home for every
fact. I would rather have five documents I maintain than twenty I don't.

Where I can help

Deciding what to build is yours. You have the domain knowledge — that is the entire premise of everything above. What I know is the how: the workflow that lets one person with deep expertise ship something real with AI, without surrendering the judgment that made the idea worth building in the first place.

If you're building with AI and hitting a ceiling, I'd like to hear about it. Most of my hours go to Praxen right now, so I take on only a small number of engagements — but the right problem is always worth a conversation.

Vibe coding works. Then it stops.

If you're vibe coding right now, four rules

Talk it all the way through first

Make the plan outlive the chat

Harvest your corrections

Decide what it isn't allowed to decide

What the ceiling looked like for me

The system, one piece at a time

Build your version

What it will ask you first

Where I can help