{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/en/autor/alexander-bock/"},"categories":["AI Development"],"content":{"markdown":"Say you want an assistant that answers your colleagues' questions about travel expenses. You could put it together on a platform by clicking, without a single line of code. You could use the same kind of platform and add a few lines of code where it falls short. Or a developer could write it as ordinary software. All three can lead to a working assistant. They differ in how fast you start, how much you decide yourself and how hard it is to change course later.\n\nThis is part 4 of Level 0 in our AI Development learning path. [Part 1](/en/ai-development/learn/what-is-ai-development/) described three ways to do AI development. Here we look closer at the most common one: building a product on top of a finished model. You will learn what no-code, low-code and code mean and how they compare on five criteria. You will also see what to build with each and when it is time to switch.\n\n## Three approaches, one example\n\nLet's stay with the travel assistant. It should answer questions such as \"Can I take a taxi to the airport?\" from your company's travel policy. Here is what building it looks like in each approach.\n\n**No-code** means you build in a visual editor: you click, fill in forms and write instructions in plain language. You never touch program code. For the assistant, you upload the travel policy and write an instruction such as \"Answer only from the policy.\" Then you pick a model from a list and test the result in a preview. The platform runs the app for you.\n\n**Low-code** also starts in a visual editor. Where the ready-made building blocks end, you add small pieces of code. Your assistant could, for example, use a short script to fetch the current expense limits from your finance system. In most cases, the platform still runs the app.\n\nWith **code**, a developer writes the assistant as normal software, for example in Python or JavaScript. The program sends each question to the model, together with the matching parts of the policy. It does this through the model's **API**, the interface that lets programs talk to it. The developer decides where the app runs, which model it uses and what it records.\n\n![Three app windows side by side: a no-code editor with fields for instructions, files and model; a low-code workflow with one code step between ready-made blocks; a code editor](/images/learn/en/no-code-low-code-or-code-ways.webp \"One assistant, three approaches: the further right, the more you build and run yourself.\")\n\n{{\u003c callout type=\"term\" title=\"AI app builder\" \u003e}}\nA newer kind of tool sits between the approaches. You describe the app in a chat, and the builder writes the code for you. According to the vendors, Emergent builds web and mobile apps from a plain-language description. Devs.ai lets companies build apps and agents on their own data. You start without code, but you end up with code — and someone has to read, test and maintain it.\n{{\u003c /callout \u003e}}\n\nWorking this way is often called *vibe coding*. Our article [VibeCoding: How We Deploy Experiments Faster](/en/ai-development/vibecoding-faster-experiments-ai-development/) shows where it helps us and where we stop.\n\n## Five criteria for choosing\n\nNo approach is the best in general. The right one depends on what you build, who builds it and how long it has to last. Five criteria make the choice clearer:\n\n- **Speed:** how quickly you have a first working version.\n- **Control:** how much you decide yourself, from the interface to the model and where your data goes.\n- **Cost of change:** how much effort a change takes later, such as a new data source or a different model.\n- **Scaling:** what happens when ten or a hundred times more people use the app.\n- **Lock-in:** how hard it is to leave a platform. Experts speak of **vendor lock-in** when leaving would cost so much that you stay.\n\nThe table shows typical tendencies. Individual platforms differ.\n\n| Criterion | No-code | Low-code | Code |\n|---|---|---|---|\n| Speed | Fastest start, nothing to set up | Fast; code steps add some time | Slowest start: setup, hosting, tests |\n| Control | Only what the platform offers | More: code fills the gaps | Full: you decide every detail |\n| Cost of change | Low within the platform's limits, high beyond them | Medium; code steps need someone who can code | Each change needs a developer, but nothing blocks you |\n| Scaling | The platform's limits and pricing set the frame | Like no-code, plus your own services | You plan it yourself: servers, model choice, cost control |\n| Lock-in | High: the app only exists on the platform | Medium to high | Low for your code; changing the model provider still takes work |\n\nSpeed and control pull in opposite directions. The figure places the three approaches on both axes.\n\n![Two-by-two grid with control on the horizontal axis and speed to the first version on the vertical axis: no-code sits in the fast but limited corner, code in the full-control corner, low-code in between; the slow and limited corner is marked as a trap](/images/learn/en/no-code-low-code-or-code-speed-control.webp \"Speed against control: each approach gains one by giving up some of the other. The placement is a rough guide, not a measurement.\")\n\nOne corner deserves a warning: slow and limited at the same time. You end up there when you force a platform to do something it was not built for. Each workaround makes the app harder to understand, and every change takes longer than it would in code.\n\n## Who provides which part of the app\n\n[Part 2 of this level](/en/ai-development/learn/how-an-ai-app-works/) explains the seven parts an AI app is made of. The three approaches differ in who provides each of them.\n\n![Matrix with the seven parts of an AI app as rows and no-code, low-code and code as columns; each cell shows whether the platform provides the part, you build it from the platform's parts, or you build it yourself](/images/learn/en/no-code-low-code-or-code-parts.webp \"Who provides which part: from no-code to code, more of the app moves into your hands. Instructions and data are yours in every approach.\")\n\nTwo rows look the same in every approach: you write the instructions, and you bring the data, such as the travel policy. Together with your test questions, they hold most of what you learned about the task. You can take them with you. The interface and the steps in the backend are different: on a platform, they exist only in its format. They are what you rebuild when you leave.\n\n{{\u003c callout type=\"tip\" title=\"Keep a portable kit\" \u003e}}\nFrom day one, keep four things in a shared folder outside the platform:\n\n- your instructions,\n- your source documents,\n- test questions with good answers,\n- a short description of each workflow step.\n\nBefore you start, also check whether the platform can export your work. If you switch later, the kit carries most of your effort with you.\n{{\u003c /callout \u003e}}\n\n## What to build with each approach\n\nMost projects fit one approach better than the others. These examples show typical starting points:\n\n| Project | Start with | Why |\n|---|---|---|\n| Assistant that answers staff questions from a handbook | No-code | Chat over your documents is a common feature of no-code platforms |\n| Helper that drafts product texts from a short form | No-code | Simple input, simple output, a small team |\n| Sorting incoming emails and creating tickets | Low-code or an automation platform | Needs connections to your email and ticket systems |\n| Support bot that checks the order status in your shop | Low-code | A short code step that asks your shop system fills the gap |\n| AI search inside your own app or website | Code | Must fit your product and stay fast for many users |\n| Feature with strict data rules, for example data that must stay on your servers | Code | You control hosting, logs and the choice of model |\n\nOur [tool comparison](/en/ai-development/#area-app-builders) lists {{\u003c stat \"area\" \"app-builders\" \u003e}} tools for app building and testing and {{\u003c stat \"area\" \"agents-automation\" \u003e}} for agents and automation. Five of them show the range. According to the vendors, MindStudio is a no-code platform for building your own AI agents. Turbotic builds automations from a description in natural language. Emergent and Devs.ai are AI app builders. Dry Ground AI is part consultancy, part product: here you work with a team instead of building alone. We have not tested these tools.\n\n{{\u003c tools \"mindstudio turbotic emergent devs-ai dry-ground-ai\" \u003e}}\n\nHiring a team is a fourth route when a project needs code but nobody on your side writes it. Ask the same questions as for the other approaches, and one more: who owns and changes the app once the project ends?\n\n## When to switch\n\nMany projects move through the approaches as they grow. A no-code prototype shows whether people use the idea at all. A pilot connects it to your systems. An app for many users with strict rules often ends up as code.\n\n![Three steps rising from left to right: test the idea with no-code, run a pilot with low-code, build the product with code; signals between the steps show when to move on](/images/learn/en/no-code-low-code-or-code-path.webp \"One common path, not a rule: start without code and add code where the platform ends.\")\n\nThese signals tell you that it is time to move toward code:\n\n- **The platform cannot do what you need.** A data source, a model or a part of the interface is missing, and the workarounds pile up.\n- **Costs grow faster than the value.** Platforms bill in different ways, for example per user or per run. Check what happens to the bill when use doubles.\n- **Data rules get stricter.** Your security team may need data to stay in one region, or it may need detailed logs and access rights.\n- **Several people change the app.** You need a history of every change, reviews and automatic tests before a change goes live. Code tools are built for this.\n- **The app becomes critical.** If an outage stops work for many people, you need monitoring and a plan B.\n\nSwitching works in the other direction too. If a developer spends hours on small wording changes that a colleague could make, the instructions may be better off in a no-code tool. And many internal helpers never need to leave the platform at all.\n\nLevel 1 shows both ends in practice: [build a simple AI app without code](/en/ai-development/learn/build-a-simple-ai-app-without-code/) and make [your first LLM API call](/en/ai-development/learn/your-first-llm-api-call/).\n\n## Common mistakes when choosing\n\n- **Choosing by habit.** Developers tend to write code for everything. Business teams tend to push a platform too far. Start from the task and the five criteria instead.\n- **Building the full product first.** A rough prototype with real users answers the most important question early: does anyone need this?\n- **Forgetting running costs.** Model providers usually bill per **token**, a small piece of text, and platforms add their own fees. Estimate the costs for ten times today's use before a wide rollout.\n- **Treating generated code as finished.** Code from an AI app builder still needs someone who reads it, tests it and checks it for security gaps.\n- **Leaving a prototype without an owner.** Once a helper becomes important, someone must keep its documents current and react when it fails.\n\n{{\u003c callout type=\"try\" \u003e}}\nPick one AI idea from your work and answer five questions:\n\n1. How soon do you need a first version?\n2. What must you control: the data, the model, the interface?\n3. How often will the app change, and who will make the changes?\n4. How many people will use it a year from now?\n5. How bad would it be to depend on one platform?\n\nChoose a starting approach. Then write down one signal that would make you switch.\n{{\u003c /callout \u003e}}","text":"Say you want an assistant that answers your colleagues\u0026rsquo; questions about travel expenses. You could put it together on a platform by clicking, without a single line of code. You could use the same kind of platform and add a few lines of code where it falls short. Or a developer could write it as ordinary software. All three can lead to a working assistant. They differ in how fast you start, how much you decide yourself and how hard it is to change course later.\nThis is part 4 of Level 0 in our AI Development learning path. Part 1 described three ways to do AI development. Here we look closer at the most common one: building a product on top of a finished model. You will learn what no-code, low-code and code mean and how they compare on five criteria. You will also see what to build with each and when it is time to switch.\nThree approaches, one example Let\u0026rsquo;s stay with the travel assistant. It should answer questions such as \u0026ldquo;Can I take a taxi to the airport?\u0026rdquo; from your company\u0026rsquo;s travel policy. Here is what building it looks like in each approach.\nNo-code means you build in a visual editor: you click, fill in forms and write instructions in plain language. You never touch program code. For the assistant, you upload the travel policy and write an instruction such as \u0026ldquo;Answer only from the policy.\u0026rdquo; Then you pick a model from a list and test the result in a preview. The platform runs the app for you.\nLow-code also starts in a visual editor. Where the ready-made building blocks end, you add small pieces of code. Your assistant could, for example, use a short script to fetch the current expense limits from your finance system. In most cases, the platform still runs the app.\nWith code, a developer writes the assistant as normal software, for example in Python or JavaScript. The program sends each question to the model, together with the matching parts of the policy. It does this through the model\u0026rsquo;s API, the interface that lets programs talk to it. The developer decides where the app runs, which model it uses and what it records.\nOne assistant, three approaches: the further right, the more you build and run yourself. §AI app builder\nA newer kind of tool sits between the approaches. You describe the app in a chat, and the builder writes the code for you. According to the vendors, Emergent builds web and mobile apps from a plain-language description. Devs.ai lets companies build apps and agents on their own data. You start without code, but you end up with code — and someone has to read, test and maintain it.\nWorking this way is often called vibe coding. Our article VibeCoding: How We Deploy Experiments Faster shows where it helps us and where we stop.\nFive criteria for choosing No approach is the best in general. The right one depends on what you build, who builds it and how long it has to last. Five criteria make the choice clearer:\nSpeed: how quickly you have a first working version. Control: how much you decide yourself, from the interface to the model and where your data goes. Cost of change: how much effort a change takes later, such as a new data source or a different model. Scaling: what happens when ten or a hundred times more people use the app. Lock-in: how hard it is to leave a platform. Experts speak of vendor lock-in when leaving would cost so much that you stay. The table shows typical tendencies. Individual platforms differ.\nNo-Code, Low-Code or Code: Three Ways to Build with AI Criterion No-code Low-code Code Speed Fastest start, nothing to set up Fast; code steps add some time Slowest start: setup, hosting, tests Control Only what the platform offers More: code fills the gaps Full: you decide every detail Cost of change Low within the platform\u0026rsquo;s limits, high beyond them Medium; code steps need someone who can code Each change needs a developer, but nothing blocks you Scaling The platform\u0026rsquo;s limits and pricing set the frame Like no-code, plus your own services You plan it yourself: servers, model choice, cost control Lock-in High: the app only exists on the platform Medium to high Low for your code; changing the model provider still takes work Speed and control pull in opposite directions. The figure places the three approaches on both axes.\nSpeed against control: each approach gains one by giving up some of the other. The placement is a rough guide, not a measurement. One corner deserves a warning: slow and limited at the same time. You end up there when you force a platform to do something it was not built for. Each workaround makes the app harder to understand, and every change takes longer than it would in code.\nWho provides which part of the app Part 2 of this level explains the seven parts an AI app is made of. The three approaches differ in who provides each of them.\nWho provides which part: from no-code to code, more of the app moves into your hands. Instructions and data are yours in every approach. Two rows look the same in every approach: you write the instructions, and you bring the data, such as the travel policy. Together with your test questions, they hold most of what you learned about the task. You can take them with you. The interface and the steps in the backend are different: on a platform, they exist only in its format. They are what you rebuild when you leave.\n✦Keep a portable kit\nFrom day one, keep four things in a shared folder outside the platform:\nyour instructions, your source documents, test questions with good answers, a short description of each workflow step. Before you start, also check whether the platform can export your work. If you switch later, the kit carries most of your effort with you.\nWhat to build with each approach Most projects fit one approach better than the others. These examples show typical starting points:\nNo-Code, Low-Code or Code: Three Ways to Build with AI (2) Project Start with Why Assistant that answers staff questions from a handbook No-code Chat over your documents is a common feature of no-code platforms Helper that drafts product texts from a short form No-code Simple input, simple output, a small team Sorting incoming emails and creating tickets Low-code or an automation platform Needs connections to your email and ticket systems Support bot that checks the order status in your shop Low-code A short code step that asks your shop system fills the gap AI search inside your own app or website Code Must fit your product and stay fast for many users Feature with strict data rules, for example data that must stay on your servers Code You control hosting, logs and the choice of model Our tool comparison lists 5 tools for app building and testing and 3 for agents and automation. Five of them show the range. According to the vendors, MindStudio is a no-code platform for building your own AI agents. Turbotic builds automations from a description in natural language. Emergent and Devs.ai are AI app builders. Dry Ground AI is part consultancy, part product: here you work with a team instead of building alone. We have not tested these tools.\nMindStudioAgents \u0026amp; Automation · AI at the coreNo-code platform for building your own AI agents. TurboticAgents \u0026amp; Automation · AI at the coreBuilds automations from a natural-language description, without code. EmergentApp Building \u0026amp; Testing · AI at the coreBuilds web and mobile apps from a plain-language description. Devs.aiApp Building \u0026amp; Testing · AI at the corePlatform where teams build and run AI applications and custom agents on their own data. Dry Ground AIApp Building \u0026amp; Testing · AI at the coreAI operator (CompanyClaw) that learns how a company works and handles routine work through connected tools. Short descriptions from our tool comparison, based on the vendors' information — not tested by ABXK.\nHiring a team is a fourth route when a project needs code but nobody on your side writes it. Ask the same questions as for the other approaches, and one more: who owns and changes the app once the project ends?\nWhen to switch Many projects move through the approaches as they grow. A no-code prototype shows whether people use the idea at all. A pilot connects it to your systems. An app for many users with strict rules often ends up as code.\nOne common path, not a rule: start without code and add code where the platform ends. These signals tell you that it is time to move toward code:\nThe platform cannot do what you need. A data source, a model or a part of the interface is missing, and the workarounds pile up. Costs grow faster than the value. Platforms bill in different ways, for example per user or per run. Check what happens to the bill when use doubles. Data rules get stricter. Your security team may need data to stay in one region, or it may need detailed logs and access rights. Several people change the app. You need a history of every change, reviews and automatic tests before a change goes live. Code tools are built for this. The app becomes critical. If an outage stops work for many people, you need monitoring and a plan B. Switching works in the other direction too. If a developer spends hours on small wording changes that a colleague could make, the instructions may be better off in a no-code tool. And many internal helpers never need to leave the platform at all.\nLevel 1 shows both ends in practice: build a simple AI app without code and make your first LLM API call.\nCommon mistakes when choosing Choosing by habit. Developers tend to write code for everything. Business teams tend to push a platform too far. Start from the task and the five criteria instead. Building the full product first. A rough prototype with real users answers the most important question early: does anyone need this? Forgetting running costs. Model providers usually bill per token, a small piece of text, and platforms add their own fees. Estimate the costs for ten times today\u0026rsquo;s use before a wide rollout. Treating generated code as finished. Code from an AI app builder still needs someone who reads it, tests it and checks it for security gaps. Leaving a prototype without an owner. Once a helper becomes important, someone must keep its documents current and react when it fails. ▸Try it\nPick one AI idea from your work and answer five questions:\nHow soon do you need a first version? What must you control: the data, the model, the interface? How often will the app change, and who will make the changes? How many people will use it a year from now? How bad would it be to depend on one platform? Choose a starting approach. Then write down one signal that would make you switch.\n","words":1857},"date":"2026-10-14","description":"Compare no-code, low-code and code for building AI apps: speed, control, cost of change, scaling and lock-in, with examples and clear signals for when to switch.","image":"https://abxk.ai/images/cover/no-code-low-code-or-code.webp","json":"https://abxk.ai/en/ai-development/learn/no-code-low-code-or-code/index.json","kind":"page","language":"en","learning_path":{"category":"ai-development","level":0,"level_name":"Start here"},"modified":"2026-10-14","related_tools":["MindStudio","Turbotic","Emergent","Devs.ai","Dry Ground AI"],"section":"ai-development","seo_title":"No-Code, Low-Code or Code: How to Build with AI","tags":["no-code","low-code","ai-apps","vendor-lock-in","beginner"],"title":"No-Code, Low-Code or Code: Three Ways to Build with AI","translations":[{"json":"https://abxk.ai/de/ai-development/learn/no-code-low-code-or-code/index.json","language":"de","url":"https://abxk.ai/de/ai-development/learn/no-code-low-code-or-code/"}],"url":"https://abxk.ai/en/ai-development/learn/no-code-low-code-or-code/"}