After DevDay: Open Models, Faster Tools, and the Work of Building — Part 4 of 4

An online community meets on Folsom Street

OpenAI’s DevDay party took place in an art museum with live jazz; the Nous Research gathering occupied a club on Folsom Street in San Francisco. For one attendee, the club brought an online community into the same room: people encountered through Discord, X, and Thursday.ai were meeting in person. This final part of the DevDay conversation opens with those contrasting developer gatherings.

Projected artwork and GPU-themed signs promoted keeping AI open, alongside imagery associated with the effective-accelerationist community. The attendee saw the event as an opportunity to gather people already in town for OpenAI’s conference. Two guests in lab coats said they had come straight from work on chips.

Asked about Nous Research’s commitment to open releases, the participant deferred an authoritative account to its members. Their understanding combined releasing datasets and models with helping people build and fine-tune models through Discord, potentially alongside paid assistance for companies running them. Trismegistus, described as a model trained on occult, physical, and metaphysical material, illustrated the community’s unconventional interests. The example concerned subject matter, not demonstrated answer quality.

The participant argued that legal exposure helps explain why large providers constrain outputs, contrasting those restrictions with the freedom of open models. Their assertion that OpenAI would block occult-related uses was speculative. More broadly, DevDay felt to this attendee like a shared AI milestone comparable to the GPT-4 launch, with the potential to become a sought-after annual developer gathering.

Faster answers can keep users talking

The final interview takes place one day after DevDay with Rahul Ligma, introduced as CEO and co-founder of Julius AI. Platform dependence surfaces immediately: Rahul reports that plugins were accidentally switched off during DevDay and then restored. He also describes their deprecation as forthcoming.

Rahul’s priorities among the announcements are Turbo’s speed, multiple function calling, and JSON output formatting. His speed assessment is qualitative: he had noticed ChatGPT becoming faster in the preceding weeks, but supplies no benchmark or confirmation of which model caused that change.

Julius gives him a specific reason to care about latency. After a user’s first message, the system generates code, executes it, and presents the output. Rahul reports that delivering this answer a few seconds sooner improves the chance of a second message. Conversion here means continuing the conversation, rather than buying a subscription. He gives no effect size or experimental design, but identifies a concrete product outcome for speed improvements.

Fetch documentation before the error

Function calling is tool use: the model requests a tool and supplies its inputs. Rahul expects the ability to request multiple tools at once to support more specialized tools, each with more specific instructions, and to expand how applications organize work around the model.

A recurring Julius failure explains the opportunity. GPT generates Python using its remembered version of a module, but the module’s programming interface has changed. The code fails when executed. Rahul contrasts two approaches: - Recover after failure: ask GPT to look up current documentation after the execution error, then repair the code. - Prepare documentation alongside code: request code generation and a documentation lookup together, so the documentation is ready if execution fails. Rahul hopes this will enable a quick repair without another GPT call. The second approach is a planned workflow, without a measured latency result.

More tool choices can confuse the model. Rahul had observed this with larger sets of functions and wanted to test the new capability’s breaking point. The interviewer also asks about the space tool definitions consume in the model’s context window; Rahul does not know whether that constraint has changed. Requesting multiple tools therefore leaves an important question open: how many choices can the model use effectively?

Rahul wants developers to give multiple tool use more attention. The interviewer adds a complementary recommendation: explore advanced API features alongside base-model behavior and prompt engineering.

Use the rendered page to guide its next revision

Julius already supported generating React and HTML components. Rahul proposes using vision to make that capability useful to people who cannot write React: turn a hand-drawn mockup into usable webpage components.

He extends the proposal into a visual feedback loop: 1. Generate a webpage. 2. Capture a screenshot of the result. 3. Feed the screenshot into a vision model to produce further instructions. 4. Use those instructions to revise the page and repeat. The rendered output becomes input to the next revision. This is a proposed capability, not a demonstration of reliable improvement.

A brief detour turns to anniversaries. The host describes marking dates as a tangible reminder of time passing, motivating him to spend his years wisely and pursue interesting work.

Give users tools they can combine

The host describes Julius as a data-analysis chatbot resembling an expanded Code Interpreter, available through a plugin and a dedicated web app. Rahul confirms that description, while explaining a broader ambition: help people accomplish tasks through model-written code. Data analysis is the immediate focus because he considers it something the system can already do well.

The preceding Friday’s addition of FFmpeg support for media tasks illustrates the approach. The team exposed executable media tools and told Julius what they could do. Rahul reports that users then discovered workflows the team had not explicitly built: - Video conversion: turning uploaded videos into GIFs. - Video summaries: requesting short summaries of YouTube videos. - Media composition: overlaying a meme video on Rahul’s tweet. Tool access and capability descriptions let users request new combinations of work.

When the host suggests an enterprise audience, Rahul corrects him: Julius targets individuals with data to analyze, including academics, students, and researchers uploading CSV or Excel files.

Rahul also reports that users can train NanoGPT inside Julius on a CPU, with a demonstration video planned for the following days. His estimate of a few minutes comes without a dataset size, model configuration, or quality measurement; it cannot serve as a general training-performance estimate.

Keep building when the platform competes

The closing question concerns OpenAI building overlapping features. The host points to its built-in data-analysis bot and customizable GPTs with Code Interpreter as competitive pressure. He also reports a possible opportunity from a closed-session roadmap: bringing one’s own Code Interpreter. That remained a roadmap prospect at the time of the interview.

Rahul responds with Julius’s launch chronology: three months after Code Interpreter’s announcement and a few weeks after its general rollout. Julius nevertheless reached a reported 100,000 people, including people who merely tried it. The interviewer challenges the suggestion that this number establishes preference for Julius; it provides no measure of active usage or retention.

His argument is that making capabilities work as a product still takes substantial effort. FFmpeg support and HTML and React component generation are examples of that work. Founders can reasonably change ideas, he argues, but too many give up before making an application function properly. Risk is part of building a startup, rather than sufficient reason to stop.

The expanding range of things developers can build leaves Rahul excited. His closing call is practical: use the new AI capabilities to build useful products and attract users.