Push to Beta

The classroom problem

It usually works like this: I have a clear picture in my head of how I want the lesson to work and what I want students to take from it. Once that picture feels right, I start looking for material that fits. Too often, I end up choosing the least-wrong worksheet, and it starts shaping the lesson instead of the other way around.

I teach English at a small special education school in Germany, working with students who need additional support in emotional and social development. Attention, trust and motivation cannot simply be assumed. Of course, relevance matters in every classroom. In mine, generic material tends to miss faster. In the German school context I know, printed worksheets are still a routine part of everyday teaching, and I do not expect that to change anytime soon. Their quality is therefore not a minor detail: poorly matched material has a real cost.

Our school already has a subscription to a what-you-see-is-what-you-get editor for worksheets. In fact, I was the one who suggested it, because I wanted my colleagues to create more of their own material, use their creative judgment and take greater ownership of what they put in front of their students. The approach is straightforward and intuitive: an HTML drag-and-drop editor built around reusable content blocks.

Over time, however, I realized that the tool I had recommended only solved part of the problem. It makes layout work easier, but my colleagues and I still spend too much time and attention assembling each page block by block. I wanted us to spend that attention on content, sequence and fit—not on production work a computer could potentially handle more efficiently.

From renderer to image model

The first version of Sheetify automated that editor workflow. I discussed the lesson with ChatGPT, turned the result into a structured concept card, and let the system assemble the page from reusable components. It worked, but its consistency eventually became a limitation. I saw coherence; my students saw the same worksheet coming back to haunt them, just in a new version.

Then one day, I pasted one of those concept cards into ChatGPT Images 2.0. Somewhat annoyingly, the result was far more varied and visually coherent than anything my renderer had produced—and it arrived almost instantly. I had spent weeks refining the renderer, yet the first image-model result was already closer to what I actually needed.

For a few days, I resisted the obvious conclusion. Then I reminded myself of the sunk-cost fallacy: having built the old pipeline was not a reason to protect it. I connected GPT Image 2 through OpenAI’s API and turned the experiment into a command-line proof of concept. The existing pipeline could already produce a reliable concept sheet that defined the worksheet’s content and structure; the image model gave that approved plan a visual form the old renderer had not reached.

When I asked Google, Codex and ChatGPT to compare the two approaches, all three found strong reasons to keep the deterministic renderer—or at least to make it the reliable foundation of a hybrid system. Their objections were sensible. They did not end the experiment; they clarified what it had to prove.

Google Codex ChatGPT

That changed the technical question. I no longer needed to know whether the model could produce a good-looking page. I needed to know whether it could revise that page on request without drifting away from the approved content. It also meant accepting a more iterative workflow: generate, inspect, revise and sometimes generate again, rather than expecting the right page from a single prompt. That became the new pipeline. Whether it would hold up in daily classroom use—or make sense to other teachers—remained open.

As soon as the generation worked, a more ordinary problem became obvious. I use OneNote to plan and run my lessons, but the workflow now stretched across ChatGPT, OneNote, local folders and a growing collection of PDFs. Every generated worksheet meant another file in my Downloads folder to rename, store and later hunt down. I wanted one smooth flow: develop the idea, review the concept, render the worksheet, save it in the right project and find it again.

The push to beta

Just before Build Week, I had already started migrating my projects to a new mini PC I had set up as a home server. Then I discovered the event and realized it was already underway. It appealed to me immediately, although at first I was not sure what my Build Week project was supposed to be: the core idea and a working prototype already existed. Eventually, I decided to treat the beta push itself as the project. I was not entirely sure that would count as enough for the event, but it was clearly the meaningful next step—for the project and for me.

So that became the project: a summer plan compressed into a beta push over a few days. Hosting, project storage, beta passes, deployment, paid test runs and support for the friends and colleagues willing to test SheetifyIMG were no longer secondary tasks. They were what turned a working generation pipeline into something another person could actually use. I had never taken one of my tools this far.

Many parts of the beta and submission process were firsts for me: self-hosting an application, building deployment and push pipelines, and even setting up a video-rendering pipeline for the demo. Codex was especially helpful here. It reduced the friction of unfamiliar technical work and kept the process moving while I learned what each new layer required.

