How I Built CodeLearn: An Interactive Coding Platform Powered by Tencent EdgeOne Makers

A few weeks ago I set out to build something I’d wanted to make for a while: a platform where beginners could actually practice coding instead of just reading about it. That project became CodeLearn — an interactive coding platform with guided quests, a live sandbox, and an AI tutor that helps you when you’re stuck. And the whole thing runs on Tencent EdgeOne Makers.

This isn’t a polished marketing post. It’s a walkthrough of what I actually built, why I chose EdgeOne Makers to deploy it, and what I learned along the way.

The idea behind CodeLearn

Most coding tutorials fall into one of two traps: either they’re too passive (you read, you nod, you forget), or they’re too overwhelming (a full IDE with no guidance). I wanted something in between, so I designed CodeLearn around three pillars:

• Quests — short, structured learning paths (HTML/CSS basics, JavaScript fundamentals, programming logic) broken into small levels with visible progress.
• Sandbox — a live, in-browser code editor where you write HTML/CSS/JS and instantly see the result, no setup required.
• AI Tutor — a chat assistant that gives hints instead of answers, nudging learners toward understanding rather than just copy-pasting a solution.

The goal was simple: reduce the gap between “I understand the concept” and “I can actually write it myself.”

Why I chose Tencent EdgeOne Makers

I evaluated a few hosting options before landing on EdgeOne Makers, and a few things stood out enough that I stuck with it: fast deployment straight from GitHub, native support for serverless and cloud functions, and a free tier that’s actually usable for real development instead of just a toy demo.

Stage by stage: from local build to live deployment

Here’s roughly how the build actually went, feature by feature.

1. Building the frontend locally. CodeLearn started as a plain Next.js app — the landing page, the quest list, and the quest detail pages where the sandbox and AI tutor live. I built and tested everything locally first with npm run dev before touching deployment at all, so I knew the UI worked before adding any backend complexity.

2. Sandbox tools / code runner. For the live coding sandbox, I used a sandboxed iframe as the code runner — whatever HTML/CSS/JS the learner types gets injected and executed inside an isolated iframe, with the rendered output shown instantly next to the editor. Keeping the runner isolated from the main app was important so user-written code can’t touch anything outside the sandbox.

3. Serverless function for the AI Tutor. The AI Tutor needed a backend that could safely call an LLM without exposing any API key on the client. Instead of running my own server, I wrote it as a serverless function on EdgeOne Makers — it receives the learner’s question, forwards it to the model, and streams the response back. No server to provision or keep alive.

4. Cloud function for heavier logic. Some logic didn’t fit neatly into a lightweight edge runtime — things like validating quest progress and handling slightly heavier request processing. For that, I used EdgeOne’s cloud function runtime (Node.js), which gave me a more familiar server-like environment for anything that needed more than a quick edge response.

5. Chat agent + DeepSeek Flash as the model. The AI Tutor itself is built as a chat agent, with its system prompt tuned specifically to give hints instead of full answers. For the underlying model, I used DeepSeek Flash, mainly because it’s fast and cheap enough to run interactively without the tutor feeling laggy every time a learner asks a question mid-exercise. I call it through EdgeOne’s AI gateway using a familiar OpenAI-style client:

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: 'https://ai-gateway.edgeone.link',
});

const completion = await client.chat.completions.create({
  model: '@makers/deepseek-v4-flash',
  messages: [
    { role: 'system', content: 'You are a patient coding tutor. Give hints, not full answers.' },
    ...conversationHistory,
    { role: 'user', content: learnerMessage },
  ],
});

6. Conversation memory. A tutor that forgets what you asked two messages ago isn’t very useful. Instead of managing chat history myself, I put the AI Tutor in the agents/ folder (Makers' stateful agent runtime, as opposed to the stateless cloud-functions/ one) and pass a conversation_id with every request. EdgeOne routes requests sharing the same conversation_id back to the same instance, so it can reuse context from earlier in that chat without me building my own session store:

const response = await fetch('/agents/chat', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    conversation_id: sessionConversationId,
    message: learnerMessage,
  }),
});

This is also why the sandbox and the AI Tutor feel connected rather than like two separate tools bolted together — the tutor’s memory of the conversation persists for as long as the learner is working through a level.

7. Database with Turso. Local storage was fine for a first version, but it meant progress disappeared the moment a learner switched devices, and the AI Tutor had no memory beyond a single session. I moved persistence over to Turso (SQLite at the edge, via libSQL) for two things: quest progress per user, and conversation history for the AI Tutor. Because Turso is edge-friendly and low-latency, it fits naturally next to functions running on EdgeOne Makers instead of adding a slow round trip to a traditional centralized database.

import { createClient } from '@libsql/client';

const turso = createClient({
  url: process.env.TURSO_DATABASE_URL,
  authToken: process.env.TURSO_AUTH_TOKEN,
});

