Tim Daugs

building with AI

[Tim Daugs @TimDaugs]

https://t.co/FtFwiVEO4D

[Tim Daugs @TimDaugs]

SOMEONE TURNED A PHOTO INTO A PRODUCT YOU CAN HOLD WITH ONE APP.

photo in. the app cuts it down to a clean stamp design. you tap order, and a real rubber stamp shows up at your door.

the whole thing does one job:

→ upload any photo
→ it converts to a stamp design automatically
→ designs get saved and sorted by date
→ order the physical stamp in the app
→ press it on letters, packaging, cards

what makes this interesting isn't the code. it's the last mile. most vibe-coded apps end at a screenshot. this one ends at a manufacturer, a shipping label, and a thing you can hold.

that's the part everyone skips because it's boring. supplier, fulfillment, returns. it's also the part that makes it a business instead of a demo.

the build got cheap. plugging it into the physical world didn't.

[Tim Daugs @TimDaugs]

https://t.co/FtFwiVEO4D

[Tim Daugs @TimDaugs]

SAME PROMPT, SAME 32 MINUTES, TEN GENERATIONS EACH. ONE MODEL MADE A WEBSITE. THE OTHER MADE A FILM.

boutique Japan travel brand, origami style. a subway pulls in, a paper house unfolds into a hotel, a bird takes flight as you scroll.

the pipeline is the fun part.

→ one anchor image, approved once. every scene inherits its style
→ it goes to video through the Higgsfield MCP, straight from the terminal
→ ffmpeg rips every frame
→ each frame maps to a scroll position, so the scrollbar becomes the playhead

by hand this is brutal. matched starting frames, stitched videos, frames pulled one by one and synced.

GPT-5.6 Sol nailed the interiors. real detail inside every scene. then it hard cuts. scene one to scene two, nothing in between.

Fable 5 built the seams. wires push out of the top of frame while the next scene blurs in behind, gains depth, locks into place.

same inputs, and the entire verdict came down to the transitions.

the thing nobody writes into the prompt is the thing that decides whether it reads as a page or a film. the shots were never the hard part. the cuts were.

[Tim Daugs @TimDaugs]

https://t.co/FtFwiVEO4D

[Tim Daugs @TimDaugs]

"CLAUDE CAN'T DO THAT" IS ALMOST NEVER TRUE. IT USUALLY MEANS YOU ASKED FOR IT BADLY.

the model isn't the variable. this whole genre of post works because a bad prompt and a weak model look identical from the outside.

give any frontier model a one-liner and you get the same thing every time: hero, three cards, a stock gradient, a button. that's not the ceiling. that's the default, and defaults are what you get when you don't bring taste.

what actually moves the output:

→ feed it 2-3 sites you love, make it extract the art direction into a style bible first
→ brief the goal, not the steps. one paragraph
→ ban the defaults explicitly. no hero-with-three-cards, no stock gradients
→ set a bar in words: a working designer can't tell this from an agency build

and then the step nobody does. open a second model with fresh context and let it grade the work against that bar. the builder never grades itself. it passes itself every single time.

the gap between "this model can't" and "this model just shipped agency work" is almost always a person who wrote a spec instead of a wish.

[Tim Daugs @TimDaugs]

https://t.co/FtFwiVEO4D

[Tim Daugs @TimDaugs]

NOBODY OPENED BLENDER TO MAKE THIS. THE MODEL TYPED IT.

a car falling through a pink cloud deck at altitude, a starfighter cutting the sky behind it, mountains burning gold on the horizon.

GPT-5.6 drives Blender through MCP. it never touches the interface. it writes python and runs it:

→ volumetric clouds, built as code
→ shaders and emission, written not clicked
→ camera roll, lighting, the whole grade

and the clouds are the flex, not the car. volumetric atmosphere that reads as depth instead of pink soup is what artists lose entire weekends to. it just wrote it.

what it cannot do is look. it built this frame blind:

→ you screenshot the render
→ you tell it the highlights are blowing out
→ it fixes, you screenshot again

for twenty years the price of a shot like this was learning the software. that price is now zero, and nobody's priced in what that means yet.

[explos1ve @explosss1ve]

https://t.co/YDY1uveJ2m

[Tim Daugs @TimDaugs]