Most of that work was invisible. I suppose that is what happens when a shiny, exciting prototype has to become a beta someone else can actually test. Long Codex runs went into persistent state, recovery paths, tests and repository cleanup—things users should never have to notice when they work properly. That was when I understood why moving from a prototype to a beta can take more work than building the visible prototype itself.

One of the first steps in the beta push was bringing GPT-5.6 Luna and GPT-5.6 Sol into the app through the Responses API. In practice, Luna handles routing and conversation. Sol builds and revises the worksheet concept, and only after the teacher approves it does the app create an internal ImageSpec and send the controlled content to GPT Image 2. The teacher never has to think about model switches.

The first paid runs showed costs rising faster than I expected. I used GPT-5.6 to analyze the usage data and found that image generation was not even the most expensive part; the reasoning calls before it were. That nudged me to rework the revision flow so small changes would no longer trigger a full rebuild, and to add instrumentation so I could see real usage, cost and latency instead of guessing.

Step by step, the workflow grew into something much closer to what I had imagined. The app could stay in conversation, recognize when there was enough material to propose a concept, and present a clear next action instead of jumping straight to a render. Underneath, however, open-ended chat, explicit actions, deterministic application states and several model roles had to behave like one coherent assistant. Making that routing reliable became one of the hardest parts of the build. It is reliable enough for the beta; I do not consider it finished.

The difficulty of that orchestration also clarified my own role. I studied English and philosophy, not computer science. I did not manually type a single line of SheetifyIMG’s code; I built it through Codex.

I worked with OpenAI models on both sides of the product: through Codex while building it, and through the Responses API inside the app itself. Using the latest Codex app during Build Week, I worked across the entire process—from migrating the prototype to the Beelink server, through implementation and paid test runs, to deployment and the final cleanup of the Git tree. Later, I also used it to analyze beta results and turn the feedback into an actionable backlog.

Working with Codex changed the shape of the work. Instead of moving through one task after another, I kept several threads running and switched between them quickly. To keep priorities, dependencies and open questions out of my head, I began writing them down on paper. It was a kind of mental offloading I had not needed since university—and, counterintuitively, part of what made the faster pace possible.

I never felt like a spectator in that process. The implementation was anything but a one-shot prompt. My role was to define the workflow, compare approaches, make product decisions, test real cases and decide what was ready for another teacher. The process was a loop, not a hand-off: define the problem, compare options, build, inspect and revise. Codex expanded what I could build; it did not decide what the product should become.

Teacher-in-the-Loop

The same principle carries into the app. I stayed in the loop while Codex handled implementation; teachers should stay in the loop while SheetifyIMG handles production. In AI, the familiar phrase is “Human-in-the-Loop.” For this project, “Teacher-in-the-Loop” feels more precise.

A worksheet can look finished and still be pedagogically empty. The concept stage creates a deliberate pause before rendering: a chance to inspect the structure, change a task, question the difficulty or remove something that does not fit the class. I want the model to take over layout and production work—not the lesson or the teacher’s creative control.

That design reflects a broader frustration I have with how AI is currently introduced in schools, at least in the German context I know. Too often, “integration” means dropping a chatbot into a classroom and acting as if access to the model were enough. I still see too few applications that translate model capability into a guided, low-friction workflow built around actual teaching practice.

Teachers need interfaces, guardrails, didactic checks and enough control to understand and take ownership of the result.

Those workflows also have to fit school as it actually exists: limited time; technical confidence that varies widely and is often low; phones, PDFs and printers; and ideas that often arrive away from a desk. SheetifyIMG is my attempt to build that missing layer for one narrow, everyday task.

What remains open

The beta is still small. A handful of people are testing it, including colleagues from my school and another school, along with a few friends. At this stage, reach is not the measure that matters. What matters is whether another teacher can create something worthwhile without my help—and whether they choose to come back.

There are still important open problems. GPT Image 2 renders the complete worksheet, including its text. That gives the page much of its visual coherence, but it also creates the clearest reliability gap: the final image can misspell, omit or change text that was correct in the approved concept. An OCR- or vision-based fidelity check is therefore one of the next important steps. The beta also still has to show whether the workflow fits other teachers as well as it fits the way I plan my lessons.