// save a message from the AI Tutor conversation
await turso.execute({
  sql: `INSERT INTO messages (conversation_id, role, content, created_at)
        VALUES (?, ?, ?, datetime('now'))`,
  args: [conversationId, 'user', learnerMessage],
});

// pull quest progress for a learner
const progress = await turso.execute({
  sql: `SELECT quest_id, level, completed_at FROM progress WHERE user_id = ?`,
  args: [userId],
});

This is what turned “conversation memory” from something session-bound into something that actually persists — a learner can close the tab, come back a day later, and the AI Tutor still has context from where they left off, because that history is read back from Turso instead of living only in memory.

8. Deploying to EdgeOne Makers. Once the frontend, sandbox, serverless function, cloud function, chat agent, and Turso database were all working locally, I connected the repo to EdgeOne Makers. It automatically detected the Next.js build output and split it correctly between static assets and the dynamic function routes — I didn’t have to manually configure that separation.

The actual commands I ran

For anyone who wants to follow the exact same path, here’s the command sequence I used, stage by stage.

Setting up the frontend locally:

npx create-next-app@latest codelearn
cd codelearn
npm install
npm run dev

Installing and checking the EdgeOne CLI:

npm install -g edgeone
edgeone -v
edgeone -h

Initializing Makers config in the existing project (instead of starting from a template, since I already had the app built):

edgeone makers init

Running the project locally through EdgeOne’s own dev runtime, to make sure the serverless function, cloud function, and edge routes behave the same way they would once deployed:

edgeone makers dev

Deploying to production once everything worked locally:

edgeone makers deploy -n codelearn -t $EDGEONE_API_TOKEN

Deploying to a preview environment first (what I actually used while testing the chat agent + DeepSeek Flash integration, before pushing it live):

edgeone makers deploy -n codelearn -e preview -t $EDGEONE_API_TOKEN

Setting up the Turso database:

curl -sSfL https://get.tur.so/install.sh | bash
turso auth login
turso db create codelearn-db
turso db show codelearn-db --url
turso db tokens create codelearn-db

Managing environment variables (this is where the DeepSeek Flash API key and Turso credentials live, so they never touch the client):

edgeone pages env add DEEPSEEK_API_KEY your_api_key_here
edgeone pages env add TURSO_DATABASE_URL your_turso_url_here
edgeone pages env add TURSO_AUTH_TOKEN your_turso_token_here
edgeone pages env ls

That’s it — no Dockerfile, no manual server provisioning. Once edgeone makers deploy finished, the frontend, the serverless function powering the AI Tutor, the cloud function, and the Turso-backed persistence layer were all live.

How the pieces fit together

The sandbox runs in a sandboxed iframe with live preview — whatever the user types in the editor renders instantly, similar to CodePen but scoped to each quest’s exercise, powered by the code runner described above.

The AI Tutor chat agent is where the serverless function and DeepSeek Flash do the heavy lifting. Instead of giving direct answers, the tutor’s system prompt is designed to respond with progressive hints — first a nudge, then a more specific pointer, and only if the learner is still stuck, a fuller explanation. That was a deliberate design choice: an AI that hands out full answers immediately doesn’t actually teach anything.

Progress tracking started out in local storage while I was still validating the UI, then moved to Turso once the core flow was working — so a learner’s quest progress and their AI Tutor conversation history now both follow them across devices instead of resetting every time they open the app on a different browser.

What I’d tell someone trying this themselves

If you’re building something similar, a few honest takeaways:

1. Don’t over-engineer the sandbox code runner early. A simple sandboxed iframe is enough to start; you can always add more isolation later.
2. Split your backend logic deliberately — serverless functions for quick, stateless calls like the chat agent, cloud functions for anything heavier that benefits from a more familiar Node.js runtime.
3. Pick your model based on the interaction pattern, not just benchmark scores. DeepSeek Flash worked well for me specifically because the tutor needed to feel responsive in a back-and-forth chat, not because it’s the “best” model on paper.
4. Keep your chat agent’s system prompt strict about not giving away answers — it’s easy for it to default to being “too helpful.”
5. Don’t skip a real database for too long. Local storage is fine for the first prototype, but the moment you want conversation history or progress to survive across devices, something like Turso is a lot less painful to add early than to retrofit later.
6. Test your deployment early and often. Catching a routing or build quirk on day one is a lot less painful than debugging it after your app has grown.

Final thoughts

Building CodeLearn was a good reminder that a lot of the friction in shipping a side project isn’t the idea — it’s the infrastructure around it. Tencent EdgeOne Makers removed enough of that friction — serverless and cloud functions, a working chat agent setup with DeepSeek Flash, Turso for persistence, and straightforward deployment — that I could spend most of my time on the actual product: the quests, the sandbox experience, and making the AI tutor genuinely useful instead of just a chatbot bolted on the side.

If you’re curious about the code, the repo is public here: **https://github.com/Maylenee/CodeLearn **codelearn.edgeone.dev

TencentEdgeOne #EdgeOneMakers #CODEPOLITAN #EdgeOne