Why AI keeps breaking my websites, and what I am changing
AI-written, human-reviewed
Two years of building with AI across four live sites. What a famous $80 million exit really required, why connectors and instruction files keep failing, and the verification rules I am putting around every AI session.
What did the Base44 founder have that most people building with AI do not?
Years of engineering and startup experience, a focused product, and real customers.
Maor Shlomo sold Base44 to Wix for $80 million in cash after about six months. TechCrunch reported that he was not truly solo: he had eight employees, who shared a $25 million retention bonus out of the $80 million. The company reportedly reached 250,000 users and was profitable. Shlomo was already an experienced developer and serial entrepreneur. He solved one clear problem, helping people build software without coding, and he shared the journey publicly. Prompts alone were not the asset. Judgment, a product and distribution were.
TLDR: The exit was a product with users and revenue built by an experienced founder, not a clever prompt.
Related: TechCrunch: Base44 sells to Wix for $80M cash · Forbes Israel: Base44 sold to Wix
Why do GitHub and Cloudflare connections fail so inconsistently?
Authorization is not orchestration. Access to a tool does not mean the assistant picked the right repo, branch or deploy target.
My stack has many separate parts: ChatGPT, Claude, Cursor, GitHub repos, Cloudflare Pages, D1 databases and MCP connectors. Each has its own permissions and state. My laptop, my coding assistant and a browser chat do not necessarily share the same files, session, credentials or tools. From my own experience, an assistant can use GitHub successfully and a few prompts later say it cannot see the connector. That is an observation of my setup, not a diagnosis of every setup. A platform that bundles hosting, database and auth reduces how many systems the AI has to keep in sync.
TLDR: More connected systems means more places for the assistant to lose track of reality.
What does "I can't access GitHub" actually mean?
It can mean four different things, and they need different fixes.
Tool unavailable: the current session does not expose the connector. Authentication failed: the connector exists but access was rejected. Operation failed: the connector worked but the action did not. Verification failed: the action may have run, but the result was not confirmed. Treating these as one problem leads to repeated re-authorization when the real issue is somewhere else. The first step is a read-only call that shows what the session can actually do.
TLDR: Separate unavailable, unauthorized, failed and unverified before changing anything.
Why does more documentation make the mess worse?
Instruction files describe a system; they do not enforce it, and assistants keep adding new ones.
When an assistant hits a problem, it often writes another script, inventory or handover file instead of finding the root cause. The next assistant reads all of them, and nobody knows which one is authoritative. Starting over with fresh clones helped me once, then the file sprawl came back, because the process creating it was unchanged. Documentation also cannot restore a missing connector or a lost permission. What helps is one authoritative instruction hierarchy, enforced by checks rather than by another prompt.
TLDR: One source of truth, enforced by checks, beats ten well-written instruction files.
Why can't an AI just look up the facts and never be wrong?
Language models predict likely text. A dictionary can tell them what code means, not whether your deploy worked.
A model turns language into tokens and predicts what is likely to come next. Likely and correct usually coincide, and sometimes they do not. Even with perfect documentation, the model cannot know the current state of your infrastructure: whether the credentials are valid, whether the build passed, whether the right branch is live. Those facts come from independent checks such as type checkers, linters, automated tests, required CI checks, deployment logs and a look at the live page. The model can propose work. It should not be the one deciding that the work succeeded.
TLDR: AI can help build things. It cannot certify its own correctness.
What am I changing in practice?
A read-only audit first, one change at a time, and proof instead of reassurance.
First, record the real repositories, production branches, Cloudflare projects and last good deployments directly from GitHub and Cloudflare, not from an assistant's memory. Second, one change at a time on a branch with a stated purpose, and no new skills, architecture files or workflows without approval. Third, a task is done only when the commit exists, the correct deployment succeeded and the live page behaves as intended. If a tool becomes unavailable, the assistant stops and reports instead of inventing a workaround. The goal is not an autonomous AI. It is one that is predictable, auditable and unable to quietly change the architecture when something fails.
TLDR: Make the AI predictable and auditable. Do not rebuild everything.
Related: Does anyone really understand how large language models work? · Daniel's Corner home
TLDR: Two years of building with AI across four live sites. What a famous $80 million exit really required, why connectors and instruction files keep failing, and the verification rules I am putting around every AI session.