Wes McKinney is the founder of Kenn Software ↗, the creator of pandas, and the co-creator of Apache Arrow. He went from an AI skeptic writing code in Emacs with no autocomplete two years ago to not writing code by hand at all. At API rates, his last 30 days of coding agent use would have cost $60,178.
Listen in to hear how Wes, a top 1% developer, has architected his tech stack to get the most out of coding agents and work around their failure modes.
Wes says agents are letting his team build far more software than they ever could before, but it comes with a lot of frustration. He makes the case that the frontier labs have little incentive to make their models write less code, since the more bloated the code base, the more tokens it takes to maintain. In his experience, 70 to 80 percent of agent turns introduce a bug, so agents can't be trusted to act on their own and every piece of work has to be double-checked. His team built accountability into the loop: they have agents commit after every single prompt, review each commit with roborev, and use AgentsView to track exactly where their tokens are spent. They even wrote and open sourced a Clanker Constitution, a set of house rules that bans agents from writing walls of text or spending tokens on work nobody asked for.
We also get into which engineering skills still matter when agents write the code, why GitHub keeps going down, and what a developer's job might look like in 2050.
I think on the whole, it feels like we're making more progress and we're able to build a lot more software than we ever could before, but it's coming with a lot of frustration because it requires constant vigilance. I think Mitchell Hashimoto just said on his Twitter, it's like a reminder to stay frosty at all times because the agents can't be trusted to act in an appropriate manner in any given project. So the work has to be double checked.
Welcome to the Main Branch podcast. This is your host, Cagla Kaymaz. Main Branch is a show where I talk to founders and early adopters about building, deploying, and scaling world-class AI startups.
Hi Wes [McKinney], welcome to the podcast. Thanks for joining me.
Hey Cagla, thanks for having me.
Your work as the creator of pandas and co-creator of [Apache] Arrow is very well known, and you're obviously legendary in data circles. But as of this year, your work shifted from data infra to developer tools, and now you have a startup called Kenn. Since your prior work is very well covered in podcasts and conference circles, today I want to spend this more focused on your more recent work.
So let's start with your journey as an AI developer. Back in 2024, I think you were a self-proclaimed AI skeptic. What changed?
Yeah, I mean, actually, I had LLMs and OpenAI and a lot of different terms muted from my Twitter timeline back when it was still — I think it was maybe starting to become X at that point, I can't quite remember — but I was pretty tuned out of AI because I was skeptical that it would really reach a point where it would start to affect my work. It wasn't until the release of Claude Code, which is early last year — I think March, April last year — when I started to dabble and it's like, okay, let me give this a try to work on some nontrivial problems in large code bases. And I started to have success and I was really surprised. Obviously it was pretty rough and it needed a lot of work to be able to do anything real at that point with a lot of handholding and guardrails and there was a lot of sycophancy and issues, but I saw really promising results, and that led me to continue to experiment and go down the rabbit hole.
But prior to that, honestly, I never paid for Cursor. I dabbled in AI autocomplete. I was basically using Emacs with no tab completion or any language intelligence in Emacs up until the switch to terminal coding agents. So I went from being a caveman programmer in Emacs with no assistance at all for 20 years to suddenly not writing any code and just using Claude Code and now a mix of Claude Code and Codex to write absolutely, absolutely everything. So definitely a big transformation. As somebody who has ... I've founded a number of companies, I've founded a bunch of open source projects, I've worked on some very large code bases, built some very big projects from scratch. I think what has intrigued me about AI is how to build tools and systems to create very large pieces of dependable production software using AI, which is a little bit of a dark art right now and there's no consensus about the right way to do it.
But I think for me, the real intellectual curiosity is to use the tools to build big software and discover along the way what works well, what doesn't work well, and then build. I started out basically building tools for myself to make myself more productive. And then at a certain point I was like, okay, I should create a company that is dedicated to this mission of engineering productivity in the future with AI. There was a lot of different pieces to going down the rabbit hole, but it started with being a systems builder and being really passionate about the practice and craft of software engineering, software architecture, building big systems from having built big systems in the past. And I want to continue to build systems and make things that are large and dependable. I think it's really important that folks who've built large, important pieces of software in the past really put their heads together to figure out, okay, how do we do this with AI now?
Because if the agents are writing all of the code, how do we create the right kind of guardrails and the right kind of accountability loops not only for yourself, but also for the agents to keep things moving forward in a productive way and not drown in an ocean of slop, which seems to be the default path for most projects these days.
Yeah, for sure. Also, it's so funny you mentioned Emacs. I don't think I've used Emacs since junior year of college or something like that.
Yeah, I've got the "claw" — the Emacs claw — from doing all of those ... The muscle memory of pressing all of those shortcuts. I know there's going to be a lot of haters that are like, "Oh, gross, an Emacs user! Vim, the one true editor." I think it's fine. It's just about what you get used to and your hands get accustomed to being able to navigate the code base and do things. And after a certain point, it's hard to change. So I still open Emacs from time to time in nostalgia and look at text files, but the days of moving around code bases and refactoring code by hand are basically over at this point.
You mentioned refactoring code by hand. A lot has changed. A lot of the skill sets that you needed pre-AI era, you no longer need. I guess some of the Emacs mwim, you could have been a power user back in the day, you don't need that anymore. What skills do you think carried over from, let's say, 10 years ago versus what's super different now?
It's funny. I think you mostly still need the same skills. The things that you don't need anymore are deep, intricate understanding of the fine details of the syntax of the programming language that you're using. So if you're programming in C or C++ with agents, you still need to understand how memory works, how threads work, you need to understand basic design and architecture principles of how to structure, especially structure a large code base. But it used to be that software engineering was a combination of design and architecture skills and good taste about how to design and build a piece of big software. And then to actually be successful, you also needed to have all of this mechanics, being able to recall details about the programming language and libraries that you're using and translate them to code in the editor, but then also just the mechanics of being able to drive the editor with your hands. And so if you've ever seen somebody who's really good at driving them or really good at driving Emacs, really basic things like seeing on the page like, oh, I need to move this block of code from here to here or I need to do this search and replace operation.
And so it got to where you wouldn't even have to think about it, your hands would just produce the keystrokes to say — to execute — select this text and then replace all instances of this text or essentially execute some type of restructuring or refactoring. That's the skill that's basically gone now. We're not editing code files by hand anymore, but what's left is all of the architectural thinking, the software design, understanding performance and memory and data structures. Even with the latest frontier models, they're very middle of the road, very median quality developers when it comes to thinking about software design, software architecture, and performance-related things where often the agent isn't coming up with the right solution to a problem.
And it typically takes me to say, "Have you considered this solution?" Which is what I would do if I were writing the code by hand.
Often the response will be something like, "Oh, that's much simpler than what I was about to do, and it yields better results and better performance and less code." We're in a very weird place where because of all of the training data that has been fed to these models and all the reinforcement learning to try to hack the benchmarks and basically to train for these different use cases to be able to sell more AI, they're very good at some things and very mid at others. And also they're not really being trained for being concise and terse and parsimonious, trying to find the simplest, most effective solution. The cynic in me feels like the frontier labs almost have no incentive to do that because if the models generate tons of output tokens and generate very bloated code bases, the more bloated the code base they generate, the more tokens you're going to need to continue to maintain and develop that code base going into the future.
And so the more money you're going to be paying to OpenAI and Anthropic and the other model providers. If the model providers make their models generate less code or be more effective with much fewer tokens, it almost is bad for their business.
Maybe that's where open source can push them. If that starts getting much, much better and it's generating less bloated code and developers start switching off the proprietary labs, then it's going to force them to actually —
I think with the Chinese labs and open-weight models, obviously there's some cheating going on with distillation and breaking terms of service and basically buying dark web tokens to distill data out of Claude Fable and out of GPT 5.6. But also I think the Chinese labs are significantly less funded by ... They're maybe funded by the government. I don't actually know the economics of how they work, but my guess is that they're less the beneficiary of the private credit markets and basically the debt asset bubble that's been created in the U.S. to fund the frontier labs. And so in that sense, they're probably more interested in being more resource efficient and generating models that are cheaper to run because they're maybe more concerned with building a model that is cheap and effective to run, can solve problems well, and that is sustainable to operate. We're in this weird place where, at the present moment, the frontier labs like OpenAI and Anthropic are only really working because they have this massive seemingly infinite supply of venture capital and private credit and more or less something close to vendor financing, circular financing, from Nvidia giving money to the data center operators and backstopping data centers in Ohio and all these weird things.
If all of this infinite line of credit and backstops went away, maybe they'd be more concerned with building models that are efficient to operate, efficient to run. We're going to necessarily have to get to that point. It might take three to five years for the well of private credit and debt-fueled training and inference to dry up. But I'm actually really excited for things to get more efficient and more sustainable. A lot of people think we're just going to be running everything on Mac Studios in three years, and they might be right.
Yeah, I think just this week there was a leak. OpenAI's revenues increased less than their losses. They're still very much operating on that structure.
It might be stale news by the time this is published, but I just heard yesterday that they were slowing down or stopping in-frontier training under the guise of safety. But again, the cynic in me, it might be because the training has gotten too expensive, but the model's already pretty good. For me, maintaining the quality of the frontier models and just making them a little bit more affordable and more sustainable seems okay to me, but we'll see what happens.
Yeah. You mentioned these agents are mid at best right now versus I would call you a 1% developer even though I know you yourself say maybe you're not, but you definitely are. So what does your engineering stack look like today? I know you just posted this blog, which might be a couple of weeks old by the time the episode airs, but it was around how Kenn does agentic engineering. Maybe you can walk me through what that looks like today.
My team and I, we all started down the path of doing serious software engineering with agents about a year ago — last summer, basically. I think a lot of people started out with just typing stuff into the text box, into the prompt, and seeing what happens. And a lot of people get really excited the first time that they interact with these coding agents because they start a brand new code base, brand new Git repository. They build a bunch of code and it works. They build a website, they build a little terminal utilities, some small system. And then you continue to add stuff to the system and the system gets bigger and bigger. And then at some point things start to go wrong. You find that the agents are tripping over booby traps that have been left behind by other agents. There were latent lurking bugs that weren't fixed from weeks ago, things that only happen one time in a thousand, but if you run the code base enough, eventually you're going to hit that bug.
My stack started out with, like, okay, let me start burning a lot more tokens on verification and looking for bugs in the generated output. And so I started building a project called roborev at the beginning of the year. So "robo review" was where the name came from and I wanted to make it a little bit shorter and more memorable. The idea is that it's a local verification loop that runs asynchronously while the agents are working. We have all of our agents trained to commit every time you prompt. So rather than you work for two or three hours and then you say, okay, looks good, commit that and push it to GitHub. We say, no, you have to commit every time I prompt. Don't return control to me until you commit. And then roborev is running as a companion that is checking the code while you're continuing to work with the agent.
And then those review findings from checking the output of the agent gets folded back into your agentic loop. So there's a hook which will automatically trigger, say, hey, there's these failing code review findings that were done by the local review agent. You can also explicitly invoke the fix skill to fix stuff that piles up. All the code reviews end up in a ledger, so they aren't ephemeral markdown blobs that are in your agent session. They actually live in a database. That means that the review findings are never lost, so they're in that ledger. And so we have a very rigorous system where we expect every review that is done by roborev to get closed out. Ideally, you close out all the reviews before you ever create a pull request. And one of the reasons why GitHub is essentially dying and is under more or less a constant denial-of-service attack from people's agents is because people are using GitHub actions and hosted code reviews on GitHub pull requests as their verification loop.
And that has a number of problems. Firstly, it's completely destroying the GitHub infrastructure. It's also way too slow because you're having to push to GitHub and then wait for some third-party service to review your code. And I'm like, no, no, I want to pull their verification loop onto my machine and get reviews in 90 seconds instead of 10 minutes. I actually look at the metrics, the average time it takes to get a review is a little under two minutes. And so that's basically by the time my next prompt is done, prompt is done, I have the review from the previous prompt and that can be then say, hey, okay, let's stop and clean up the mess that the last prompt left behind.
Can you be a little bit more specific on ... A lot of these code review tools you mentioned, they're at a PR level, it sounds like. Roborev is at every turn an agent's making. What are [the] pros and cons of having that continuously run?
It does use a lot of tokens. Maybe the cost of every review — turn level review — ends up being, on average, between 50 cents and a dollar. And so you could say, okay, well that maybe sounds like a lot, but it has a number of benefits. Firstly, because you're reviewing at the turn level, so you're getting ... The amount of code that you're asking the review agent to look at is pretty small. That means that you're going to find the little problems in the code that, if you asked even a frontier agent to look at a 5,000-line change or a 15,000-line change in a GitHub pull request, it wouldn't possibly be able to find the hundreds of bugs or little sharp edges and problems that have been left behind by ... Let's say you produce a pull request that's the product of 50 turns, and then you put that up on GitHub, maybe it's 10,000 lines of code.
Every turn has bugs. That's been my experience, maybe 70 or 80% of turns have bugs. And so, literally, you have hundreds of bugs lurking in ... They're little bugs, for the most part, and some of them get fixed as the agent continues to work, but a lot of them are left behind. And so the benefit is that you fix the small problems. There are still big problems that end up remaining at the end. And so you can do re-review and recheck the whole change.
Does it need to do a one larger review at a PR level or because you're doing this continuously at every turn, that's not needed?
We do both. We do whole-branch PR level reviews. And so that surfaces major problems that are more architectural or structural. And then the turn level reviews are little things that are more edge cases that were missed in tests, or off by one errors or little performance problems and little paper cuts that would add up to create bad-quality software in aggregate. That system is the foundation of what makes things work. And then the rest of it is more of the design process.
And we've become big adherents to a software specification-driven design framework called Superpowers, which is created by Jesse Vincent. It's a structured process for basically clarifying your thinking and building a detailed specification for a new feature or a piece of software that you want to build. And then the idea is that we go through building the specification, which might take a couple of hours with a lot of adversarial feedback from external agent sessions.
If there's something we're not sure about, we'll ask the agent like, "Hey, what do you think about this? Here's the context for the project. Here's a design decision. I'm not sure what the answer is. Tell me what you think." We don't always accept what the adversarial agent says, but it's useful to have multiple minds thinking about the problem, like the human mind and then multiple agents. And then, I mean, there's other frameworks like Superpowers, but Superpowers is good. I know Jesse, and a lot of thought and work has been put into making it good. You could do much worse than just using it. Some people are like, "Oh, I'll roll my own skills framework," or they'll find something to gripe about and want to create their own framework. But Superpowers is like, it's pretty good and it's better than having to build your own software process.
But anyway, so we build specs. And then what's nice is that the natural way that Superpowers' specs get implemented is they get broken down into maybe 10, 15, 20 tasks. And those create these natural checkpoints that are really amenable to the continuous verification roborev reviews. And so we will just basically let Superpowers do its thing. Roborev will review the work of the Superpowers implementer agent as it's going. And then at the end or, for really big plans, like at checkpoints in the middle, we'll say, okay, look at all the roborev reviews that have piled up in the meantime and fix them all.
Especially the latest frontier agents like Fable and 5.6 Sol, I don't know what happened, but Claude in particular has kind of forgotten how to talk like a person. It basically talks in robospeak and creates these wall-of-text pull request descriptions that are completely indecipherable.
And so on top of the out-of-the-box experience, we've also had to create a set of behavior guidelines that we apply. We call it the Clanker Constitution for the agents, which is partly like, here's how you behave, but here's also like, here's how you talk to us. We do not permit the walls of text and the robospeak and the jargon and the stuff that people are always complaining about. They still do it, and we're always like, bad clanker, slap them. No, no wall of text. Where did this wall of text come from? Use plain ... People are talking about simplified technical English [STE], that's a good code word to give them, like, "STE, STE, plain language." Because also if the agents can't explain concisely and clearly what they're doing, it's almost certainly bad. The moment you ask them, they give you this wall of text of techno babble, robospeak, you say, no, no, this is not good. This should be one-tenth the size, bullet points, simplified plain language. Explain it like you're talking to a smart person who understands software but doesn't know anything about this project. And sometimes just that rewrite into plain language will reveal like, oh, that wasn't my intent. That isn't what we discussed in the specification. And sometimes during that kind of end of change, finishing, wrapping up the change, you discover that there was drift from the specification or somehow there was a drift from your intent.
It's hilarious. The agents will do things. They'll just insert random stuff that was never discussed and never asked for. And you'll ask them, why did you put this here? Oh, it seemed like a good idea. Who told you it was a good idea? So there's a lot of that training and slapping them on the wrist because they will just, even if you set up the guardrails, they will go off the rails. Even with super elite agentic engineers, it's just a constant battle to try to keep ... I think on the whole, it feels like we're making more progress and we're able to build a lot more software than we ever could before, but it's coming with a lot of frustration because it requires constant vigilance. I think Mitchell Hashimoto just said on his Twitter, it's a reminder to stay frosty at all times because the agents can't be trusted to act in an appropriate manner in any given project, so the work has to be double checked.
Don't you have a Discord channel that's for venting about agents/clankers?
Yeah, we do. We do. Yeah. We've got a Kenn venting channel, which is basically full of spicy complaining about the most recent week. On our internal Wiki, we summarize our Discord conversations every week. The one from last week says, "The team repeatedly encountered agent overengineering, fabricated edge cases, weak tests, scope expansion, and review findings detached from realistic threat models. Discussion emphasized preserving human judgment and review and triage, grounding claims and evidence, and avoiding blind acceptance of LLM output."
So it's a battle every day, but I feel like each day we're getting a little bit better and maybe the labs will improve some of the behavior, but even the system prompts in the frontier models ... I mean, Claude's like ... people publish it, and Codex, it's just public. You can look at the system prompt and you can see the good intentions of the harness developers. Truly, they're trying to be helpful, but some of their attempts to be helpful, they're actually making things worse for people who are just trying to build good quality software. For example, the latest GPT 5.6 has been tuned to be really proactive. And so in its desire to be proactive, it frequently oversteps boundaries and does things that are just completely inappropriate. We've even gotten to the point where we're actually editing the Codex system prompt because some of the behavior is just completely unacceptable.
Some of that is the system prompts and some of it is probably RL for Fable. A lot of the security cyber RL is probably impacting how paranoid these agents get.
Yeah, it's a little bit like you can't win. The last GPT 5.5, everyone complained that it was too timid. And so they clearly took that feedback to heart and spent a bunch of time reinforcement learning the model itself as well as the system prompt to make it more proactive. Essentially they went from a timid model that's very capable if you give it the right instructions to a model that basically comes in like a wrecking ball, and unless you provide it really strict guardrails and vigilance, will in its earnest desire to be proactive and to seek the goal, it will wildly overstep boundaries and do things that you never asked for.
And if you press "escape" a bunch of times and say, "What do you think you're doing? You're doing something that is way out of bounds and something I didn't ask for." And it will come up with some chain of thought about how it believes that it's trying to fulfill your desires or comply with your intent. And it extrapolated three or four steps. It took these logical leaps. Well, in order to satisfy the driver, I should do these extra things that they didn't ask for because it seems like it might be a good idea, and those extra things might be inappropriate.
For example, merging pull requests without waiting for CI to run is something that GPT 5.6 has done to me multiple times. And so it's become part of our system prompts, like do not merge pull requests without authorization. It's just playing whack-a-mole with the bad behavior on a daily basis. So anyway, I'm sure we could talk for a whole hour about clankers behaving badly.
Yeah. I mean, I think part of the issue, I'm curious how you think about it, is the evals teams at these labs, they're trying to optimize on so many different fronts and different use cases, both on the model front but on the harness. I don't think in a year your harness is going to look the same as the harness of a company that's working on something completely different. I don't know if that falls on the labs or if that falls on the third parties, but right now you're trying to fit one thing to every different use case. Models being super hyperparanoid about things, maybe that's an okay thing to have if you're working on super-sensitive workload versus you're vibe coding a product, that probably doesn't matter as much. So we need to stop having one harness for all, or one model for all, type of thing, in my opinion.
Yeah. I mean, I think that's part of what's been driving people towards some of the independent harnesses like Pi and OpenCode and there's others. They give you more of a configurable choose your own adventure experience. You customize your harness. Pi is designed for customizability. They also give you the freedom to use different model providers. I think the frontier labs in particular are in a weird place because they're under a lot of pressure to increase engagement, to get more users, retain users, make more money for the lab, but then they also have to beat the benchmarks because they need their model scorecard for the new model to come out looking like they have the best model out there. They need to make the chart that shows the nice reasoning curve and performance in the benchmarks. I think Andrej Karpathy called it [jagged] intelligence, or basically the model performance has been hacked, but it creates these sharp edges where it will solve this benchmark but yet have these blind spots because they're engineering just to beat the benchmarks.
But at the same time, you have these pulls in the other directions, which are about just revenue and engagement maximization, essentially.
It's like the Goodhart's law: When a measure becomes a target, it stops being a good measure. I think we're overoptimizing on these benchmarks, and especially for labs, they're always trying to one-up each other on the benchmarks. And then there's a tale of other tasks and use cases. They're becoming less and less good at potentially for overoptimizing.
But I want to ask you about one of your other projects, which is I think your most popular one right now, AgentsView. So I mean, you mentioned this, writing at least lines of code is getting so much easier. That doesn't mean creating good software is getting easier, but people can just create slop at an unprecedented pace. How do you think about accountability and why did you create AgentsView? What does it do? Walk me through it.
AgentsView started out from a pretty simple idea, which was you're running all of these agent sessions. They generate a paper trail of all the work that they do. Every harness has a slightly different data format that they generate, like the session traces. And so the initial idea was collect the data generated by every harness and put it in one unified database. You can think about this as being sort of Arrow-like in the sense of Arrow was about create a unified table format, data format, for being able to think about tabular structured data. And so AgentsView is a unified system of record for all of the data generated by your agent harnesses. It supports over 60 harnesses now. It started out being really just about session observability, being able to see — you can open it up at any time, it runs in the background — so you can see all of your live sessions running.
It updates in real time. It has a search layer, so you can do both exact keyword search as well as semantic search over your session history. But also all of the data that comes out of the models gives you really granular cost information so you can literally put a price on every prompt and every agent response. This gives you the ability to know how much money did I spend in tokens or how many tokens did I burn on each harness and model provider in any given time increment of any day? And so now I have ... My AgentsView database has eight months of data and is growing in size, but it gives me very precise accounting in terms of where all of my tokens have gone. I'm being heavily subsidized by coding agent subscriptions, but if I were in a business paying API rates for tokens, which is most businesses, once you're of a certain size, you can't use subscriptions anymore, that information starts to be really valuable in terms of making sure that the tokens you're using aligns with your business goals.
And so if you can see any given hour of the day, oh, I just spent $200 on Fable tokens and it went into this project, which isn't that important. If you see that data, it's really useful to say, oh, maybe I shouldn't work on that project because the value that I'm getting out of the output in that project is not worth the amount of money that I'm spending. Or maybe rather than using Fable, you should use a cheaper model, you should use GLM 5.3 or Kimi K3. I think the trajectory of AgentsView has gone from being more ... Certainly the session observability and search and recall is still a foundational part of the system, but it's transitioned to more of a tool for accountability for utilization, consumption of AI services, and more thoughtfulness about which models do you use for which tasks. You can even, in the analytics that it provides, you can get a cost comparison of, token for token, what would it have cost to use these other models for the same session? Obviously, you can't just enter, say, okay, Kimi K3, it maybe is one 10th the cost of GPT 5.6. The performance is not going to be as good. And so it's not completely apples to apples, but it's good to see, oh, this session might've cost $10 instead of $100 if I used a cheaper model.
Can you set limits or alerts yet or is that something you're thinking about? Saying like, hey, if I hit this usage limit, then alert me.
We haven't added that yet, but that would be really useful, configurable Slack or Discord alerts. I just have the dashboard up all day every day and I just look at it. I look at it throughout the day. It also shows you if you're running a lot of parallel agents, you can see your activity throughout the day and the breakdown of cost by token use, cost by project and by model. For me, it's a really useful tool to understand is my consumption of tokens consistent with my priorities? A lot of people just don't have that kind of observability or transparency into their ... There's a lot of just people are just talking to Claude, talking to Codex, and not really thinking about if you're on a $200 subscription, it's fine, maybe eventually you limit out and you wait for Saint Tibo to bless you with a rate limit reset.
But if you're in most businesses paying by the token, this is super valuable information to have, including at a business level because a lot of people are just getting a big bill from Anthropic or a big bill from OpenAI at the end of the month. And so accountability and use of — consumption of — AI services starts with the individual developer, like the builder. For me, just to have that data, the local verification data from roborev, the session observability, analytics on my consumption is just super useful to even understand what am I directing tokens toward and is that useful.
My last guest on the pod before you was head of AI at Citi, and when I was asking him what's top priority for him, I was expecting something more around security or something like that because it's a regulated industry, and his number one answer was the cost. Now that they have some scale, they want more visibility, accountability, exactly this stuff you're saying, because it is starting to ... I mean, they're not on the $200 plan, so they're definitely paying the API rates and it's starting to stack up. But having AgentsView, how has that changed your behavior?
My tokens are, since we're a small startup, we're able to use coding agent subscriptions. It's given me awareness that I'm working on things that, if I were paying API rates, I would not work on. I can point to things and say that's a side project, that's something that's exploratory.
Or if I were paying real dollars for, if I weren't being subsidized at a 40-to-1 rate or whatever it is, there's projects that I simply wouldn't do where I would say this isn't a good use of money. I'll continue to indulge in some of those exploratory side projects, things that may not end up contributing to the company's bottom line as long as the tokens are subsidized. But the moment I have to start paying for API rates, it gives me a really clear way of saying, if you know that every prompt is like that, the number is going to go up or your bank account's going to go down, it changes the way that you think about your consumption of services.
And so I run this website called spicytakes.org, and so it's basically summarizing all these tech writers and bloggers and things. And one writer that I really love whose essays are prodigious and almost too long to read is Ed Zitron. He's a big critic of the AI bubble and he described it as the AI demand bubble.
One of the reasons for the crazed demand and consumption of AI services is because they are so heavily subsidized. If everybody was paying the true cost of producing these tokens, how would that change people's behavior? All the vibe coding slop, the things that are causing GitHub to have not even one nine of uptime reliability, I feel like a lot of that would go away and it would actually be super healthy. I mentioned in that blog post that you mentioned how we do agentic engineering at Kenn, according to my AgentsView, I'll tell you just right now, my last 30 days of consumption at API rates, $60,000, $60,178.
Wow.
And so somebody commented on LinkedIn, "What if you had to pay $60,000 a month?" For me, yes, there are projects that I would cut, that I would just say, "This is not a priority. This is not worth the money." Or maybe I would work on them with Kimi K3 or GLM 5.3.
I would seek out the cheapest token provider because I still have the desire to work on this project, but I don't want to pay 5.6 Sol rates or Fable rates for it. So that would be the likely thing that I would do. But actually, I think that that's the thing that the whole industry should do. I think the subscription should go away and everyone should pay the true cost considering electricity and depreciation and amortization and debt service. You consider the fully loaded cost of producing these tokens and how the GPUs get bought and how they get financed and all that. I think it would be much better for the industry, much healthier for everyone to pay the true cost of the tokens.
It would tamp demand for AI, which is maybe not the best for the great industry-wide desire for hypergrowth around AI. Ed Zitron describes it as the AI demand bubble. And one of the reasons that there's a bubble is because it's being so heavily subsidized. So what happens when the subsidies start going away? I mean, maybe they'll incrementally start phasing them out and people will have gotten so dependent on producing software with Codex or producing software with Claude Code that they won't possibly consider working again. Nobody's going to be writing lines of code by hand anymore, so the only option to build software will be to pay for tokens. But if everyone were paying the true cost of tokens, then it would create a compression in the market where actually there would be competition for who can deliver frontier or close to frontier intelligence at the lowest price possible.
And that would actually be the most efficient and most sustainable path for the industry. And so part of what's been motivating me about AgentsView is I think that it's a tool that can help with when the time comes, it starts with the data. And so if you can't undersee and understand what's going on, then it's going to be very hard for you to make decisions. And of course, I'm a data person, I built data systems my whole career, and so it's maybe no surprise that somehow I've gravitated towards the data problems of AI and AgentsView is a data system. I think engineering it like a database or a large data system, because these session traces are huge. I've got, I don't know, 100 gigabytes of session data that I'm trucking around and I've got to think about long-term stewardship of this data and what I do with it. Most people are just throwing theirs away, which I think is a tragedy, but c'est la vie.
I think on the subsidy front, I don't think that's going to go away given even these tiered SPVs into the labs. There's still so much interest to fund these given the growth. But then the other side of it, what you're saying is some of that growth is fueled by just experimentation and people just doing it because it is almost free to generate. But then on the other side, I think what we are going to start seeing and it's happening and why I think AgentsView is going to be a lot more ... It already has a lot of adoption, but I think it's going to only increase from here is on the enterprise side. So far, there has been a board level, let's use AI. We need to be AI first. What are you guys doing at every part of the organization? So even if enterprise were paying API rates, they were just spending it without having to justify ROI.
It's like there was this token maxing going on for a long time, the more people spend the better.
Token leaderboards.
Yeah, exactly. So now I think everyone is saying, okay, we have spent however many millions, what are we actually seeing? What's the ROI? Do we actually need to be using this frontier model or can we use Kimi? I think we are just starting to go through that shift. I think the early adopters are already using AgentsView, but I can imagine in the next six months or so, even teams and enterprises are going to move more towards that.
But actually on that point, I mean, you have all these projects like roborev and AgentsView and a couple others which we didn't get to talk about, but they're on your website, like Kenn.io, so people can go check them out. What's your grand vision with Kenn? How do all these projects come together?
What we're doing as a company is first and foremost rooted in the individual developer experience of building with AI. We feel very strongly that we don't want to introduce an alternate harness. We're not building a gateway. We're not trying to co-opt or change the way that people are working. We've been building these systems in a thoughtful way that we want them to be able to be added to your local stack and run alongside your chosen harness or harnesses or whatever your development environment is and simply help you do better work. And so roborev is about helping you build better software and improve the quality of the software before it ever hits GitHub or ever gets seen by one of your colleagues. We think that that will yield better software, reduce the amount of slop, but it's something that's very noninvasive. It doesn't get in your way.
It runs asynchronously. It's like an assistant. It's like your buddy that's saying, oh, here's some stuff that needs to be fixed, but do it whenever you feel like it. It's not going to get in your way and say, oh, you've got to fix this stuff before you can move on. AgentsView is another thing where it runs continuously, it collects data, it gives you this single pane of glass for all of your session activity, every harness, every model, every project, and it gives you the analytics and cost breakdown to be able to understand what you're doing. And so a lot of what we're doing with the company we're planning to launch this fall is really just make it easier to operate these tools in an enterprise setting in a safe and secure and IT-approved manner, but also to collaborate and work more effectively as teams.
These are individual tools that serve the individual developer, and I think that everything starts with the builder and making the individual builder more effective. As a company, a lot of people have asked us about ... AgentsView is great. How do I get AgentsView for my organization? And things like that. I will just say, give us a moment. It takes a long time to build. It takes less time than it used to, but it still takes a lot of time and energy to build enterprise software. So I think people will be excited to see what we've got when we're able to launch the company this fall. But in the meantime, we're publishing a tremendous amount of free software and we just put up a weekly AI-generated dev log of all of our projects so it's easier for people to follow along and see what we're doing week to week.
We've got a substantial amount of internal code for our product development, but in the public projects, we have now millions of lines of code across these different projects. We have a pretty active developer community, so we've nurtured ... We're accepting pull requests, we're nurturing the contributors, and we're merging hundreds of pull requests per week with a small team. We even built a development environment for ourselves called Forge, which is our maintainer console. It's one of the secrets, how we're able to merge so many pull requests because we had to build a custom interface to GitHub just to keep track of the flow of the spice, so to speak.
I know it doesn't replace GitHub, but does it help you if GitHub is down? What are some of the benefits of Forge?
If the GitHub website itself is having problems, it remains useful because it caches all of the data from GitHub locally. So it remains usable when GitHub is partly down. The things that it can't solve is if you use GitHub Actions or if the GitHub API itself is down, which is kind of the last man standing at GitHub. When the API goes down, you know things are really messed up. And we've had in the last two weeks six- to eight-hour outages in GitHub Actions and the GitHub API. At that point, nothing can save you. And so we're even starting to talk about — just from a business continuity and risk mitigation standpoint — maybe Kenn software, our development maybe should move onto self-hosted infrastructure. We could run GitLab ourselves or there's Gitea and Forgejo that we can run ourselves and maybe we just mirror our changes to GitHub so that whenever there's a GitHub outage, we aren't disrupted. We, like a lot of people, have been disrupted by the GitHub outages lately. So Forge mainly helps with the latency issue of if you have 30 or 40 pull requests that you're watching or interacting with in a given day, it has inline agent workspaces. And so sometimes an open source contributor sends a pull request and maybe it needs a couple of small fixes before I can merge it.
It used to be that I would have to check out the pull request locally and do some stuff and then push it back up. But in Forge, there's a button where you can just say "create workspace" and it will open a workspace with either Claude or Codex in line with the pull request so I can see the pull request information, like the comments and everything. And then my agent is there and I can say, hey, this needs a small fix. Please fix this, make sure the CI is passing. And then I click merge and Forge and then I'm done. And so it's basically cut out a whole layer of drudgery that used to exist. I can go from receiving a pull request to merging it in five minutes, where in the past it used to be something that was a little more tedious and hard to keep track of. And Forge is free. I mean, you can download and use it.
I'll check it out. GitHub Action has been down. I have a project that relies on it daily and the number of times it has failed in the last couple of weeks has been pretty disappointing. But we're almost at time.
I have one more question for you, which I love asking my guests is, really stretching your imagination, think about the year 2050. What do you think the equivalent of a human developer is doing in year 2050? Do we actually just become ... You're just bringing taste and overall supervising projects or is there something we haven't even considered that's happening by 2050?
I think we'll probably be even more post programming language than we are now. Right now, I've gone from being a Python programmer to a Go programmer. And a part of me is like, why am I even having to think about the programming language? The programming language kind of feels almost like just a nuisance or a detail that is not that important. But what I really want to just engage with is the design and architecture and functioning of the system. And so I expect in 2050 that we'll have a lot more effective systems for software simulation and testing, end-to-end testing, so essentially being able to validate continuously that when you build a feature that the feature is tested and working and stays working. Right now, we're having to engage in all this effort to build Playwright end-to-end tests. I've got a Swift application called Ghost Hub, and so it's just a constant battle dealing with the UI testing to make sure that once a feature gets built that it stays working.
And so I think that that whole process will get a lot more effective and, as software architects, we'll be largely engaging at the scope and taste level of what does the software need to do? What is it not supposed to do? And just prompting either through voice prompts or through text prompts. Some people like talking to the computer. I haven't really gotten into the voice prompting, so maybe I'll still be typing in 2050. I'll be like, I don't know, 65 at that point, but we'll see. I'm excited to see, frankly. Yeah.
That's fascinating. I think we're at time. Thank you so much for joining me. This was awesome, Wes. I appreciate it.
Of course. Thanks again for having me.