VITON13School

Generative AI for BeginnersLesson 11 of 21

Low-code AI apps and automations

Not every AI feature needs a Python project. Visual app builders and workflow tools can call a model, read a spreadsheet and send an email with no code at all. Knowing where they shine, and where they stop, saves you weeks.

Course by , Founder of VITON13 SCHOOL
  • Part 2: Build
  • 35 min

You will be able to

  • Name the main kinds of low-code and no-code tools and what each is for
  • Describe the trigger, steps and actions that make up an automation
  • Call an OpenAI-compatible model from a generic HTTP step in any workflow tool
  • Judge when a low-code tool is enough and when custom code is the better choice

What low-code means today

Low-code tools let you build software by arranging blocks, filling in forms and writing the occasional formula instead of full programs. No-code tools go further and hide even the formulas. The line between them is blurry, and most products offer a little of both.

Three families matter for AI work. App builders give you screens, forms and a simple database, so you can make an internal tool in an afternoon. Workflow automation tools connect services: when something happens in one place, they run a chain of steps across others. Assistant or agent builders let you describe a helper, attach documents and a few actions, and publish it as a chat window.

Large software vendors bundle their own versions with office suites and cloud platforms, and independent tools such as Zapier, Make and n8n focus on connecting many different services. The concepts in this lesson apply to all of them, so pick whichever one your school, company or budget already allows.

Many of these tools now include an assistant that builds for you. You describe the app or flow in plain words, and it suggests tables, screens or steps. Treat that draft like code from a new colleague: useful as a start, but read every step before you switch it on.

How an automation is put together

Almost every workflow tool uses the same vocabulary. A trigger starts the flow, steps transform data, and actions change something in the outside world. Data from earlier steps can be inserted into later ones, usually by picking fields from a list or typing a placeholder.

AI fits in as one more step. Some tools have a ready-made block for a specific provider; most also have a generic HTTP request step. Because many providers share the OpenAI-compatible format, one HTTP step that posts JSON to LLM_BASE_URL plus /chat/completions, with your key in an Authorization header, works with any of them.

Keep the AI step narrow. Ask for one job, such as a summary, a category or a quiz question, and ask for a fixed output format so the next step can read it. A flow where the model returns free text and a later step guesses where the answer starts will break on the first unusual reply.

  • Trigger: a new form answer, a new row in a sheet, an incoming email, a schedule
  • Transform: clean the text, pick fields, cut it to a sensible length
  • AI step: one prompt with a clear output format
  • Check: confirm the reply parses and has the fields you expect
  • Action: write the result back, send a message or create a task
  • Fallback: on any error, notify a person instead of failing silently

When low-code is enough

Low-code tools are a great fit when the work is a straight line of familiar steps, the volume is modest, and the people who own the process are not programmers. Turning form answers into a tidy summary, sorting incoming messages into categories or drafting replies for a human to approve are typical wins.

They also make prototypes cheap. Before you spend a week coding a feature, a two-hour flow can show whether anyone actually uses it. If the prototype proves its value, you can rebuild it in code later with a much clearer specification.

Ownership is another advantage. A teacher or office manager can open the flow, see each step and fix a wording problem without waiting for a developer. That transparency is worth a lot for small teams.

When to switch to code

Visual tools become painful once logic branches in many directions, loops over large lists or needs careful error handling. A flow with forty blocks and nested conditions is harder to read than the thirty lines of Python that would replace it, and you cannot easily test it.

Cost and limits change at scale. Many platforms charge per task or per step, so a flow that runs thousands of times a day can cost more than a small server. Rate limits, timeouts and missing features in a connector can block you with no workaround.

Data and security deserve a sober look. Every connector you add passes data through another company, often with broad permissions on your accounts. Check where the data is stored, who can see the run history, and whether you are allowed to send personal or school data to that service at all.

Version control and testing are the last big gap. Code lives in git, gets reviewed and can be tested automatically before release. Some tools now offer exports, versions or self-hosting, which helps; if yours does not, a careless edit can break a working flow with no easy way back.