FABLE 5 AND GPT-5.6 BUILT A PLAYABLE MECH SHOOTER. THEN THE FIRST BUILDING THEY PLACED BROKE THE CAMERA.

lock-on combat, hardpoints, ammo counters, kill feed, a working score. all systems, all code, and code is the part these models actually own now.

then someone dropped a box in to fake a ruined building. and the whole thing exposed itself.

in a lock-on shooter you're almost never looking where you're driving. camera's tracking the target, chassis is going sideways. so the mech snags the building. the camera snags the building. the fight stops being a fight.

the fix isn't a better model. it's the oldest lesson in level design: cover has to be destructible, or it has to not be there.

the model can hand you a working game in an afternoon. it cannot tell you the level fights the camera. you find that out by playing it.

[Tim Daugs @TimDaugs]

https://t.co/nBehrBg4lj

[Tim Daugs @TimDaugs]

@explosss1ve It looks incredible bro

[Tim Daugs @TimDaugs]

FABLE 5 BUILT A SURVIVAL SIM WITH READABLE OCEAN WATER AND A FULL SEASON/TEMPERATURE HUD IN A COUPLE OF HOURS.

not a screenshot mockup. a running scene.

reflections on the water, a half-drowned timber tower, a clock ticking, temperature at 0.00, day one of spring up in the corner.

the model wrote the systems layer, and that's the part that used to eat a weekend.

the water shader, the HUD state, the day/season clock, the swim controller, all of it is code. and code is exactly what it's good at now.

the water surface is the tell. getting an ocean plane to reflect and catch light so it reads as water, not a blue floor, used to be a tutorial rabbit hole. here it just showed up.

what it can't hand you is whether swimming toward that tower feels like anything. drift, weight, the small dread of cold open water. that's still tuning, and tuning is still human.

the barrier to standing a world like this up basically fell off. deciding whether it's worth being in is the part that didn't move.

[Tim Daugs @TimDaugs]

https://t.co/nBehrBg4lj

[Tim Daugs @TimDaugs]

YOUR AGENT'S BENCHMARK SCORE MIGHT BE MEASURING WHERE IT SAVES FILES, NOT HOW SMART IT IS.

a frozen open model scored 0% on a hard legal agent benchmark. weights untouched, they let a loop rewrite only the harness around it. it ended up matching Sonnet 4.6 at a fraction of the cost per task.

the model was reasoning fine the whole time. it just kept saving the deliverable under the wrong name, in the wrong folder, or not at all. the judge only counts the file when it lands exactly right.

the 0% wasn't a reasoning gap. it was a wrapper bug.

the fix that beat every prompt tweak: a step that drops the output exactly where the grader looks. no extra model tokens.

same model, same tasks, five harnesses spread from 3.5% to 80.1%. the wrapper was the variable, not the intelligence.

you can't tell if the model failed until the harness around it stops failing first.

[Tim Daugs @TimDaugs]

https://t.co/5i0bm4URTV

[Tim Daugs @TimDaugs]

https://t.co/5i0bm4URTV

[Tim Daugs @TimDaugs]

SOMEBODY BUILT A ROBOT ARM TO TAP PHONE SCREENS. THE ARM IS THE TELL.

a gantry, a stylus, a row of phones scrolling short video forever. it looks like the peak of the phone-farm meme.

it's the opposite. a single line of adb does every swipe on that rack in software. input swipe, no motors, no rail, no 3d-printed finger dragging across glass.

so why build the machine? because a software tap is easy to flag, and a physical finger is harder to catch. the arm isn't there to save labor. it's there to look human to something watching.

that's the whole line. the legit version of this never needs a finger. it removes the tapping, keeps the accounts real, and the phones just sit there doing what a person approved.

the moment you're engineering a robot to fake a human touch, you've stopped building a content op and started building the thing platforms hire whole teams to kill.

the phones were never the hard part. pretending a machine is a person is.

[Tim Daugs @TimDaugs]

https://t.co/um7RBnOUfn

[Tim Daugs @TimDaugs]

a wall of phones, a few laptops, and nobody tapping a single screen. the whole operation is a script that fits on one page.

it looks like a click farm. it's closer to the opposite.

