Mit AutoCoder.cc eine KI-App bauen und das Backend für Produktion vorbereiten

Eine überprüfbare User Journey statt einer Seitenliste

Die offizielle AutoCoder-Übersicht nennt Frontend und UI, Backend-APIs und Logik, Datenpersistenz, Benutzerauthentifizierung, Deployment und Quellcodeexport. Im Build-Ablauf wird eine natürlichsprachige Beschreibung zu einer Requirement List, die vor der Demo-Generierung verfeinert werden kann.

Beschreiben Sie daher nicht nur Login, Dashboard und Upload-Seite, sondern ein vollständiges Ergebnis. Für einen Dienst zur Dokumentanalyse könnte die Journey so aussehen:

1. Eine Person erstellt ein Konto und lädt einen erlaubten Dateityp hoch.
2. Das Backend prüft Größe, Format und Eigentümerschaft des Dokuments.
3. Der Analyseauftrag erhält eine eigene ID und einen sichtbaren Status.
4. Die Modell-API wird nur vom Backend aufgerufen.
5. Die Oberfläche zeigt das Ergebnis oder einen kontrollierten Fehler, ohne Key oder interne Provider-Antwort offenzulegen.

Testen Sie nach der Generierung eine gültige Datei, eine ungültige Datei und eine wiederholte Einsendung. So werden fehlende Berechtigungen, doppelte Jobs und blockierende Fehlerzustände sichtbar, die eine rein visuelle Prüfung der Startseite nicht findet.

Plattform-Publish oder Quellcodeexport

AutoCoder bietet zwei unterschiedliche Übergaben vom Editor zu einer URL. Der integrierte Publish erzeugt eine Website URL und eine Backend URL. Für Demos und frühe Produkttests ist das praktisch, weil ein Teil der Infrastruktur innerhalb der Plattform bleibt.

Der Export ist sinnvoll, wenn das Team Repository, Umgebungen, CI/CD, Secrets, Server und Rollback selbst kontrollieren möchte. Laut der aktuellen Dokumentation zu Plans & Credits und Deploy & Hosting gehört Source Code Export zu den kostenpflichtigen Plänen und ist in Free nicht verfügbar. Preise und Credits können sich ändern; prüfen Sie vor dem Kauf die aktuelle Seite, statt eine alte Zahl in die Architektur zu übernehmen.

Vier Fragen helfen bei der Wahl:

Exportierter Code ist der Beginn der technischen Abnahme. Er beweist nicht, dass Abhängigkeiten geprüft, Berechtigungen korrekt, Migrationen umkehrbar oder erwartete Lasten beherrschbar sind.

Die Modell-API gehört hinter das Backend

In dieser Architektur erzeugt und exportiert AutoCoder die Anwendungsschicht: Oberfläche, Serverlogik und Datenstrukturen. BetterToken wird im Backend als Modell-API für Zusammenfassung, Klassifikation oder Extraktion angebunden. Der API Key darf nie in einem Frontend-Bundle, HTML, mobilen Paket oder öffentlichen Repository erscheinen.

Die aktuelle öffentliche BetterToken API Reference dokumentiert OpenAI-kompatible Chat Completions:

Base URL: https://www.bettertoken.ai/v1
Request URL: https://www.bettertoken.ai/v1/chat/completions
Authorization: Bearer YOUR_API_KEY
Model: YOUR_MODEL_ID

Behandeln Sie YOUR_MODEL_ID als Konfiguration. Kopieren Sie die aktuelle ID aus dem Modellkatalog oder aus dem Setup des betreffenden API Keys in der Console. Ein Modellname aus einem alten Tutorial ist keine dauerhafte Abhängigkeit.

Für ein exportiertes Node.js-Backend können die Umgebungsvariablen so beginnen:

OPENAI_BASE_URL=https://www.bettertoken.ai/v1
BETTERTOKEN_API_KEY=your_api_key_here
BETTERTOKEN_MODEL_ID=copy_current_model_id_here

Committen Sie keine echten Werte. Stellen Sie diese zur Laufzeit über den Secret Manager der jeweiligen Umgebung bereit. Auch der kompatible Client wird ausschließlich in einem Servermodul initialisiert:

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.OPENAI_BASE_URL,
  apiKey: process.env.BETTERTOKEN_API_KEY,
});

