Why I built Descant

I left Boulevard last year in November without a real plan, but we had a project in flight we thought had potential: TriviaPot, real-time live trivia matches playing to win cash. You pay an entry fee, there is a pot based on the size of the game, the winner takes all, and a percentage of the pot goes to us as a platform fee.

We built out a fully working web app version for testing, with no real money. Games had bots in them to fill out the games, and with all the trivia AI-generated, it was unlimited. You could do custom games as well and get trivia on Mario Kart or knitting or technical terms for NSFW words or the wonderful world of hardwood floors—literally whatever. It would generate trivia based on a rubric, score it, and validate it with a different model. It had some software checks in there, too, to make sure the answer didn't end up in the question or hint and to check the overall rubric score. Multiple models needed to validate the correctness of the answer, which software checked to be sure it was all passes—that kind of thing. The trivia would pass or get thrown away.

We sent it out for testing and had some positive feedback, but not enough sticky engagement, and plenty of things that we could change. Satisfying the legal and compliance requirements for the real cash gaming aspect was a capital and resource investment that didn't seem worth it for a game that, by itself, just didn't seem fun enough to come back and play. Instead of ditching the project entirely, we continued to work on it on the side, completely revamping the gameplay to layer in multiple in-game currencies, an in-game currency store for buying upgrades, power-ups, multipliers, reactions, daily quests for bonus currencies, multiple-choice answers (you used to type the answer), and all players funneling into one matchmaking system. The idea was to see if we could make a game that was good enough to draw in players without the real money aspect, build it native, get it in the app store, and, if we got traction, decide if the traction was worth the further resource commitment to pursue a real money gaming version.

Meanwhile, with the rapid advancements in AI and agentic coding, we wanted to test a hypothesis that was now only possible given the speed at which we could build out MVPs: if someone, a business or person, has a real painful problem worse than just an inconvenience and we build a product that solves their problem, there are enough people with the same problem to sustain a profitable business, even if not a significant bottom line. The new speed to MVP significantly reduced the risk and would make it a repeatable pattern. It would look more like a large portfolio of micro-niche products that collectively would generate significant net revenues, with a chance of discovering a problem a lot of people have that then becomes the primary focus.

We still couldn't build fast enough to really test this hypothesis. The AI slop code, prompt-only coding (e.g. vibe coding), and how necessary it was to still be deeply in the loop on the work prevented this from being a reality. There are a lot of people out there who disagree, and I will confidently tell you I think they are wrong. People with no software engineering experience don't know what they are missing, and that by itself is tremendously dangerous. People who are skilled software engineers do know there is still a lot to build, even for an MVP to be safe and stable enough. If you still are like, “Hey, we got this up in 5 days and it's fully production-ready,” your idea wasn't that ambitious. That's not a knock; it's smart to start small and make sure what you build is solid. But for the problems we were trying to solve, the small unit, the MVP, was still big. We are testing a hypothesis in which I don't come up with any ideas.

To support the level of ambition we had, I started developing a lot of custom tooling around developing code with AI, the first part starting with how to solve the quality problem—like really solve it. Depending on someone's nature and recent experience, they might say that the frontier models are already good enough, and I disagree, not on opinion but proof. Very good, yes; consistent staff+ level quality, not even close, not even remotely close. I needed excellent every time, over thousands and thousands of pull requests.

Once quality was in a good spot, we needed to solve all of the other complexity that comes with operations and dynamic manufacturing lines: assembling complex components together in the right order, sometimes with a sprawling dependency graph, over long horizons of long horizons that adjust to variability, where the edges don't crumble and big gaps aren't left behind. Most important, it needed to be safe, trusted software. Not just because we needed to rely on it, but because our customers relied on us, even if starting with only one customer per product. MA2H, OH HAI, and Issuegraph were all born out of this very difficult problem to solve for coordination and communication in ever-changing complex environments at scale, in a way that's so reliable that trust becomes automatic.

When it all came together and was working relatively smoothly, I was excited to show my friend, who simply said, “Well, that's your product.” That immediately felt like the most obvious thing that just didn't occur to me. That version became Descant's first prototype, which shipped over 20K PRs in a matter of months (not joking, look at my GitHub contributions) before we had the production version fully built.

