zob

all-seeing dev

[zob @ripZ0B]

https://t.co/jZFFZ5Jd9d

[zob @ripZ0B]

@WiPRenaud

[zob @ripZ0B]

Coding agents are becoming teams.

Not just one chat.
Not just one assistant.

Multiple agents can now explore, plan, implement, review, communicate, and run in the background.

I’m building an agentic control plane in public to explore what that future looks like.

[zob @ripZ0B]

Still a work in progress.

I’m building it by using it, improving orchestration, communication, context continuity, guardrails, and factory workflows as real agent work breaks.

If coding agents become teams, we’ll need systems that manage them like teams.

[zob @ripZ0B]

Principle 6: workflows become factories.

When a pattern repeats, it should become reusable:

manifest → checkpoints → smoke → pilot → batch → evidence-backed output

That’s how repeated agent work becomes infrastructure.

[zob @ripZ0B]

https://t.co/edsk9BxX3u

[zob @ripZ0B]

Today I’m starting to show what I’ve been building: Cepage.

Cepage is a graph-first skill compiler for coding agents.

Not another agent.
Not another orchestrator.

The idea is simple:

Coding agents are getting very good at doing work once.

But the best runs often disappear into chat history, terminal logs, or one-off diffs.

Cepage captures those runs and turns them into typed, reusable skills that can be composed visually on a canvas.

It already connects with OpenCode, Cursor and Claude Code.
Local-first, MIT, pre-alpha.

I’m sharing it now because it finally feels useful enough to be used, broken, and improved by other builders.

And with more builders getting access to serious AI coding credits, now feels like the right moment to build the layer around the agents.

If you’re building with coding agents and repeating the same workflows again and again, I’d love your feedback.

[zob @ripZ0B]

The bet behind Cepage:

Agents will keep getting better.

But teams will still need a way to capture what worked, reuse it, and compose it into reliable workflows.

Agents write code.
Cepage turns good agent work into reusable building blocks.

Early builder feedback welcome.

[zob @ripZ0B]

anyone else just got hit with a random kimi code reset? On my Allegretto sub my 5 quota straight up dropped outta nowhere with zero warning 😭 Am I tweaking or is this bugging for y’all too?

[zob @ripZ0B]

I've been using the GLM sub for months whenever I'm out of credits, and honestly it's really not great.
As soon as you push a bit past the context limit, everything goes to shit, the model becomes completely unpredictable.
Plus it doesn't even take full advantage of Cursor's features like Composer 2 or GPT-5.4 do. It's almost like it's done on purpose...

[zob @ripZ0B]

What if countries that actually want to stay ahead built AI-driven governance: fully custom tools, minimal bureaucracy, scale with fewer citizens?

Small states could leapfrog. Larger ones… maybe not.

Slowly, then suddenly.

[eric zakariasson @ericzakariasson]

off-the-shelf software in a world where everyone can build

as autonomous companies start emerging, they will have far fewer employees than companies do today. with many employees, you need many customers to hit economies of scale. with fewer employees, that’s no longer the case. customer count becomes a useful proxy for complexity.

this assumes software engineering is a somewhat solved problem. not perfectly, but enough that building software is increasingly cheap and repeatable. this is also jevons paradox at play - as software becomes cheaper to build, more of it gets built.

building software that solves operational needs like internal comms, sending emails, competitive analysis, or customer support is usually trivial, but becomes difficult once you need to support it at scale. scale, in this framing, is mostly about customer count.

if you can hit economies of scale with fewer customers, building your own software suddenly becomes viable. operational complexity becomes a much smaller problem, and you gain the ability to customize and tune the software to your exact needs.

most off-the-shelf software is a compromise around the most common customer needs, and the long tail of infrequent requests is not served. if you opt out of ots, you no longer have this constraint.

this obviously won’t apply to every business. and it won’t happen overnight. but it will happen sooner than people realize.

if i were building ots software, i’d start thinking about which primitives you can offer to the market. for example, if i’m building an email-sending platform, how do i make it as easy as possible for people building their own software to do this? how do i increase the incentive for using a headless, composable platform?

of course, all of this should be taken with a grain of salt

slowly
then suddenly

[zob @ripZ0B]

@shaoruu not yet

[zob @ripZ0B]

Why can't I yap anymore @cursor_ai ? 😭

[Cursor @cursor_ai]

Turn speech into code with voice mode.

[zob @ripZ0B]

@thekitze just gave a talk, “From Vibe Coding to Vibe Engineering,” that perfectly captures the shift I’ve been describing.

Stop blindly accepting whatever the model outputs. Start engineering: constraints, context, and supervision.

We both use voice-to-text. I just whisper to my IDE instead of ranting at it.

https://t.co/ljnUF6EEbp

[zob @ripZ0B]

Stop prompt engineering. Start conversation engineering.

After 1,300 hours building with LLMs in @cursor_ai , I have good news and bad news.

Bad news: the perfect one-shot prompt does not exist.
Good news: you don’t need it. Real leverage comes from how you talk to the model over the next 5, 10, 20 messages.

These models aren’t magic terminals that spit out flawless code. In practice, they behave like ultra-fast junior devs dropped into an unfamiliar codebase, sounding confident long before they actually understand what’s going on.

