In just 4 months, this “rookie” developer burned through 3 billion tokens—built 50+ products and drew 3.6 million views

For a long time, the gates of the coding world seemed to open only for a select few—those who had mastered the “secret arts.” We were told that before we could create anything, we had to understand memory, memorize syntax, and grind through endless documentation.

Today, large language models are changing that story. Programming is no longer a test of endurance. It’s starting to feel more like a real-time strategy game—one where people learn to work side by side with AI, and build in a more direct, more essence-first way.

Ben Tossell, Head of Developer Relations at Factory, is one of those people. He doesn’t consider himself a strong coder. And yet, over the past four months, he has burned through 3 billion tokens.

That means minute by minute, second by second, he’s been watching AI agents write complex code through a terminal window—code he says he could never have produced alone.

Beyond “Vibe Coding”

Some dismiss this approach as “vibe coding,” but Tossell argues the phrase carries an unfair, almost elitist bias. To him, it echoes the stereotypes people attached to “no-code” back in 2019—ironically, the same year he founded a no-code education company that was later acquired by Zapier.

In his view, that bias ignores the real skill underneath: orchestration. In this new paradigm, technical ability is measured less by whether you can recite syntax from memory, and more by whether you can direct systems effectively.

From a no-code pioneer to a 3-billion-token operator, Tossell’s story points to a bigger shift: in the AI era, the most valuable “pass” into the world of software isn’t a traditional background—it’s the instinct to explore.

To document what he learned, Tossell published an article that has now surpassed 3.6 million views on X. Here’s what he shared.

What He Actually Shipped

Yes—3 billion tokens is a lot. But Tossell says he got tangible output in return, including real products and internal tools.

A personal website redesign
He rebuilt his personal site to look and feel like a terminal-based CLI interface.

Feed: a lightweight social tracker
He created a simple tracker that monitors subreddit posts and GitHub issues. It’s open source, earned over 100 stars, and has been cloned by plenty of people.

Factory Wrapped: from prototype to production
He built the first version of “Factory Wrapped,” demoed it internally, and the team liked it enough to integrate it into the actual product—where it’s now live. He also added new guides and reorganized content. It may not look like “traditional coding,” he says, but the building process was the same: plan, execute, iterate.

Custom CLI tools for the team
He made internal command-line tools, including a “Pylon CLI” the team uses to help process customer support requests.

A crypto tracker powered by prediction signals
Tossell invested in a company that predicts positive, negative, or neutral signals from dynamic datasets like finance, weather, fitness, and protein folding. He used those predictions to build a crypto tracker that automatically opens and closes long/short positions—essentially a miniature hedge fund system.

Droidmas: a 12-day experimentation sprint
A series of experiments or “game levels” based on themes people were discussing on X—memory, context management, vibe coding, and more.

An AI-guided video demo system
Give it a prompt, and it generates a video. The system acts like its own director, producer, and editor: it records in real time, reacts to what happens, waits when necessary, and handles issues like bugs and delays. Tossell used it to create a video that OpenAI later shared publicly.

And beyond these, he built around 50 other projects—some of which he abandoned along the way.

Why He Works Fully in the Terminal

Tossell’s workspace isn’t a glossy UI. It’s the CLI.

He prefers the terminal because it’s fast, direct, and transparent—you can see what’s happening as the system works. Whenever he has a new idea or hits a problem, he starts a fresh project inside Droid (Factory’s CLI). He chats with the model a few times, provides context, then switches into a spec mode to create a build plan.

In spec mode, he asks relentlessly practical questions:

What is this?
Why do we need this instead of that?
Couldn’t we do it another way?

Then he moves into execution. He runs Opus 4.5 in a high-autonomy mode, watches what happens, steps in when errors appear, and finishes by testing, giving feedback, and iterating.

The Role of agents.md: His Operating Manual

Tossell spends a surprising amount of time refining one thing: his agents.md.

For him, it’s essentially the playbook.

He keeps a local repos folder where all coding projects live. Inside it is an agents.md file that defines how every new repository should be set up: what to do, what not to do, how to use GitHub, how to commit, and whether to use a work or personal GitHub account.

One key change: he now prioritizes end-to-end testing far more than before.

Given his current level of knowledge, he sometimes discovers “basic” bugs later than he should. With testing baked in early, many of those issues would have surfaced sooner. He also regularly reads other people’s agents.md files, borrowing ideas and continually improving his own—because better documentation makes every future session smoother.

What He Learned Along the Way

CLI over MCP (most of the time)
He has used MCP before, but now tends to prefer CLI workflows because they feel simpler and more efficient. For tools like Supabase, Vercel, and GitHub, he consistently chooses CLI.

He builds CLIs for his own needs
For example, he created his own Linear CLI so he can query issues and execute tasks from the terminal instead of switching to web or desktop apps.