Before you switch a flow on

A flow that runs on its own deserves the same care as code you deploy. Test it with a handful of realistic inputs, including an empty one, a very long one and one in another language, and read every output yourself.

Decide what a person must approve. Drafting a reply is low risk; sending it to a parent or a customer without review is not. Many tools let you insert an approval step that waits for a click, and for anything that leaves your organisation it is the right default.

Write a short note next to the flow that says what it does, who owns it and what to do if it fails. Six months later that note is often the only documentation anyone has.

  • Run it on test data before it touches real records
  • Store keys in the tool's credential store, never in step text
  • Set a spending or run limit if the platform offers one
  • Make failures visible with a message to a named person

Example

The HTTP body of an AI step that writes a quiz question

{
  "model": "{{LLM_MODEL}}",
  "messages": [
    {
      "role": "system",
      "content": "You write one multiple-choice question that checks understanding of a study note. Reply with JSON only, in this shape: {\"question\": \"...\", \"options\": [\"...\", \"...\", \"...\", \"...\"], \"answer\": 0}. The answer is the 0-based index of the correct option."
    },
    {
      "role": "user",
      "content": "Study note: {{row.note}}"
    }
  ]
}

Paste this as the JSON body of a POST request to your LLM_BASE_URL followed by /chat/completions, with the header Authorization: Bearer and your key. The double-brace placeholders stand for your tool's own way of inserting the model name and the note from the trigger, so replace them with what your tool uses.

Practice

Build a no-code quiz generator for Study Buddy

  1. Create a spreadsheet with two columns, note and question, and add five study notes from your notes.txt.
  2. In any workflow tool you can use, create a flow triggered by a new or updated row in that sheet.
  3. Add an HTTP request step with the body from the example, the right URL, and your key stored in the tool's secret or credential field rather than typed into the body.
  4. Add a step that parses the reply as JSON and writes the question and the four options into the question column.
  5. Add an error branch that writes the word CHECK into the row when the reply does not parse, then add a sixth note to trigger the flow.

Done when: Adding a new note to the sheet fills its question column within a minute with a readable four-option question, and a deliberately broken prompt produces CHECK instead of a silent failure.

Common mistakes

  • Pasting the API key directly into a step's body where anyone with access to the flow can read it.
  • Letting the AI step return free text and hoping later steps can find the right part of it.
  • Switching on an assistant-generated flow without reading every step it created.
  • Keeping a flow in a visual tool long after it has grown into dozens of branches that nobody can test.

Check yourself

Pick an answer to see whether it is right and why.

Which part of an automation decides when it starts?

Right.A trigger is the event, such as a new row or an incoming email, that starts the flow; the other steps run after it.

Not quite.The right answer is “The trigger”. A trigger is the event, such as a new row or an incoming email, that starts the flow; the other steps run after it.

Why is a generic HTTP step often enough to use many different model providers?

Right.Because the request shape is shared, you can switch providers by changing the URL, the key and the model name.

Not quite.The right answer is “Many providers accept the same OpenAI-compatible request format”. Because the request shape is shared, you can switch providers by changing the URL, the key and the model name.

A flow now has many nested conditions, runs thousands of times a day and keeps breaking after edits. What is the sensible next move?

Right.Complex branching, high volume and fragile edits are the classic signs that code with tests and history will be cheaper and safer.

Not quite.The right answer is “Rebuild it as tested code under version control”. Complex branching, high volume and fragile edits are the classic signs that code with tests and history will be cheaper and safer.

From the founder

Build the quiz flow in a tool you can use for free before you decide that low-code is too simple or too limited. Then write down the first thing that annoyed you; that is usually the exact point where code starts to pay off.
Vitalii Tarasov, Founder of VITON13 SCHOOL

Course by Vitalii Tarasov, VITON13 SCHOOL. Draws in part on Microsoft's Generative AI for Beginners, MIT licence, Copyright (c) Microsoft Corporation. microsoft/generative-ai-for-beginners