Browse · Writeups
Writeup

Code Interpreter, Part 3 of 3: Local Execution, File Workflows, and Exploratory Analysis

Part 3 of 3 examines missing charts in shared sessions, requests for local code execution, and a central tension in business analysis: how do you choose an upload before you know what data you need?

Source and teaching reviews passed · Human editorial review pending.

Shared sessions lose charts—and opportunities to learn

Share a Code Interpreter analysis and the recipient might see a blank space where its chart should be. At the opening of this final part of the Code Interpreter discussion, Simon reported that shared conversations worked, but generated charts and images did not display. Readers could follow the conversation while missing part of its output.

Another participant wanted sharing to help people discover analysts and prompters with similar interests. Private conversations hide those opportunities to connect. Public prompting also offers a way to learn: one participant recalled people observing one another in Stable Diffusion’s beta Discord, while Simon credited Midjourney’s public interactions with encouraging the same behavior. Making the work visible lets users learn from one another’s prompts.

Run generated code locally

The next request exposed a distinction between where a model runs and where its output executes. A participant wanted GPT to send generated code into a Docker environment on their computer. When the host questioned the hardware requirements, they clarified that local execution of the code—not local hosting of the model—was the goal. Simon wanted API access to the fine-tuned model used for Code Interpreter so users could run its output on their own machines. Both requests would give users control over execution while leaving generation elsewhere.

Business analysis: choosing data before knowing the question

Gabriel proposed business analysis as Code Interpreter’s strongest use case. Executives already understand their business, market, and user funnel, he argued, but may lack the data-analysis skills to investigate questions themselves. Junior analysts may face the reverse problem: acquiring that business context can take a year or two. The opportunity was to give analysis capabilities to people who already understand the business.

For that workflow, Gabriel wanted direct data access instead of file uploads. A user would provide an authenticated API endpoint and a description of the data, allowing the tool to query it. Simon replied that he had built a plugin against his own data software as one route to that integration.

Simon also proposed a workflow using the existing upload interface. Assuming uploads of up to 100 MB, he argued that most business-analysis problems could fit after extracting the relevant data: 1. Query the data warehouse for material relevant to the question, such as highlights from the past 30 days of logs. 2. Export the subset into a SQLite database file or CSV file. 3. Upload it to Code Interpreter for final analysis. This puts data selection upstream and leaves Code Interpreter to perform the last stage of analysis.

Gabriel agreed that an extract could take an analyst a long way, but challenged the assumption that its contents could be chosen in advance. The required data often becomes clear only during analysis. Trial and error reveals which tables, rows, and columns matter; a fixed upload can prevent the analyst from following those discoveries.

The choice therefore depends on how well the investigation’s scope is understood: - Known data needs: Simon’s extract-and-upload workflow can provide the relevant subset for final analysis. - Evolving data needs: Gabriel’s direct-query proposal would let the investigation reach additional tables, rows, and columns as questions develop.

Personas change code style; uploads enable code discussion

Kyle turned from data access to how prompts shape generated code. He reported that asking for a data engineer’s or statistician’s perspective produced different styles and interpretations of the code. He had used these professional personas for data preparation and exploratory analysis.

Junaid offered an example from learning to program. He had started using ChatGPT at the beginning of the year and subsequently launched an iOS app using the OpenAI API. In an early Code Interpreter experiment, he uploaded a Swift file for a ten-level game in which a frog hops around eating bugs. He asked for analysis and improvements, and reported receiving a description of the game’s elements plus suggestions he had not considered.

The useful mechanism was uploading a source file and discussing its contents. This was code analysis, not a demonstration of Swift execution. Junaid confirmed that essentially all the gameplay lived in that one file, although the project contained other files.

The conversation then distinguished two archive workflows: - Uploading a larger project: Junaid planned to ZIP a multifile app and submit it for analysis; he had no result to report yet. - Downloading multiple outputs: Simon confirmed that Code Interpreter could package several generated files into a ZIP archive for a single download.

Keep experimenting—and specify what should come next

After roughly three months of exploring Code Interpreter, Simon still felt he had barely scratched the surface. He encouraged users to try things and share what they learned. The closing discussion also introduced LLM, a command-line tool for running prompts, including piping code from a terminal into a GPT-4 prompt. A major release was tentatively expected the following Monday.

Preparing the conversation’s recap suggested another file workflow: upload the transcript to ChatGPT. Participants floated transcript editing and sentiment analysis as possible uses, without demonstrating either during the exchange.

The model discussion closed with a request for more concrete expectations for GPT-5, informed by experience with GPT-4 and looking beyond the vision, fine-tuning, and new instruct-model releases participants anticipated. One participant still wanted a specific capability from the existing generation: the ability to fine-tune GPT-4 as it already existed.

Two community announcements extended that interest in practical work with AI: - AI.Engineer, a conference about coding and AI: announced for October, with application-based attendance and plans to stream everything online. Its organizer also described shifting their newsletter and podcasts toward code and large language models. - Thursday AI Spaces, a weekly discussion of AI developments: presented as a way to follow the preceding week’s main ideas, with Swyx and Junaid described as frequent participants.

The final reminder returned to the tool’s concrete operations: upload files, create ZIP archives, download results, and ask Code Interpreter to execute code—capabilities participants were encouraged to explore for themselves.

Latent Space

Join Latent Space.

Sign in with Google, or get the newsletter by email.

Loading Google sign-in…

or subscribe by email

Free. Unsubscribe any time.