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.

Author:

Amit

Published:

October 22, 2026

Updated:

October 22, 2026

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.

The toolbox nobody had to build

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:

  • ffmpeg for video and audio
  • ImageMagick for images
  • git, curl, ssh, cron
  • SQLite, PostgreSQL, Redis
  • pandoc for converting documents
  • Tesseract for reading text out of images

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.

How an AI edits video

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.webm

None 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.

Beyond video: the rest of the toolbox

ffmpeg is one example. The same pattern applies across the toolbox, and NonBioS can install and use any of these on its own machine:

Tool What it unlocks for an AI engineer
ImageMagick Resize, crop, composite and convert images in bulk: thumbnails, social cards, product shots
Headless Chromium + Playwright Screenshot and test web apps, render HTML into images or video frames
pandoc Convert between Markdown, Word, PDF and HTML for reports and docs
Tesseract Read text out of screenshots and scanned documents
Whisper (open source) Transcribe audio and generate captions, locally
PostgreSQL, Redis, SQLite Real databases and queues, not mocks
cron and systemd Run jobs on a schedule and keep services alive after restarts
nginx and certbot Serve apps on a public IP with HTTPS
git, curl, jq Version everything, call any API, process the JSON that comes back



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.

Reaching beyond the machine: external services

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.mp3

Music 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:

  • ElevenLabs for voiceover, music and sound effects
  • OpenRouter for access to other models, including vision models that can describe frames and screenshots
  • Stripe for payments in the SaaS apps NonBioS builds
  • Telegram and Discord APIs for bots that run as services on the same machine
  • Email and SMS providers for alerts and notifications

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.

Why a sandbox isn’t enough

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.

What it actually took

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:

  • A good reference. Pick a video whose story structure matches yours, even from a different field.
  • Real material. Real recordings of real software, not mockups.
  • Specific notes. If it doesnt look that good - try something like “Make it pop”.
  • A cheap first pass. Run nonbios-lite to see where it’s going, then switch to pro.

Try it yourself

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.

‍

‍

‍

‍

Give your next project an AI Engineer

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