Convivy Builder

Convivy Builder

Builder is a way to build software, or any project, with a crew of AI agents that can read what your project is for, what it has decided and what has happened so far. Your first conversation is with the steward, which asks what you want to build and sets up a crew to build it with you.

An AI agent is an AI model, such as Claude, given a role and the tools it may use, and put to work on a task. The steward is the first one you meet, and it explains each part of Builder when your work reaches it, so you can start without having written a program before.

Builder is free and open source, under the Apache 2.0 licence. Its first public release, 0.6.0, is out, and Installing Builder takes you through installing it. The rest of this site describes Builder as it is designed to work.

Install BuilderWhy BuilderSource on GitHubRead Swabby's Journal

From Swabby's Journal

Hi, I’m Jay — the swabby. Working alongside an armada of agentic crews building software and other projects, I spend my own time and effort figuring out what helps them succeed at their tasks. That’s how I ended up creating Convivy Builder. Ultimately, I’m exploring how people can effectively use agentic tools to create new and powerful things.

When I have a moment or two, I write about my experiences here.

LLMs and line cooks

It keeps coming up that LLMs can't be trusted.

Sometimes they solve a problem (typically a coding problem) cleanly, other times they spin and spin trying to get it right. You can ship something 100x faster, or ship nothing after spending hundreds of dollars on tokens.

This is the main challenge we've been tackling since the ground suddenly shifted under software engineering, at the beginning of this year. On one hand, the tools are so powerful when they work that they change the game. On the other hand, when they don't work, it's incredibly wasteful and frustrating. And -- at first -- it can be really hard to predict when they will work.

With time and effort, we're starting to understand it. And it has convinced me that engineers aren't going to be replaced by LLMs; instead, using the LLMs requires its own kind of engineering.

LLMs charged with technical tasks appear to have a lot in common with human technical experts in many fields. Specifically, they thrive when they are given exactly the information they need to complete their tasks, and nothing extraneous to that.

In Big Tech companies, there were (I think not so much anymore after the recent purges) whole groups of knowledge engineers who specialized in this: making it so software engineers would get exactly the information they needed to work, without having to sift through tons of peripheral documentation to get to the relevant items. It was so important for people that these companies invested a lot of money in it.

Based on my own experiences, I've found it helpful to remember that I've already learned this from working with line cooks. They are the core of the restaurant, and technical experts who are usually geniuses of one kind or another. And if I got wrapped up in the details of the larger operation and then started giving them too much context, started calling attention to what was happening in service, or whatnot, I wasn't helping them, I was distracting them and making it hard to focus on the task at hand. But when they received the exact specifications of what their output should be, and nothing more to worry about, that helped them thrive.

So, in terms of "the way we work now", it seems that all of our new processes need to be grounded in this effort. To make sure every task comes with exactly the information needed to complete it, narrowly scoped, and nothing more. This was already needed in key places, and as the LLMs extend into more and more operations, it becomes a core effort.

Earlier entries

You will almost certainly build them

When I first started working in Big Tech, I was surprised at how much of their development tooling was house-made. Version control wasn’t Github, internal messaging wasn’t Slack — except at Salesforce, which notably bought Slack the company — and project tracking wasn’t Jira. Instead the big companies used custom tools they made themselves.

Keep reading

Big is the new small

The ramifications of scaling up coding via agents are pretty interesting.

I do think individual coders can attain massive increases in output of greenfield product work agentically. A single dev can manage, let's say, 5-10 agentic crews working 24 hours a day in separate areas of a codebase. This makes a single engineer into a leader of ~25-50 coders, with output increases to match.

Keep reading

A new problem space

I mentioned in an earlier post that, as a developer working in their spare time to make production-grade software, agentic engineering increases my effectiveness around 50x over hand-coding.

Mature engineering organizations aren't seeing those types of gains for a multitude of reasons which are mostly easy to suss out. I think the current rule of thumb is that mature organizations are seeing gains on the order of 25% as a first step if they can effectively introduce agentic development. Which seems like it might not be worth it, when you're also, to some extent, giving up control of the your code to a robot.

Keep reading

All entries in the journal