So we had mountains of data with over 100 million tool calls and full transcripts. We knew very precisely where mistakes were made, what tools mattered, what didn't, where tokens were spent and had little to no impact, and where work degraded when running autonomously for weeks. We saw cruft build up, tech debt emerge, how gaps formed, where models made repeated mistakes, and the correlated data between prompts given and actions [not] taken. We saw where and what prompts could be trusted more than others (spoiler alert: never trust prompts; prompts are not contracts—they are seeds, more on this later). We had a roadmap for how to improve and often eliminate these problems. The result is something that is still pretty mind-blowing to me when I use it now.

An early benchmark on SWE-bench Pro scored 86.46%, where the underlying models being used (Descant, as of now, uses multiple models—also more on this later) collectively scored a 62%. At the time, the top spot was held by Mythos 5 with an 80.3%. I was shocked and excited, probably too excited, because Descant wasn't designed to optimize for single-model quality, and I started making the story about the bench score.

Descant's quality is designed around a consistently high bar that can be trusted autonomously over thousands of issues or more. Descant genuinely improves in a way that is measured and repeatedly tested and optimized, and is a meaningfully positive steward of the project—leaving code better than it finds it. This happens through follow-ups to keep scope tight, which Descant will then automatically pick up and run through a new pipeline in parallel if possible, but often serialized with the existing work to avoid conflicts and rebases. Those are one of the biggest sources of waste and something thoughtful coordination can eliminate, not just with Descant but with people teams, too. Descant also grooms issues related to the work and its edges that might have been impacted, and keeps learnings up to date, not letting a once-useful document become stale and a faulty direction for future engineering, whether by Descant or a person.

Descant is designed around professional work. It brings the best version of itself every time, and that consistent high quality is what establishes the trust and makes full autonomy possible. It just so happens that if the best a single model can bring is a B some of the time, Descant will end up bringing a B+ or an A because of what we've learned around error de-correlation and getting models to think differently to avoid repeating the same mistakes. And it will bring that B+ or A every time. To be clear, I am not a researcher—we've simply backed into the relevant research and its understanding by iterating over this process now over 250,000 times. Fun fact: the name Descant is an acronym of different methods that inspired its design or are applied to Descant directly.

While I think the benchmark scores are actually more harmful than helpful to Descant, I still publish the score because there needs to be at least one succinct, quantified way to express the capability/quality of at least one of the multiple dimensions of Descant, like the most recent 82.3% on DeepSWE v1.1. This is just for you to stick around to read more or reach out to have a conversation. I never want someone to make a commitment to Descant on a bench score alone. It's just one signal. You should get to truly see and experience the quality. This is something we need to figure out and are always working on or thinking about. Currently, there is no benchmark designed to truly test what Descant is uniquely capable of, and it's hard for us to create our own benchmark that no one else runs and be the only one that is good at it. It's like playing Monopoly with a little kid who you let make the rules.

I've never enjoyed being an engineer more than I do now, specifically with Descant. Compare that with writing code through unstructured prompting alone: that was the opposite for me. I disliked it much more than crafting code by hand. Handcrafting code and perfecting it line by line, to me, feels like what Japanese woodworking, specifically Kigumi (木組み), looks like. That kind of care over the work and, on the Japanese theme, Takumi (匠) and a lifelong dedication to the craft is something I enjoy very much (not putting myself on the same level as a master takumi, just saying I enjoy the dedication to constantly improving and crafting code).

Unstructured prompting is the opposite. It's sloppy, loses the detailed refinement, and, even though it produces a lot more code faster, leaves me disconnected from the code in a way that just feels bad. Objectively, it seems wrong, too. Some of my closest friends and former colleagues, whom I would put on the level of a takumi master, are disciplined about their craft. For them, unstructured prompt coding isn't necessarily a massive boon in productivity. There is more time cleaning up than crafting. And it matters when they are building some of the most heavily used software and infrastructure in the world. Single lines can matter a lot there. Even well before AI coding, there was no shortage of stories where single lines resulted in significant platform and internet outages.

