Choose a Familiar Stack
Ask an assistant to "build Kitty" without saying how, and it will choose a language, a framework and a database for you. It might pick well. It might also pick three separate services you have never heard of, or quietly switch libraries halfway through the project. Your stack, the set of languages and tools the app is built with, is a decision to make on purpose.
The rule
Choose well-known tools you can read, and name them in your prompts.
Each part of that rule protects you:
- Well-known. Assistants learn from large amounts of public code, so they tend to be more reliable with widely used languages and libraries than with obscure or brand-new ones. Popular tools also have more documentation, which you need to check the assistant's work.
- You can read. If the code is in a language you cannot read, you cannot judge it, and judging is your whole job. Kitty uses Python because you can read Python, not because it is fashionable.
- Few moving parts. Every extra service is one more thing to set up, secure and debug. Start with the fewest parts that meet the spec, and add more only when a real need appears.
- Named. Write the stack down and repeat it in prompts or project notes, so the assistant does not pick a different tool halfway through.
Kitty's stack note is short:
## Stack (Kitty)
- Python, with one small web framework and server-rendered HTML pages
- SQLite database, through Python's built-in sqlite3 module
- Money stored as whole paise (integers), never as floats
- Plain HTML forms, no JavaScript frameworkThat money rule is part of the stack too. Binary floating-point numbers cannot represent most decimal amounts exactly: in Python, 0.1 + 0.2 gives 0.30000000000000004. Whole paise add up exactly.
The shortcut
For any tool you or the assistant want to add, ask three questions: Can I read it? Is it widely used and documented? Does the spec need it? Three yeses, or it stays out.
Can I read it?
Partly. You understand the idea, but you would struggle to debug its configuration.
The trap is "production-ready" thinking: adding what big companies use before you have their problems. Big-company tools solve big-company problems and bring big-company complexity.
Drills
Answer fast — trust the rule.
Why do assistants tend to be more reliable with widely used languages and libraries?
You cannot read JavaScript well. The assistant suggests rewriting Kitty's pages in a JavaScript framework. Best response?
Why write the stack into your prompts or project notes?
Kitty stores money as whole paise. What is the reason?
Remember
- Rule: choose well-known tools you can read, and name them in your prompts.
- Shortcut: can I read it, is it well known, does the spec need it? Three yeses or it stays out.
- Trap: adding "production-ready" parts before you have the problems they solve.