Guides to building with AI

What these are

Each guide covers one idea and then shows it running. The pages about markets read a live perpetual market as they load, so the figures in them came from an exchange rather than from an author, and the pages about tooling link to a template you can fork and have running in a browser tab within a minute. Nothing here is a description of a product feature waiting for you to sign up before you can see it.

How to use the list

The four groups below run from the general to the specific. If you have not built anything yet, start in Building with AI. If you are already using an agent and want to know why it forgets things halfway through a task, Code, agents and tools has the answer. Compared with other builders is the honest version of where we differ from Lovable, Cursor and Bolt, which is narrower than a marketing page would claim. Markets and trading assumes no finance background and defines its terms.

Building with AI

• Vibe coding, with something real underneathVibe coding means describing an app instead of writing it; the difference between a demo and a working result is whether the generated code can reach something real, like a live market, that will contradict it when it is wrong.
• An AI app builder where the app has to workAn AI app builder turns a description into a running app; the ones that produce working software rather than convincing mockups are the ones whose generated code can read a real data source at runtime.
• An app builder for apps that answer questionsMost app builders assemble interfaces well, and assembly is no longer the hard part; what remains hard is reaching something real, handling it being slow or wrong, and saying so honestly on screen.
• An AI app generator, and what it costs to skip the boring partsAn AI app generator will produce a running app from a description in minutes, and the parts it tends to skip are error handling, staleness and what to show when a data source is unreachable, which are precisely the parts that decide whether the app is still working in a month.
• Build an app with AI, and the part everyone skipsBuilding an app with AI has an easy first hour and a hard second day: the demo runs on data invented to make it render, and connecting it to something real is where the actual work begins.
• No code, until the data gets hardNo-code app builders handle forms, tables and workflows well because that data is yours and sits still; they strain when the data lives outside your system and changes while you look at it.
• An AI website builder, and when you need more than a websiteAn AI website builder is the right tool whenever your content is stable; the moment a page has to show a price, a rate or a balance that changes, it has become an app and needs a live data source rather than a nicer layout.
• Build a website with AI, and know when you have outgrown oneAI website builders are the right tool whenever the content is written once and stays true; the moment a page has to show something that changes while a visitor is reading it, it has stopped being a website and needs a live data source rather than a better layout.
• Choosing AI tools by how fast you find out they were wrongThe most useful question when choosing an AI tool is not what it can do but how quickly you would find out it had done something wrong, because tools whose output is checkable in seconds compound in your favour and tools whose mistakes surface days later compound against you.

Code, agents and tools

• An AI code generator you can checkGenerating code is close to solved and checking it is not; pointing generated code at a live market turns correctness from a matter of judgement into something the data contradicts within seconds when it is wrong.
• An AI coding assistant that can check its own workAn AI coding assistant writes code faster than you can type it, but cannot tell you whether the reasonable-looking version is correct, because nothing in the loop ran it against anything that would object.
• A coding agent, and the difference from an autocompleteThe difference between a coding agent and an autocomplete is that an agent acts and then observes, so its usefulness depends almost entirely on whether the things it can observe actually tell it the truth about what it did.
• AI agents, and the question that decides whether one is usefulAn AI agent is a model, a loop and a set of tools, and since the first two are close to identical everywhere, what an agent can actually do is decided almost entirely by what its tools can reach and how honestly those tools report failure.
• An AI agent builder, and the part that decides whether it worksAn AI agent is only as capable as the tools you give it, so the hard part of building one is not the prompt or the loop but deciding what it can actually reach and what happens when a tool answers slowly, wrongly, or not at all.
• An MCP server, and what makes one worth connectingThe hard part of an MCP server is not the protocol, which is well specified and quick to implement, but the design of the tools themselves: what they are named, what they return, and above all what they say when they fail, because a model that receives an unhelpful error will retry and then invent.
• Model Context Protocol, explained without the diagramModel Context Protocol is a standard interface between a model and a set of tools, so that any client speaking it can use any server exposing them; it solves the wiring and deliberately leaves the hard questions of naming, scope and failure reporting to whoever writes the server.
• Prompt engineering, and the part that is really specificationMost prompt engineering is not a set of tricks but the ordinary work of specifying a problem precisely, which is why the techniques keep expiring while the skill of stating clearly what you want, what you have, and how the result will be judged keeps working.
• The context window, and why bigger is not simply betterA larger context window removes the constraint of not fitting and introduces the constraint of relevance, because a model given a great deal of loosely related material attends less well to the part that mattered, so what you include matters more than how much you could.
• AI automation tools, and the difference between a task and a decisionAI automation is reliable on tasks whose result can be checked immediately and unreliable on decisions whose consequences arrive later, so the useful line is not how hard the work is but how quickly you would notice it being done wrong.