As of now, the API costs the beta produces are mine. That is manageable for a closed beta, but if usage grows, financing becomes a product question rather than a footnote. Ideally, a teacher could sign in with an existing ChatGPT account and use the app without ever handling an API key, with the resulting usage associated with that account. It would preserve the basic idea of BYOK, but with the ergonomics of ordinary sign-in. If OpenAI ever exposes that kind of flow to third-party apps, it would fit SheetifyIMG much better than sending teachers into an API dashboard.

It is also entirely possible that the next generation of models will make parts of this pipeline unnecessary sooner than I expect. That would be slightly frustrating, but not especially surprising. A solution like SheetifyIMG is built around a particular state of the models: what they can do reliably, where they still need structure, and which compromises are currently worth making. Each new model can shift those boundaries and open up a different way of solving the same problem. I am very aware that this is unlikely to be the final form of the idea.

However, I am increasingly comfortable with that. SheetifyIMG runs on GPT-5.6 today, but its structure is not tied to a single generation of models. Better reasoning and image models could make the workflow cheaper, more stable and more flexible. My current hunch is that deterministic HTML-based worksheet renderers may become less compelling if image models can render complete pages faster, more reliably and with greater visual freedom. We will see.

The project already grew out of one such shift: GPT Image 2 led me to replace a renderer I had spent weeks refining and pointed me towards the approach SheetifyIMG now follows. That is why I see it as an experiment with a real use case and an open outcome—not as a claim that this particular pipeline will survive every model release.

Even if SheetifyIMG remains small, changes shape entirely, or becomes one part of a larger toolset, it has already changed what I believe I can build for my own work. GPT-5.6 did not make the project build itself; it made a project like this buildable for me. It still required a great deal of work, judgment and persistence. But I no longer have to wait for someone else to release exactly the classroom tool I need—and, honestly, in the end that is the part I find most exciting.

Das Unterrichtsproblem

Normalerweise läuft es so: Ich habe eine klare Vorstellung davon, wie der Unterricht funktionieren und was bei den Schülerinnen und Schülern hängen bleiben soll. Sobald dieses Bild stimmig ist, suche ich nach passendem Material. Zu oft entscheide ich mich am Ende für das Arbeitsblatt, das am wenigsten unpassend ist – und dann bestimmt das Material den Unterricht statt umgekehrt.

Ich unterrichte Englisch an einer kleinen Förderschule in Deutschland und arbeite mit Schülerinnen und Schülern, die zusätzliche Unterstützung in ihrer emotionalen und sozialen Entwicklung benötigen. Aufmerksamkeit, Vertrauen und Motivation können nicht einfach vorausgesetzt werden. Natürlich ist Lebensweltbezug in jedem Klassenzimmer wichtig. In meinem verfehlt allgemeines Material sein Ziel jedoch schneller. In dem deutschen Schulalltag, den ich kenne, gehören gedruckte Arbeitsblätter weiterhin zur täglichen Routine, und ich erwarte nicht, dass sich das in naher Zukunft ändert. Ihre Qualität ist deshalb keine Nebensache: Schlecht passendes Material hat einen echten Preis.

Unsere Schule hat bereits ein Abonnement für einen WYSIWYG-Editor für Arbeitsblätter. Tatsächlich war ich derjenige, der ihn vorgeschlagen hat, weil ich wollte, dass meine Kolleginnen und Kollegen mehr eigenes Material erstellen, ihr kreatives Urteilsvermögen einsetzen und mehr Verantwortung für das übernehmen, was sie ihren Klassen vorlegen. Der Ansatz ist geradlinig und intuitiv: ein HTML-Drag-and-Drop-Editor auf Basis wiederverwendbarer Inhaltsblöcke.