I ran a script on ~30,000 Cursor chats:

- 31% bundled multiple demands (analyze, refactor, fix)
- 43% started with a giant cold ask
- only 11% began with a modest “explain this file”

The model wasn’t dumb. My conversations were.

One-shot prompts work for tiny, surgical tasks: “write a regex,” “extract these fields.” But the moment you cram a multi-service feature or entire architecture into one prompt, the illusion collapses. You don’t need a better spell, you need a better conversation.

Concrete example: a Discord tournament bot with team registration, waiting list, and leave button. I dumped all rules and edge cases into one massive prompt. The agent replied confidently. I wired it up, clicked “leave,” and every team vanished.

The fix was a funnel of tiny messages:
1. “If the player is only on the waiting list, remove just them.”
2. “If they’re in a registered team, remove them and promote the first waiting team.”
3. “If the list is empty, here’s the bracket-shifting logic.”

Same pattern beyond code: I brain-dump messily, then ask the model to question, compress, and reshape until the idea survives outside my head. Clarity comes from talking, not from perfecting the prompt box.

Voice input is a cheat code too. In Cursor, I rant for a minute about my broken Next.js setup: VPS, Traefik labels, Docker Compose, weird prod logs. The model doesn’t care if it’s messy or half in French; it turns the rant into a plan.

You must also learn to say “no.” Agents love adding new services, files, abstractions. Push back:
“No second service, update the existing one we have.”
“Three lines of comments max.”
“Do not rewrite history; use a new branch.”

We’re moving from text editors to control rooms. Most of my code is no longer typed by me, I read, guide, adjust. I decide what the code should do and, more importantly, what it must not do. Conversation is the interface for that orchestration.

That’s conversation engineering:
- Ask the model to question you before writing code.
- Narrow scope on every reply.
- Say “no” when it drifts from your patterns.

Tomorrow in your IDE, try:
“Ask me questions before you start coding.”
“Shrink scope to only handle X for now.”
“Do not touch other files, stay inside this module.”

If your first agent session feels disappointing, the answer is rarely “this model is bad.” It’s almost always “this conversation isn’t finished yet.”

The work isn’t finding a magic spell. The work is learning to talk.

[zob @ripZ0B]

@karanjagtiani04 @cursor_ai Totally agree that structure helps, especially for bigger projects. But for me the real leverage is training yourself to think and speak clearly. If you know what you want to say and why, even a simple chat becomes very effective.

[zob @ripZ0B]

Stop prompt engineering. Start conversation engineering.

After 1,300 hours building with LLMs in @cursor_ai , I have good news and bad news.

Bad news: the perfect one-shot prompt does not exist.
Good news: you don’t need it. Real leverage comes from how you talk to the model over the next 5, 10, 20 messages.

These models aren’t magic terminals that spit out flawless code. In practice, they behave like ultra-fast junior devs dropped into an unfamiliar codebase, sounding confident long before they actually understand what’s going on.

I ran a script on ~30,000 Cursor chats:

- 31% bundled multiple demands (analyze, refactor, fix)
- 43% started with a giant cold ask
- only 11% began with a modest “explain this file”

The model wasn’t dumb. My conversations were.

One-shot prompts work for tiny, surgical tasks: “write a regex,” “extract these fields.” But the moment you cram a multi-service feature or entire architecture into one prompt, the illusion collapses. You don’t need a better spell, you need a better conversation.

Concrete example: a Discord tournament bot with team registration, waiting list, and leave button. I dumped all rules and edge cases into one massive prompt. The agent replied confidently. I wired it up, clicked “leave,” and every team vanished.

The fix was a funnel of tiny messages:
1. “If the player is only on the waiting list, remove just them.”
2. “If they’re in a registered team, remove them and promote the first waiting team.”
3. “If the list is empty, here’s the bracket-shifting logic.”

Same pattern beyond code: I brain-dump messily, then ask the model to question, compress, and reshape until the idea survives outside my head. Clarity comes from talking, not from perfecting the prompt box.

Voice input is a cheat code too. In Cursor, I rant for a minute about my broken Next.js setup: VPS, Traefik labels, Docker Compose, weird prod logs. The model doesn’t care if it’s messy or half in French; it turns the rant into a plan.

You must also learn to say “no.” Agents love adding new services, files, abstractions. Push back:
“No second service, update the existing one we have.”
“Three lines of comments max.”
“Do not rewrite history; use a new branch.”

We’re moving from text editors to control rooms. Most of my code is no longer typed by me, I read, guide, adjust. I decide what the code should do and, more importantly, what it must not do. Conversation is the interface for that orchestration.

That’s conversation engineering:
- Ask the model to question you before writing code.
- Narrow scope on every reply.
- Say “no” when it drifts from your patterns.

Tomorrow in your IDE, try:
“Ask me questions before you start coding.”
“Shrink scope to only handle X for now.”
“Do not touch other files, stay inside this module.”

If your first agent session feels disappointing, the answer is rarely “this model is bad.” It’s almost always “this conversation isn’t finished yet.”

The work isn’t finding a magic spell. The work is learning to talk.