a click farm needs hands. someone tapping, swiping, babysitting each phone. this room replaced the hands with code.

adb finds every phone on the wall. one script installs, runs, and records across all of them at once. the guys at the laptops aren't tapping anything. they're deciding what the script does next.

that's the whole shift. the phones aren't the product. the wall just looks impressive. the product is the one page of code that makes fifty screens move in parallel while nobody touches them.

the quotable version: the phones were never the hard part. not touching them is.

a person taps one phone at a time and gets bored by phone six. a script runs the whole wall and never needs lunch. that gap is the entire business.

wrote up how a room like this actually runs, the script and the economics and where it quietly breaks, in the article below.

[Tim Daugs @TimDaugs]

https://t.co/um7RBnOUfn

[Tim Daugs @TimDaugs]

a shelf of screenless phones running 24/7, each one puppeting a woman who was never real.

that's the "AI influencer farm" everyone keeps posting about.

honestly, the tech is the boring part.

one model writes her personality and answers the DMs. another builds a face that stays consistent. a video model makes the photos move. an editor cuts it for tiktok.

keeping the same face and voice across months used to be the hard bit. that's basically solved now too.

so building the character was never the moat.

the whole thing comes down to one move: manufacture a person who doesn't exist, then charge strangers to feel close to her.

and the part nobody screenshots is what happens after.

the buyer isn't paying for photos, he's paying for the belief that someone's there. the day that belief cracks, the whole thing is worthless, and nothing about the tech can stop that crack from coming.

the market floods too, because if a cheap shelf of phones spins up a thousand personas, so can everyone, and attention doesn't stretch to cover them.

strip the hype and it's not really a content business.

it's a loneliness tax with an AI face on it. and that holds right up until the people paying realize there was never anyone on the other end.

the tools are genuinely impressive. what they're aimed at here is the part worth arguing about.

[Tim Daugs @TimDaugs]

https://t.co/um7RBnOUfn

[Tim Daugs @TimDaugs]

a rack of used phones on a laptop does the exact job companies rent from the cloud for thousands a month.

that stack is a device farm. one python script runs all of it.

adb finds every connected phone, installs the app on all of them at once, runs the tests, records each screen. ffmpeg stitches the recordings into a single report showing how the app behaves per device.

the cloud version bills by the minute. a regression run across 30 phones lands around $15, and if you run it on every push, that's thousands a month with no end date.

the shelf flips it. 30 used phones near $60 each, a powered hub, a mini-pc. roughly $2,600 once, then basically electricity.

with active ci it clears its own cost in about a month. after that the cloud keeps charging and the shelf just keeps running.

it also eats the manual grind. a QA engineer plugging in, installing, poking, recording, thirty times over, was a full day. now it's a few minutes and a video report.

the reason this beats the usual "hack" is that there's nothing to ban. it's saved hours and bugs caught before users see them. real work with a real invoice behind it.

owning the hardware is the whole edge. everyone else is renting the same thing by the minute and calling it convenient.

[Tim Daugs @TimDaugs]

https://t.co/um7RBnOUfn

[Tim Daugs @TimDaugs]

50 phones on a rack, and the whole edge is that he owns them while everyone else rents from the cloud.

app testing is a grind nobody wants. every release has to run on dozens of real devices. works on one, crashes on another, and catching that by hand eats a full day.

so the fix is a fleet. a room of phones wired to one machine, running the boring part on repeat.

the pipeline is clean:

→ install the app on every phone at once
→ run the tests in parallel
→ record video from each screen
→ stitch it all into one report with ffmpeg

that part is real engineering, not a trick.

the actual move is the economics underneath it.

cloud device farms bill by the minute. AWS runs about $0.17 a device-minute, so a 5-minute pass on 30 phones is ~$25 a run. do that a few times a day and it's thousands a month, forever.

a rack flips the shape:

→ pay once for used phones and a hub
→ run for years on basically electricity
→ every job after break-even is close to pure margin

a 30-device fleet clears its own cost against the cloud in weeks, not years.

here's the honest half nobody frames right.

a testing farm is not passive income. someone writes the tests. someone fixes the flow when a vendor's android update breaks it. someone talks to the client. the agent runs the grind, not the business.

but strip the noise and the real lesson holds:

when compute gets cheap enough to own, renting it forever stops making sense. the edge was never the automation. it's the hardware nobody else bothered to buy.

[Tim Daugs @TimDaugs]

https://t.co/um7RBnOUfn

[Tim Daugs @TimDaugs]

https://t.co/um7RBnOUfn

[Tim Daugs @TimDaugs]

FABLE 5 BUILT AN INTERACTIVE VOLCANO SIMULATION IN THREE.JS FROM A PROMPT.

a volcanic island, ocean rendering, lava behavior, ui controls, a real-time structure. all wired together and running in a browser.

the demo is cool. the direction under it is the actual story.

this is the shape of scientific visualization getting cheap.

a geophysicist explaining magma flow. a teacher showing why an island forms. a researcher poking at a system instead of reading a static diagram of it.

that stuff used to need a dev team and a grant. now it starts from a sentence.

worth being straight though.

"lava behavior" in a three.js toy is a visual approximation, not real fluid dynamics or a validated physics model. it looks right. it isn't a simulation a scientist would publish from.

the gap between "looks like lava" and "behaves like lava" is the entire field of computational geophysics. a prompt doesn't close that.

but for teaching and intuition, looks-right is often enough.

the win here isn't accuracy. it's that anyone can now spin up an interactive model of a physical system to point at and explore.

we're about to get a wave of visualizations that make hard things clickable. some will be wrong. the good ones will teach more than a textbook chapter.

[Tim Daugs @TimDaugs]

https://t.co/nBehrBg4lj

[Tim Daugs @TimDaugs]

most 2D games fake the wind. this one, built with fable 5, actually simulates it into the animation.

there's a full wind system here. strength, gusts, direction, all wired into the skeletal rig so leaves and cloth react in real time.

that's the tell of someone who knows what makes a 2D game feel alive.

sprites and a sword loop are the easy part. anyone can get a character swinging a weapon.

what separates "asset flip" from "a place you're in" is the stuff you don't consciously notice. wind bending the grass. cloth catching a gust. a physics layer talking to the animation instead of sitting beside it.

the ordering is the interesting tell too. attack animations first, then environment physics reacting live. feel before content.

straight version though: a clip can't show the one thing that decides it, how the glaive feels to swing. hitstop, recovery, weight. that's runtime, and no screenshot carries it.

fable 5 is writing the systems. deciding a duel should feel heavy, and that wind should sell the world, is still the person at the wheel

[Tim Daugs @TimDaugs]

https://t.co/nBehrBg4lj

[Tim Daugs @TimDaugs]

@outsource_ @hermesworldai bro its banger

[Tim Daugs @TimDaugs]

FABLE 5 BUILT A WALKABLE STARSHIP IN THREE.JS, THEN DEBUGGED ITSELF BY STARING AT ITS OWN SCREENSHOTS.

one prompt in. a full explorable ship out.

not a static scene. a place you move through:

→ a working cockpit you can stand in
→ crew quarters
→ a planet drifting past the real windows
→ dynamic lighting that reacts as you move
→ sleep and eat interactions wired in

then the part that actually matters.

it screenshotted its own render, looked at what came back, saw the framerate was wrong, and kept rewriting until the browser held a steady 60fps.

read that again. the model judged its own output and iterated on it.

that's the shift hiding under the demo. writing code blind is old news. what's new is the loop:

→ generate
→ look at the result
→ notice it's off
→ fix
→ repeat until it hits the bar

that's what a real dev does all day. the model is starting to do the boring middle of it on its own.

where it still ends, honestly:

an "explorable demo" is not a game. no goal, no stakes, no reason to come back after two minutes of walking around.

and a screenshot can't feel anything. it can't tell if moving through that ship is satisfying or floaty and dead. game feel is the whole job in a first-person space, and it's exactly the thing a still frame hides.

so no, this isn't shipping to steam next week.

but a self-correcting three.js starship at 60fps, from a single prompt, is not a small thing to wave off.

a year ago this was a weekend for a small team. now it's a prompt and a model patient enough to fix its own mistakes.

the code was never going to be the bottleneck for long. taste is. deciding what's worth building, and whether it actually feels good to play, is still the part that's yours.

[Tim Daugs @TimDaugs]

https://t.co/nBehrBg4lj