Mit der Zeit wurde mir allerdings klar, dass das von mir empfohlene Werkzeug nur einen Teil des Problems löste. Es erleichtert die Layoutarbeit, aber meine Kolleginnen, Kollegen und ich investieren noch immer zu viel Zeit und Aufmerksamkeit darin, jede Seite Block für Block zusammenzusetzen. Ich wollte, dass wir diese Aufmerksamkeit für Inhalt, Abfolge und Passung verwenden – nicht für Produktionsarbeit, die ein Computer möglicherweise effizienter erledigen kann.

Vom Renderer zum Bildmodell

Die erste Version von Sheetify automatisierte diesen Editor-Workflow. Ich besprach den Unterricht mit ChatGPT, überführte das Ergebnis in eine strukturierte Konzeptkarte und ließ das System die Seite aus wiederverwendbaren Komponenten zusammensetzen. Das funktionierte, doch die Beständigkeit wurde irgendwann selbst zur Einschränkung. Ich sah Kohärenz; meine Schülerinnen und Schüler sahen dasselbe Arbeitsblatt, das sie in einer neuen Variante erneut heimsuchte.

Dann fügte ich eines Tages eine dieser Konzeptkarten in ChatGPT Images 2.0 ein. Etwas ärgerlicherweise war das Ergebnis wesentlich abwechslungsreicher und visuell stimmiger als alles, was mein Renderer produziert hatte – und es erschien beinahe sofort. Ich hatte Wochen damit verbracht, den Renderer zu verfeinern, doch schon das erste Ergebnis des Bildmodells kam dem näher, was ich tatsächlich brauchte.

Einige Tage lang sträubte ich mich gegen die offensichtliche Schlussfolgerung. Dann erinnerte ich mich an den Sunk-Cost-Effekt: Die bereits investierte Arbeit war kein Grund, die alte Pipeline zu schützen. Ich band GPT Image 2 über die OpenAI API an und machte aus dem Experiment einen Kommandozeilen-Proof-of-Concept. Die bestehende Pipeline konnte bereits zuverlässig ein Konzeptblatt erzeugen, das Inhalt und Struktur des Arbeitsblatts festlegte; das Bildmodell gab diesem freigegebenen Plan eine visuelle Form, die der alte Renderer nicht erreicht hatte.

Als ich Google, Codex und ChatGPT die beiden Ansätze vergleichen ließ, fanden alle drei gute Gründe, am deterministischen Renderer festzuhalten – oder ihn zumindest zum zuverlässigen Fundament eines hybriden Systems zu machen. Ihre Einwände waren plausibel. Sie beendeten das Experiment nicht; sie machten klarer, was es beweisen musste.

Google Codex ChatGPT

Damit änderte sich die technische Frage. Ich musste nicht mehr herausfinden, ob das Modell eine gut aussehende Seite erzeugen konnte. Ich musste wissen, ob es diese Seite auf Wunsch überarbeiten konnte, ohne vom freigegebenen Inhalt abzuweichen. Das bedeutete auch, einen stärker iterativen Ablauf zu akzeptieren: erzeugen, prüfen, überarbeiten und manchmal erneut erzeugen, statt die richtige Seite von einem einzigen Prompt zu erwarten. Das wurde zur neuen Pipeline. Ob sie dem Unterrichtsalltag standhalten und auch für andere Lehrkräfte sinnvoll sein würde, blieb offen.

Sobald die Generierung funktionierte, wurde ein alltäglicheres Problem sichtbar. Ich plane und gestalte meinen Unterricht mit OneNote, aber der Workflow verteilte sich nun über ChatGPT, OneNote, lokale Ordner und eine wachsende Sammlung von PDFs. Jedes erzeugte Arbeitsblatt bedeutete eine weitere Datei im Downloads-Ordner, die umbenannt, abgelegt und später wiedergefunden werden musste. Ich wollte einen durchgängigen Ablauf: die Idee entwickeln, das Konzept prüfen, das Arbeitsblatt rendern, es im richtigen Projekt speichern und später wiederfinden.

Der Weg zur Beta