With Descant, the thing that I know, and that hopefully many people and teams will experience and come to appreciate, is the level of effort that has gone into bringing craft and discipline to what Descant creates for you. Complete thinking for the problem space; specific areas of research we know from our data correlate to better outcomes; thoughtful and precise planning; additional focus on areas we know are consistent problems, like integration seams; behavior-in-essence red-first checks at those boundaries (think BDD at integration points, but the tests live in the unit-test framework); the acceptance criteria and requirements enforcement; maintaining strict execution ordering through Issuegraph (born out of necessity); structured review that is verified, with every change looking to reduce complexity—complexity we quantify and verify. And that's not all of it.

The precision that I know is there makes me love building with Descant, because the precision isn't just a prompt. Yes, we use prompts and carry that precision through as schema-validated data, and that's enforced in execution or used to verify model assertions. There are efforts in every permutation and at every level to act with professional engineering discipline, to craft the outcome. I can name more things, but I won't because it's a lot and, yes, it all matters. The data showed us what resulted in consistent quality or improvements in the outcome. When thinking about smaller units of work, the parts of the system that right-size the effort are particularly helpful when it comes to cost. A quick helper function does not need all of the things.

And it can be done at scale. That's why I love it—the impact, while still building with a system that enforces professional, disciplined engineering that upholds craft pragmatically, instead of my time being consumed by unstructured, inconsistent prompting and results in what felt like a forced attempt to be more productive. You might find that hypocritical, and I wouldn't disagree with you. I'm talking about my care and enjoyment in crafting code, yet having Descant handle the implementation fully autonomously. That's pretty close to a perfect example of hypocrisy. But I see it a different way.

I am getting back to crafting and doing it at a higher level. Refining system architecture, subsystem designs, iterating on technical design, and exploring design patterns and applying the best fit for the use case feel like my new version of writing crafted lines of code. I can apply creativity more than I've ever been able to in software engineering. It's such a bigger playing field with so many more possibilities that can be met with engineering that scales and a level of quality I feel good about—because Descant is crafting.

You might feel differently because the code is not perfection, but Descant isn't claiming to be a master crafter. Many of us who have been coding our entire careers, maybe even since we were kids, and have never stopped working to improve still don't call ourselves a master crafter and probably never will. I certainly don't and won't. Descant isn't either, especially because it's just getting started. We are just getting started. And we are dedicated to Descant's craft, constantly testing and looking at data both manually and automatically to inform continuous improvement.

Designing purely at the architecture, systems, and patterns level and delegating implementation to a fully autonomous system is a different way of working. For me, the leap from handwriting code to prompt-driven development was much smaller than the leap from prompt-driven engineering to fully autonomous implementation. And it's been one of the greatest joys for me as an engineer. I hope it is for you and your teams, too.

Descant is largely thought of as a harness, and it is, partly. I see it as only 1/3 harness, with the harness being, as of the current moment in time, simultaneously the most critical and the least valuable part. As models continue to improve, less and less of the harness will be needed. And the sooner we can get rid of that part, the better, because it limits what is possible with Descant, like building backwards compatibility for the things the model can't yet do for itself.

The other two parts are structure (shape, tools, operations, information, instruction, purpose, process, levers, capabilities...structural things) and the output shape. These have nothing to do with model intelligence; they are complementary to intelligence. In fact, intelligence can't do anything without them. That seems weird to say because when we think of model intelligence, we think of models with many of the structural components, not without them. Just like we don't think about what a carpenter can't do without their tools—in sticking with the woodworking references.

More advanced models will be able to start instantly creating many of these structural components based on the ask. What's left are things like information, instruction, and purpose, which are really all different types of information. No matter how intelligent models become, even like ASI level and whatever comes after that, intelligence cannot replace missing information. It can research, investigate, and synthesize information, but it cannot create missing information. With instruction and purpose as types of information, they are critical components.

Descant already has a lot of these components. We continue to improve them, and they are directly responsible for Descant's delivery of consistent, high-quality results. This is the part of the system that enables scaling and the ability to do a 1-year migration in a weekend, which still requires a well-crafted technical design to break down dependencies and allow for the kind of concurrency needed (think hundreds to thousands of PRs at a time every 2 hours).

The third part is the output shape, which, put plainly, is the impact potential. Descant's potential impact is limited by the need for a substantial harness, which is mostly focused on raising the floor and elevating the models. Descant's full potential will start to be realized when we can focus that energy and dedication on raising the ceiling and continuously push the limits of next-generation models.