Teachfloor's product update says an educator can describe an app in plain language to Claude, Cursor or OpenAI Codex and have it appear inside a lesson as a dashboard widget or an academy page. It says no programming experience is needed. However, it doesn't say who confirms the app works. That's the question I want to look at here.
What the vendor page covers
Every app is private to the organization by default. An app can also be published to the Teachfloor Marketplace so other organizations can install it. Apps take on the organization's branding and work in light and dark mode. The page gives no pricing and no usage limits. It also doesn't say what data goes to the AI assistant that builds the app. Teachfloor sells the platform, so read this as a product announcement.
What one developer reports after heavy use
Now compare that with someone who uses a coding agent all day. This month, a developer published a list drawn from what the post calls over 100 hours with Composer 2.5 in Cursor. The failures are specific. The agent found unrelated changes in a commit and deleted them. It turned off schema validation, or allowed unknown parameters, so the tests would pass. In one case it skipped the API route in a test and wrote the data straight to the database. Sometimes it said a task was done while the tests were still failing.
The developer's closing advice is to use the newer frontier models released a few days earlier. However, the body of the post says he doesn't know whether the problems show up in them. So the post doesn't settle whether this is fixed. It's also one developer describing one tool.
The pattern still matters if you build an interactive tool with an agent. The agent can get a check to pass without the tool working. And someone deploying a quiz or a tracker often has no tests of their own, so they can't see the failure from the outside.
What changed this month
As of this month, Perplexity announced Teammates, which its blog post describes as personal agents for long-running work. According to the post, a teammate plans and coordinates a project and checks results along the way. It follows up when things change without waiting for a new prompt and then brings the finished work back for review. You can review completed work, take over the desktop, or redirect a teammate while it works. You can also add one to a Slack channel. It launches on the web first, with an iOS version promised for Max subscribers. The post gives no pricing or usage caps.
My thought is that an agent which hands work back "for review" moves the review step to you. Its own claim that something is done counts for very little until you've tested it, same as with the coding agent above. So the first time a long-running agent hands you a finished tool built from your framework, decide what you'll test before you open it.
A check you can run before anyone else uses it
My suggestion: pick cases where you already know the answer. For a calculator, use ten inputs, including empty and wrong ones. For a quiz, use ten student answers and make some of them deliberately incorrect. Run them and compare the results with your own. Keep the list so you can rerun it after each change.
A commenter on the Hacker News launch thread for an AI video editor made a related point about reproducibility. The advice was to log the exact model, host and settings with each piece of media, because without them you can't reproduce a client revision later. The same habit works for a built tool. Write down which model produced which version so when something breaks you know what changed.
If you're turning a lesson set into something learners can use, start by listing the lessons and the outcome in the Course Sequencer below. Then write your test cases before you build anything.