export async function summarizeDocument(text: string) {
  const response = await client.chat.completions.create({
    model: process.env.BETTERTOKEN_MODEL_ID!,
    messages: [
      { role: "system", content: "Return a concise factual summary." },
      { role: "user", content: text },
    ],
  });

  return response.choices[0]?.message?.content ?? "";
}

Das Beispiel definiert die Modulgrenze, ist aber keine vollständige Produktions-Middleware. Ergänzen Sie Prüfungen fehlender Variablen, Eingabegrenzen, Timeout, Fehlerklassifikation und Logging ohne Dokumentinhalt und Key.

Smoke Test vor echtem Traffic

Senden Sie zuerst eine minimale Anfrage außerhalb der eigentlichen Geschäftslogik. Damit lassen sich Fehler in der API-Konfiguration von Fehlern im generierten Projekt trennen:

curl "https://www.bettertoken.ai/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "YOUR_MODEL_ID",
    "messages": [
      {"role": "user", "content": "Reply with: API connected"}
    ]
  }'

Eine erfolgreiche Antwort enthält choices[0].message.content. Wiederholen Sie danach denselben kleinen Fall über die Serverroute der App und prüfen Sie:

• Die Anfrage kommt aus dem Backend, nicht aus dem Browser.
• Der echte Key ist weder im Quellcode noch im Network Trace des Clients sichtbar.
• Ein Upstream-Fehler wird zu einer kontrollierten Antwort der Anwendung.
• Das BetterToken Dashboard zeigt Modell, Zeitpunkt, Status sowie Input-, Output- und Cache-Token.

Wenn curl funktioniert, die Serverroute aber nicht, prüfen Sie das Laden der Umgebung, Variablennamen, Proxy, Body-Serialisierung und Antwortverarbeitung. Wenn beides fehlschlägt, kontrollieren Sie zuerst Key, aktuelle Model ID, URL und Fehlermeldung; eine Änderung am Frontend behebt diese Konfiguration nicht.

Technische Abnahme vor Produktion

Abhängigkeiten und Build. Bewahren Sie das Lockfile auf, führen Sie eine saubere Installation und den Production Build aus. Prüfen Sie Lizenzen und entfernen Sie ungenutzte Pakete.

Authentifizierung und Autorisierung. Stellen Sie sicher, dass Nutzer nur ihre eigenen Objekte lesen und ändern können. Testen Sie anonyme, normale und administrative Anfragen getrennt.

Datenbank. Speichern Sie Schemaänderungen als Migrationen, testen Sie das Upgrade auf einer Datenkopie und bereiten Sie die Wiederherstellung vor. Tabellenänderungen beim Start ohne Historie erschweren den Rollback.

Secrets. Trennen Sie Keys für Entwicklung, Staging und Produktion. Geben Sie dem Runtime-Prozess nur notwendige Werte und dokumentieren Sie die Rotation vor einem Vorfall.

Timeouts und Retries. Begrenzen Sie die Dauer des Modellaufrufs. Wiederholen Sie nur Vorgänge mit verstandener Idempotenz; unbegrenzte Retries können Queue und Kosten erhöhen.

Beobachtbarkeit und Budget. Verknüpfen Sie eine interne Task ID mit API-Zeit und Status, ohne private Inhalte zu loggen. Das Dashboard hilft beim Abgleich von Modell, Status und tatsächlichen Token; Eingabe- und Retry-Limits schützen das Budget.

Rollback. Bewahren Sie das vorige funktionierende Artifact und eine reversible Konfiguration auf. Prüfen Sie, dass älterer Code nicht mit einer bereits ausgeführten Migration kollidiert.

Die App ist bereit für einen begrenzten Produktionspiloten, wenn die zentrale Journey in Staging funktioniert, Berechtigungen geprüft sind, die Modell-API einen isolierten Smoke Test besteht, Fehler ohne Datenleck sichtbar sind und der Rollback tatsächlich getestet wurde. Generierter Code allein liefert diesen Nachweis nicht.

Um den KI-Aufruf in einen kontrollierten Backend-Pfad zu verschieben, erstellen Sie einen separaten API Key, kopieren die aktuelle Model ID und senden die erste Anfrage anhand der BetterToken API Reference. Gleichen Sie vor echtem Traffic den Dashboard-Eintrag mit der Task ID Ihrer Anwendung ab.

Quellen

• AutoCoder: Funktionsübersicht
• AutoCoder: Build-Ablauf
• AutoCoder: Pläne und Export
• AutoCoder: Deployment und Hosting
• BetterToken API Reference