Amit
October 22, 2026
Why We Gave Our AI Engineer a Real Computer
Why NonBioS has a full Linux machine rather than a sandbox, what that unlocks, and how a single command-line tool turned a language model into a video editor.
Why NonBioS has a full Linux machine rather than a sandbox, what that unlocks, and how a single command-line tool turned a language model into a video editor.
Author:
Published:
Updated:

Last week we published a film: two years of apps that NonBioS built and deployed, cut together with matching music and sound. No one on our team opened a video editor. NonBioS (powered by Claude Opus) did the edit by writing Python and running ffmpeg from a terminal.
People asked how. The honest answer is that the most important part isn’t the AI model. It’s the computer the model was working on, and the decades of tools that come with it.
This post is about that idea: why NonBioS has a full Linux machine rather than a sandbox, what that unlocks, and how a single command-line tool turned a language model into a video editor.
Every Linux machine ships with, or is one command away from, an enormous library of tools written and refined over decades by thousands of engineers:
These tools share a design philosophy that turns out to suit AI remarkably well. Each does one job very well. Each is controlled by text: you type a command, and it prints a result. And each can be chained to the others.
That’s exactly the interface a language model is good at. A model can’t click through a video editor’s timeline, but it can write
ffmpeg -i input.mp4 -vf fps=2 frames/%04d.png without hesitation. Every frontier model already knows these tools well, because their documentation, examples and Stack Overflow answers have been on the internet for decades and are part of what these models learned from.
So the models already know how to use the tools. What they’re usually missing is a computer to run them on.
Language models don’t render video. They read text and images, and write text. ffmpeg is the bridge: it turns video into things a model can reason about (frames, timestamps, numbers) and turns the model’s decisions back into video.
Here is roughly what happened when we made our film.
1. Study a reference.
We gave NonBioS a reference video whose story arc fit ours: a Make in India promo, which tells a hardware story we adapted to software. NonBioS can’t watch a video, so it took it apart:
bash
# Pull two frames per second so the model can "see" the style
ffmpeg - i reference.mp4 - vf fps = 2 frames / % 04 d.png
# Find every cut, to measure the pacing
ffmpeg - i reference.mp4 - vf "select='gt(scene,0.3)',showinfo" - f null - 2 > & 1 | grep pts_time
# Extract the audio to analyse rhythm and structure
ffmpeg - i reference.mp4 - vn - ac 1 - ar 22050 audio.wav
From the frames it read the layouts, type and colour. From the cut timestamps it learned how long each shot lasted and where the pace changed. From the audio it worked out the beat the cuts followed. Then it wrote a screenplay for our footage in the same rhythm.
2. Measure everything.
Timing is the difference between a video that feels edited and one that feels assembled. NonBioS measured every clip and every piece of audio to the millisecond:
bash
ffprobe -v error -show_entries format=duration -of csv=p=0 music.mp3
3. Lay out the scenes in code.
NonBioS wrote Python that defined each scene: which recording, which segment, how fast, what text on screen and when. That script generated the ffmpeg commands to trim, scale, speed up and join the clips.
4. Mix the sound.
bash
ffmpeg -i film.mp4 -i music.mp3 -i whoosh.wav \ -filter_complex "[2:a]adelay=12000|12000[sfx];[1:a][sfx]amix=inputs=2:duration=first[a]" \ -map 0:v -map "[a]" -c:v copy -c:a aac -shortest final.mp4
5. Review its own work.
This is the step that made the result good rather than passable. After each render, NonBioS built a contact sheet, a grid of frames from across the film, and looked for problems: clipped text, blank frames, cuts that missed the beat.
bash
ffmpeg -i final.mp4 -vf "fps=1,scale=320:-1,tile=6x4" -frames:v 1 contact-sheet.png
6. Encode for every destination.
One command for the high-quality master, another for the small silent loop on our homepage, another for the vertical Short:
bash
ffmpeg -i final.mp4 -c:v libx264 -crf 18 -pix_fmt yuv420p -movflags +faststart master.mp4
ffmpeg -i loop.mp4 -c:v libvpx-vp9 -b:v 0 -crf 32 -an hero-loop.webmNone of this is exotic. It’s the same ffmpeg that sits inside the browsers and media players you use every day. What’s new is that an AI can now drive it fluently, and with a computer to run it on, that turns into a real editing workflow.
ffmpeg is one example. The same pattern applies across the toolbox, and NonBioS can install and use any of these on its own machine:
The power isn’t in any one tool. It’s in combining them. Transcribe a recording with Whisper, cut it with ffmpeg, caption it from the transcript, generate a thumbnail with ImageMagick, and publish it on a schedule with cron. Each step is ordinary. Together they’re a production pipeline, and an AI can assemble one in an afternoon.
Some things are better done by specialised services. The music in our film was composed by NonBioS through the ElevenLabs API, because the reference video’s original track was copyrighted and we needed our own.
From the machine’s point of view, an external service is just another tool. NonBioS calls it the way any developer would: an HTTP request with an API key. For example, generating a voiceover line with ElevenLabs looks like this:
bash
curl -s -X POST "https://api.elevenlabs.io/v1/text-to-speech/$VOICE_ID" \
-H "xi-api-key: $ELEVENLABS_API_KEY" \
-H "Content-Type: application/json" \
-d '{"text": "This is NonBioS."}' \
--output line-01.mp3Music generation follows the same pattern against ElevenLabs’ music endpoint. And the moment the audio file lands on disk, it’s back in ffmpeg’s world: measured, trimmed, mixed and encoded like anything else.
A few services we see NonBioS users wire in regularly:
The rule we follow is simple: keys live in a .env file, never in code or logs, and the agent is told never to print them.
Most AI coding tools give the model a narrow environment: write code, preview it, deploy it to someone else’s cloud. That works for the cases the sandbox was designed for. It breaks the moment a task needs something the designers didn’t anticipate, like ffmpeg, a Redis queue, a background worker, or a bot that runs all night.
A real computer has no such ceiling. NonBioS gets a Linux VM with root access, 2 vCPUs, 4GB of RAM and a public IP. If a task needs a tool, it installs it. If an app needs a service, it runs one. If something breaks, it reads the logs and fixes it, the way a human engineer would.
That’s why the same agent that edited our film has, over two years, also built dashboards, uptime monitors, Telegram bots, internal tools and SaaS products, and kept them running on machines our users own.
The film wasn’t one prompt. Each stage (the screenplay, the music, the final polish) took three or four rounds of notes, and the whole edit took six to ten hours of guided work. The AI did the editing; we directed.
What helped most:
NonBioS can run the same pipeline on its own machine: it has the terminal, it can install ffmpeg, and it can call ElevenLabs with your key. To let it “see” frames, add an OpenRouter key for a vision model.
Start with something like:
I’ve uploaded my screen recordings and a reference video. Break down the reference’s pacing, cuts and audio using ffmpeg, then propose a screenplay for a 60-second film of my recordings in the same style. Use the ElevenLabs API (key in .env) for the music. Use Gemini vision model using the OpenRouter API (key in .env). Show me a contact sheet after each render.
Then direct it like you would a human editor.
The tools have been waiting for decades. AI just needed a computer.
Quick signup, give NonBioS a high-level instruction, see progress within minutes. Your first multi-hour session is on the house.
No Credit Card Required