Compared with other builders

• A Lovable alternative for apps that need live dataLovable is a strong AI app builder for product interfaces; the case for an alternative is narrow and specific, and it is whether the app you are describing has to read a live financial market.
• A Cursor alternative when you do not want to open an editorCursor is an AI code editor and assumes you have a project open; a builder assumes you want a running app and will read the code if you need to, which suits a different moment rather than a different skill level.
• A Bolt alternative for apps that read a live marketBolt and this are both prompt-to-running-app builders, and the narrow case where they differ is whether the app has to be correct about a live market, because a generated dashboard is only as honest as the data source behind it and a model with nothing real to read will produce convincing invented numbers instead.

Markets and trading

• Crypto arbitrage, and why most of it is already goneMost crypto arbitrage is closed by bots before a person can act, so the useful question is not where the gaps are but why a visible gap has survived: halted withdrawals, congestion, a book too thin to fill, or fees that exceed the edge.
• A trading dashboard is only as good as its refreshA trading dashboard showing a price from four minutes ago looks identical to one showing a price from four seconds ago, so the thing that makes one useful is not its layout but whether it states when each number was read.
• A financial dashboard, and the three numbers most of them get wrongThe hard part of a financial dashboard is not the layout but deciding what each figure means, how old it is allowed to be, and what to show when the source is unreachable, because a stale number and a current one are visually identical and only one of them is safe to act on.
• What is a perpetual futureA perpetual future is a futures contract with no expiry, held close to the spot price by a funding payment between longs and shorts, which makes funding a cost of time rather than a fee on trading.
• A crypto trading bot is mostly risk codeMost of the code in a working crypto trading bot is not the strategy, it is position sizing, failure handling and the conditions under which it stops trading, because a strategy that is right most of the time can still lose everything on the occasion it is not.
• A crypto portfolio tracker, and the number most of them get wrongMost crypto portfolio trackers value a holding at the last traded price, which is the number you could sell one unit at rather than the number you could sell your position at, and the gap between those two is largest exactly when it matters most.
• AI for trading, and the distinction that matters mostAI is genuinely useful for building trading tools, dashboards, scanners, monitors and alerts, and is not reliably useful for predicting prices; the distinction matters because the first is checkable within seconds and the second cannot be evaluated until it is too late.
• Algorithmic trading, and where the difficulty actually sitsIn algorithmic trading the strategy is usually the shortest part of the code, and the difficulty sits in execution, position sizing and the conditions under which the system stops, because a strategy that is right most of the time can still lose everything on the occasion it is not.
• Backtesting, and the four ways it lies to youA good-looking backtest is the default rather than a discovery, because four errors reliably produce one: look-ahead bias, survivorship bias, overfitting, and ignoring costs, and a result that has not been checked against all four says almost nothing about the future.
• Web3 development, and the part that is just distributed systemsMost web3 development is ordinary engineering, and the genuinely different parts are three constraints: state changes are slow and can fail after you thought they succeeded, everything you write is public and permanent, and there is no support line when a user loses access.