Kurz vor der Build Week hatte ich bereits damit begonnen, meine Projekte auf einen neuen Mini-PC umzuziehen, den ich als Homeserver eingerichtet hatte. Dann entdeckte ich die Veranstaltung und stellte fest, dass sie bereits begonnen hatte. Sie sprach mich sofort an, obwohl ich zunächst nicht wusste, was genau mein Build-Week-Projekt sein sollte: Die Kernidee und ein funktionierender Prototyp existierten bereits. Schließlich entschied ich mich, den Weg zur Beta selbst als Projekt zu behandeln. Ich war nicht ganz sicher, ob das für die Veranstaltung ausreichen würde, aber es war eindeutig der sinnvolle nächste Schritt – für das Projekt und für mich.

So wurde aus einem Sommerplan ein auf wenige Tage komprimierter Beta-Push. Hosting, Projektspeicher, Beta-Pässe, Deployment, bezahlte Testläufe und Support für die Freunde und Kolleginnen und Kollegen, die SheetifyIMG testen wollten, waren keine Nebensachen mehr. Sie machten aus einer funktionierenden Generierungspipeline etwas, das eine andere Person tatsächlich benutzen konnte. Keines meiner Werkzeuge hatte ich zuvor so weit gebracht.

Viele Teile des Beta- und Abgabeprozesses waren Neuland für mich: eine Anwendung selbst zu hosten, Deployment- und Push-Pipelines aufzubauen und sogar eine Video-Rendering-Pipeline für die Demo einzurichten. Gerade dabei war Codex besonders hilfreich. Es verringerte die Reibung bei unbekannter technischer Arbeit und hielt den Prozess in Bewegung, während ich lernte, was jede neue Ebene erforderte.

Der größte Teil dieser Arbeit war unsichtbar. Vermutlich passiert genau das, wenn aus einem glänzenden, aufregenden Prototyp eine Beta werden soll, die jemand anderes tatsächlich testen kann. Lange Codex-Läufe flossen in persistente Zustände, Wiederherstellungswege, Tests und das Aufräumen des Repositorys – Dinge, die Nutzerinnen und Nutzer bei korrekter Funktion niemals bemerken sollten. Dabei verstand ich, warum der Weg vom Prototyp zur Beta mehr Arbeit machen kann als der sichtbare Prototyp selbst.

Einer der ersten Schritte auf dem Weg zur Beta war, GPT-5.6 Luna und GPT-5.6 Sol über die Responses API in die App zu bringen. In der Praxis übernimmt Luna Routing und Gesprächsführung. Sol erstellt und überarbeitet das Arbeitsblattkonzept. Erst nachdem die Lehrkraft es freigegeben hat, erzeugt die App intern eine ImageSpec und sendet die kontrollierten Inhalte an GPT Image 2. Über Modellwechsel muss die Lehrkraft nie nachdenken.

Die ersten bezahlten Läufe zeigten, dass die Kosten schneller stiegen als erwartet. Mit GPT-5.6 analysierte ich die Nutzungsdaten und stellte fest, dass nicht einmal die Bildgenerierung der teuerste Teil war, sondern die vorgelagerten Reasoning-Aufrufe. Das brachte mich dazu, den Überarbeitungsablauf so umzubauen, dass kleine Änderungen nicht länger einen vollständigen Neuaufbau auslösen, und Instrumentierung hinzuzufügen, mit der ich echte Nutzung, Kosten und Latenz sehen kann, statt zu raten.

Schritt für Schritt näherte sich der Workflow meiner ursprünglichen Vorstellung. Die App konnte im Gespräch bleiben, erkennen, wann genug Material für einen Konzeptvorschlag vorhanden war, und eine klare nächste Aktion anbieten, statt sofort zu rendern. Unter der Oberfläche mussten sich jedoch offene Gespräche, ausdrückliche Aktionen, deterministische Anwendungszustände und mehrere Modellrollen wie ein einziger stimmiger Assistent verhalten. Dieses Routing zuverlässig zu machen, wurde zu einem der schwierigsten Teile des Builds. Für die Beta ist es zuverlässig genug; als abgeschlossen betrachte ich es nicht.

Die Schwierigkeit dieser Orchestrierung verdeutlichte auch meine eigene Rolle. Ich habe Englisch und Philosophie studiert, nicht Informatik. Keine einzige Codezeile von SheetifyIMG habe ich manuell eingegeben; ich habe die App mit Codex gebaut.

