DevDay Recap, Part 4 of 4: Faster Answers, Parallel Tools, and Room to Build

Open models for specialized interests

At the Keep AI Open party, 3D projections and live visual art surrounded the DJ. A concrete example of the gathering’s message was Trismegistus, described by an attendee as a model trained on occult, physical, and metaphysical material, with resurrection among its intended subjects. This final part of the DevDay recap begins with the case for such specialized models.

The attendee argues that open models make room for specialized uses that large providers may restrict because of legal exposure. Their assertion that OpenAI would restrict these occult-related uses is an expectation, not a demonstrated refusal. They understand the open-model group’s commitment as releasing datasets and models as openly as possible while developing a business, though they defer authoritative questions about its mission to its members.

That commitment extends to helping people build with the models: Discord support, instruction in fine-tuning and producing models, and potential commercial help for companies that want to run them.

DevDay as an annual gathering

The attendee places DevDay alongside GPT-4’s March 14 launch as a landmark AI day. That earlier launch prompted the weekly discussions that became ThursdAI. DevDay and its surrounding parties suggest to them the beginnings of an Apple-style annual event, with developers competing to attend.

A speaker reports roughly 8,000 listeners for their DevDay Spaces broadcast, compared with 22,000 for a Code Interpreter broadcast, as a rough indication of developer interest. The comparison is informal: a competing Space drew some listeners away, and no common measurement window or counting method is specified.

Faster answers earn the second message

The closing guest is Rahul, introduced as Julius AI’s CEO and co-founder at the time of recording. Julius is a data-analysis chatbot that generates and executes code, available as a plugin and a dedicated web app. Platform uncertainty is already immediate: Rahul says plugins are expected to be deprecated, but describes the previous day’s shutdown as accidental and says access has been restored.

Rahul’s developer priorities are Turbo’s speed, multiple function calling, and JSON output formatting. He is also interested in vision and API access to Code Interpreter—the code-execution capability—but expects speed to enable the most applications. He had noticed faster ChatGPT responses several weeks earlier, although that subjective observation establishes neither a numerical speedup nor which model caused the change.

Julius gives that enthusiasm a practical basis. The system generates code, executes it, returns output, and tracks whether the user continues. Rahul reports better conversion when an answer arrives a few seconds sooner. Here, conversion means moving from the first message to the second, not becoming a paying customer. He gives no effect size or experimental design; the reported benefit concerns whether users keep working after their first result.

Parallel tools can prepare the repair

Multiple function calling lets a model request several tools at once, extending the earlier pattern of selecting one tool and supplying its input. Rahul expects parallel requests to support more specialized tools; the interviewer adds that each tool can have more specialized instructions.

A concrete use is repairing Python generated against an outdated library API. The model’s knowledge may predate changes to the library, so otherwise plausible code fails during execution. Rahul compares two approaches: - Existing repair: Generate and execute code, then ask GPT to retrieve current documentation and fix the error if the library API has changed. - Proposed parallel lookup: Request code and documentation together, so the documentation is ready if execution fails. Rahul expects a quicker repair without another GPT call; this is a planned workflow, not a measured result.

Expanding the tool set still raises two distinct constraints: - Selection reliability: Rahul says earlier models became confused as functions and options multiplied. He wants to test the new capability’s breaking point. - Context consumption: Tool descriptions in JSON schemas occupy part of the model’s context window. Whether the new capabilities change the practical limit remains unresolved.

From a sketch to a screenshot feedback loop

Julius already generates React and HTML components, Rahul says. His proposed vision extension would let someone who cannot write React draw a paper mockup and turn it into usable webpage components. A sketch would become an input to component generation, opening the feature to people without that programming skill.

He then proposes a screenshot feedback loop: capture the generated page, feed the image into a vision model, obtain further instructions, and revise the page. Repeating that cycle could produce a webpage that improves through visual feedback. It remains a proposal, without an implemented loop or evaluation demonstrating improvement.

The interview briefly turns to anniversaries. The interviewer uses memorable events to make elapsed time tangible: recognizing that a year has passed motivates spending the next one on interesting work. They find that more motivating than reminders of mortality.

Executable tools let users discover applications

Returning to Julius, the conversation reports that the product has just crossed 100,000 users, without specifying activity criteria or a measurement period. Rahul’s ambition extends beyond analysis: letting models write and execute code could let users automate tasks and interact with services. Data analysis is the immediate focus because, in his assessment, it already works well.

Julius added FFmpeg support for media processing the Friday before the conversation. Users began trying video-to-GIF conversion and YouTube video summarization without the team hard-coding each workflow. Exposing executable tools let users discover applications themselves. One user combined a meme video with an overlay on a tweet and attracted likes—a playful instance of the broader goal of enabling people to do things.

When the interviewer suggests businesses and enterprises as the target market, Rahul identifies individuals with data, including academics, students, and researchers. They can upload CSV or Excel files for analysis.

He also says users can train what he calls a nano GPT in Julius, with training running on a CPU. A demonstration video is planned for the following days; model size, dataset, and measured training results are unspecified.

Platform capability leaves product work to do

The final question is competitive: what happens when OpenAI offers a startup’s features? The interviewer points to OpenAI’s data-analysis GPT and customization with Code Interpreter. They also report a closed-session roadmap item about bringing one’s own Code Interpreter—a planned possibility, not an available feature.

The founder responds with Julius’s launch timing: three months after Code Interpreter’s announcement and a few weeks after its broad rollout. Julius nevertheless reached the reported 100,000-user mark. When he frames that number as evidence of preference, the interviewer interjects that some people may simply have tried it. Acquisition does not establish preference or retention; neither is measured in this exchange.

His concrete defense is that turning a capability into a working product takes substantial effort. FFmpeg support, HTML generation, and React components each require implementation work. He sees that work as room for startups despite overlap with OpenAI.

The closing advice is to avoid giving up before starting. Founders can change ideas, but risk remains part of building a startup. He treats the new capabilities as opportunities to make useful products, and ends with a call to build things and attract users.