Bash finally clicked through repetition
While working on changelogs, he began to truly understand how Bash commands fit together. He had Droid create a slash-command workflow—his first “proper” multi-step command pipeline. It runs several Bash commands and prompts the model to perform specific checks, like reviewing GitHub diffs, verifying feature flags, or placing new features and bug fixes into the right sections.

VPS became real, not abstract
He always knew a VPS was basically “a remote computer that runs 24/7,” but didn’t really grasp its value until he needed it. Now he uses a VPS to run the crypto tracker continuously, pulling minute-by-minute data while staying always online. He also relies on it for a Droid Telegram bot, syncing local repos to the VPS via SyncThing so everything stays current and he can pick up exactly where he left off.

A New Programmable Abstraction Layer

A tweet by Andrej Karpathy resonated strongly with Tossell: we now have a new abstraction layer to learn.

In the no-code era, the abstraction layer was drag-and-drop tools like Webflow, Zapier, and Airtable—stitched together to resemble “real software,” until you hit their limits.

Now, the challenge isn’t “learn to code from scratch before you’re allowed to build.” The real skill is learning how to collaborate with AI:

How do you prompt it well?
How do you maintain the right context?
How do you connect the pieces into a coherent system?
How do you keep improving that system over time?

To sharpen that skill, Tossell reads posts by experienced developers like Peter Steinberger. One thing that struck him was the simplicity: talk to the model, and make it do the work. That insight boosted his confidence—he didn’t need a complicated setup to be effective.

He also notes that on X, many people constantly optimize their systems—sometimes to the point of over-optimization. That can feel intimidating, but he thinks it’s also the magic: the system is fully customizable. You can run a structured “planning mode,” or go direct and conversational. Both can work.

The Power of “Stupid” Questions

People often have questions that sound naive—questions veteran engineers stopped asking a long time ago.

For example: if frameworks exist to make human work easier, and LLMs are now so capable, why not abandon heavy frameworks entirely and let models generate pure, dependency-free code? Wouldn’t that reduce bugs and maintenance?

Over time, Tossell realized it wasn’t a dumb question at all. Frameworks aren’t just tools—they’re shared conventions and ecosystems. And LLM intelligence is shaped by training data, much of which is rooted in mainstream frameworks.

That’s how his understanding evolves: by asking fundamental questions and letting the answers rebuild his mental model. Where he once felt like an outsider to the engineering world, he now feels he’s actively joining it—one question at a time.

Rethinking “Vibe Coding”

Tossell thinks the term “vibe coding” misses the point. What’s happening isn’t just intuition—it’s deep system understanding: dissecting logic, improving structure, and shaping workflows.

He doesn’t want to call himself “non-technical,” but he also doesn’t feel the traditional label “programmer” fits. He sees himself as an explorer in a new, still-unnamed category.

To him, programming now feels like a real game—one where ideas can be tested immediately, and every curiosity can be explored deeply. Perfection isn’t the entry requirement; learning the system is the real objective. Not every experiment needs to ship on GitHub. Sometimes code is just a signpost pointing deeper into the system.

That spirit—building not just to produce, but to understand—is what he values most.

Faster Feedback, Lower Emotional Cost, Bigger Output

Tossell used to see learning to program as a heavy investment. If you worked hard to prototype something and nobody cared, it was painful to let go—because you’d already sunk so much time and emotion into it.

No-code changed that for him: you could build in a weekend, test quickly, and drop it if the market didn’t respond. Low cost made it easier to move on.

AI accelerates that feedback loop to near light speed.

He believes we’re approaching a software “big bang.” Yes, there will be a flood of mediocre work. But there will also be an explosion of remarkable projects—especially as experienced developers ship open-source tools at unprecedented speed. That creates an endless parts factory: clone, tweak, remix.

Compared to starting at the bottom with file I/O syntax drills, outcome-driven recombination is dramatically more efficient. Feedback is instant. Output is continuous. You don’t have to overthink the starting line—you have to keep trying and colliding with reality.

His Final Takeaway

In this paradigm, ideas aren’t heavy burdens. They’re probes you can throw out at any moment.

Tossell is convinced that anyone who wants to enter the technical world can do it. You don’t need a computer science degree. You need permission to play.

Treat coding like a game: spin up a CLI agent, tell it you want an RSS tracker, a fitness app, or a personal website—and press start.

You’ll hit plenty of bugs. But that’s not the punishment; that’s the best part. Instead of feeling defeated, you get curious: why did this happen?

Even experts fight bugs daily. The difference now is that you can bring a “council” of models—ChatGPT, Claude, and others—to examine the problem from multiple angles and choose the best path forward.

His rule for navigating the tool jungle is simple: fastest, simplest, furthest.

Pick one tool. Go deep. If something is missing, try building it yourself.

As Tossell puts it: this has been a huge, genuinely enjoyable learning experiment—building constantly, failing forward, and repeatedly pushing new things into the world.