Ich arbeitete auf beiden Seiten des Produkts mit OpenAI-Modellen: beim Bauen über Codex und innerhalb der App über die Responses API. Mit der neuesten Codex-App arbeitete ich während der Build Week am gesamten Prozess – vom Umzug des Prototyps auf den Beelink-Server über Implementierung und bezahlte Testläufe bis hin zum Deployment und der abschließenden Bereinigung des Git-Baums. Später nutzte ich sie außerdem, um Beta-Ergebnisse auszuwerten und das Feedback in ein umsetzbares Backlog zu überführen.

Die Arbeit mit Codex veränderte die Form der Arbeit. Statt eine Aufgabe nach der anderen abzuarbeiten, ließ ich mehrere Threads parallel laufen und wechselte schnell zwischen ihnen. Damit Prioritäten, Abhängigkeiten und offene Fragen nicht alle in meinem Kopf bleiben mussten, begann ich, sie auf Papier auszulagern. Es war eine Form des mentalen Offloadings, die ich seit dem Studium nicht mehr gebraucht hatte – und, etwas kontraintuitiv, ein Teil dessen, was das höhere Tempo überhaupt möglich machte.

Ich fühlte mich dabei nie wie ein Zuschauer. Die Umsetzung war alles andere als ein One-Shot-Prompt. Meine Aufgabe war es, den Workflow zu definieren, Ansätze zu vergleichen, Produktentscheidungen zu treffen, echte Fälle zu testen und zu entscheiden, was für eine andere Lehrkraft bereit war. Der Prozess war eine Schleife, keine Übergabe: Problem definieren, Optionen vergleichen, bauen, prüfen und überarbeiten. Codex erweiterte, was ich bauen konnte; es entschied nicht, was aus dem Produkt werden sollte.

Teacher-in-the-Loop

Dasselbe Prinzip gilt innerhalb der App. Während Codex die Umsetzung übernahm, blieb ich in der Schleife; während SheetifyIMG die Produktion übernimmt, sollen Lehrkräfte in der Schleife bleiben. In der KI-Welt heißt es oft „Human-in-the-Loop“. Für dieses Projekt trifft „Teacher-in-the-Loop“ es genauer.

Ein Arbeitsblatt kann fertig aussehen und pädagogisch trotzdem leer sein. Die Konzeptphase schafft vor dem Rendering eine bewusste Pause: eine Gelegenheit, die Struktur zu prüfen, eine Aufgabe zu ändern, den Schwierigkeitsgrad zu hinterfragen oder etwas zu entfernen, das nicht zur Klasse passt. Das Modell soll Layout und Produktionsarbeit übernehmen – nicht den Unterricht oder die kreative Kontrolle der Lehrkraft.

Dieses Design spiegelt eine grundsätzliche Frustration darüber wider, wie KI derzeit – zumindest in dem deutschen Schulkontext, den ich kenne – eingeführt wird. Zu oft bedeutet „Integration“, einen Chatbot ins Klassenzimmer zu stellen und so zu tun, als reiche der Zugang zum Modell aus. Noch immer sehe ich zu wenige Anwendungen, die Modellfähigkeiten in einen geführten, reibungsarmen Workflow übersetzen, der auf tatsächlicher Unterrichtspraxis aufbaut.

Lehrkräfte brauchen Oberflächen, Leitplanken, didaktische Prüfungen und genug Kontrolle, um das Ergebnis zu verstehen und sich zu eigen zu machen.

Diese Workflows müssen außerdem zur Schule passen, wie sie tatsächlich ist: wenig Zeit, sehr unterschiedliche und häufig geringe technische Sicherheit, Smartphones, PDFs und Drucker sowie Ideen, die oft nicht am Schreibtisch entstehen. SheetifyIMG ist mein Versuch, diese fehlende Ebene für eine enge, alltägliche Aufgabe zu bauen.

Was noch offen ist

Die Beta ist noch klein. Eine Handvoll Menschen testet sie, darunter Kolleginnen und Kollegen meiner Schule und einer weiteren Schule sowie einige Freunde. Reichweite ist in dieser Phase nicht die entscheidende Kennzahl. Entscheidend ist, ob eine andere Lehrkraft ohne meine Hilfe etwas Wertvolles erstellen kann – und ob sie wiederkommt.

Es gibt weiterhin wichtige offene Probleme. GPT Image 2 rendert das gesamte Arbeitsblatt einschließlich des Textes. Das verleiht der Seite einen großen Teil ihrer visuellen Kohärenz, erzeugt aber zugleich die deutlichste Zuverlässigkeitslücke: Das fertige Bild kann Text falsch schreiben, auslassen oder verändern, obwohl er im freigegebenen Konzept korrekt war. Eine OCR- oder visionsbasierte Prüfung der Inhaltstreue ist deshalb einer der nächsten wichtigen Schritte. Außerdem muss die Beta erst noch zeigen, ob der Workflow zu anderen Lehrkräften ebenso gut passt wie zu meiner Art, Unterricht zu planen.

Derzeit trage ich die API-Kosten der Beta selbst. Für eine geschlossene Beta ist das tragbar; bei wachsender Nutzung wird die Finanzierung jedoch zu einer Produktfrage statt zu einer Fußnote. Idealerweise könnte sich eine Lehrkraft mit einem bestehenden ChatGPT-Konto anmelden und die App verwenden, ohne jemals einen API-Schlüssel handhaben zu müssen, während die Nutzung diesem Konto zugeordnet würde. Das würde die Grundidee von BYOK mit der Alltagstauglichkeit einer gewöhnlichen Anmeldung verbinden. Falls OpenAI einen solchen Ablauf für Drittanbieter-Apps ermöglicht, würde er wesentlich besser zu SheetifyIMG passen, als Lehrkräfte in ein API-Dashboard zu schicken.

Es ist außerdem gut möglich, dass die nächste Modellgeneration Teile dieser Pipeline früher überflüssig macht, als ich erwarte. Das wäre ein wenig frustrierend, aber nicht besonders überraschend. Eine Lösung wie SheetifyIMG baut auf einem bestimmten Entwicklungsstand der Modelle auf: darauf, was sie zuverlässig können, wo sie noch Struktur benötigen und welche Kompromisse sich derzeit lohnen. Jedes neue Modell kann diese Grenzen verschieben und einen anderen Weg eröffnen, dasselbe Problem zu lösen. Mir ist sehr bewusst, dass dies wahrscheinlich nicht die endgültige Form der Idee ist.

Damit kann ich zunehmend gut leben. SheetifyIMG läuft heute mit GPT-5.6, doch seine Struktur ist nicht an eine einzelne Modellgeneration gebunden. Bessere Reasoning- und Bildmodelle könnten den Workflow günstiger, stabiler und flexibler machen. Meine derzeitige Vermutung ist, dass deterministische HTML-basierte Arbeitsblatt-Renderer an Bedeutung verlieren könnten, wenn Bildmodelle vollständige Seiten schneller, zuverlässiger und mit größerer visueller Freiheit rendern können. Wir werden sehen.

Das Projekt entstand bereits aus einer solchen Verschiebung: GPT Image 2 brachte mich dazu, einen über Wochen verfeinerten Renderer zu ersetzen, und wies den Weg zu dem Ansatz, dem SheetifyIMG heute folgt. Deshalb verstehe ich es als Experiment mit einem echten Anwendungsfall und offenem Ausgang – nicht als Behauptung, dass genau diese Pipeline jede Modellveröffentlichung überdauern wird.

Selbst wenn SheetifyIMG klein bleibt, seine Form vollständig verändert oder Teil eines größeren Werkzeugkastens wird, hat es bereits verändert, was ich für meine eigene Arbeit bauen zu können glaube. GPT-5.6 hat das Projekt nicht von selbst gebaut; es hat ein solches Projekt für mich baubar gemacht. Dafür waren weiterhin sehr viel Arbeit, Urteilsvermögen und Ausdauer nötig. Aber ich muss nicht mehr darauf warten, dass jemand anderes genau das Unterrichtswerkzeug veröffentlicht, das ich brauche – und ehrlich gesagt ist das am Ende der Teil, der mich am meisten begeistert.