Half the feature is the lesson: how Kieran Klaassen runs Cora without touching the code

The third speaker at localhost was Kieran Klaassen, who runs Cora at Every.

Kieran hasn't written a line of code this year, and hasn't looked at any either. Yet Cora, a full AI email client, is something thousands of paying customers trust with their inbox every day.

Every describes itself as an AI lab for the future of work, one that writes about, teaches, and builds toward an answer to a single question: what's next. Most of its products, Cora included, are built by one person. That's the system Kieran has built for himself, and it shapes what he actually spends his time on now that implementation isn't the bottleneck.

Cora is agent-native: anything a person can do in the app, an agent can do too. Kieran is building a second version now, running on iOS, Android, web, and directly inside coding tools like the CLI, Codex, and Claude Code. He owns product and engineering end to end, joking that he loves technologies that start with R: Rails on the backend, React on the frontend, Render for infra. Design, marketing, and support have their own people, but Kieran is the one who's responsible if something breaks. He came into this from a background as a VP of engineering and technical founder, and said part of the point was seeing how far AI could push him toward doing everything himself.

Two years ago, when Sonnet 3.5 and Cursor Composer were new, Kieran started building an email assistant and the code it produced wasn't great. He added prompts that reviewed the code for sloppiness, and those prompts became agents that did the reviewing themselves. Once code quality stopped being the bottleneck, planning became the next one: a good plan, it turned out, tends to produce good code on its own. Once planning was solid, the bottleneck moved again, this time to product judgment: deciding what was actually worth building, and spending real time with users to understand their problems.

Somewhere in that progression, Kieran noticed he kept repeating the same corrections to his agents. So he built a memory system to hold onto them. That system is what he now calls compound engineering. For Kieran, this works now because models have gotten good enough to actually leverage this way, and because most people building with agents, in his view, still aren't pushing them hard enough to find out.

His job now is deciding what deserves to exist, judging whether a result actually feels right, and teaching the system not to repeat a mistake once it's been caught. A single person with a laptop, running this loop, can compete with companies valued in the billions.

Kieran's loop runs through ideation, brainstorming, planning, implementation, review, polish, and a compounding step at the end, an approach Every's public compound engineering guide describes as an eight-stage loop: ideate, brainstorm, plan, work, review, polish, compound, repeat. Kieran puts his own attention at the two ends of that loop, the brainstorming at the start and the review and compounding at the close, and lets the agent run the heavy implementation work in the middle largely unsupervised.

His personal rule for making that middle stretch trustworthy over time: spend half the time building a feature, and half capturing what the work taught him. That lesson might become a convention, a planning document, a warning about an approach that failed, or an explicit instruction a future agent can retrieve before it makes the same mistake. Under the 50/50 rule, shipping the feature is only half the job. The other half leaves the whole system a little better informed than it was before, and, as a side effect, cheaper to run: a saved lesson means an agent doesn't have to re-run the equivalent of deep research on a problem it's already solved once.

In practice, this runs on a handful of specific commands. An "ideate" command can be pointed at open GitHub tickets, Slack feedback, Intercom, or a list of OKRs, or left with no target at all to see what it surfaces on its own, and returns a structured, arguable list of what to do next as a clean HTML page. A "doc review" command points at a planning document and asks the sharp questions a person might not think to ask, and compounds automatically, so future plans get reviewed against the same bar without Kieran asking again. A heavier "brainstorm" command pulls in the existing source code, prior plans, and defined personas before asking its own clarifying questions, and writes the result out as a markdown document, stored in the repo by default but configurable to somewhere like Linear or Google Drive for teams that want it elsewhere. And a long-running command Kieran calls "lfg" takes a brainstorm document and runs the full middle of the loop mostly unattended: planning, implementation, code and document review, testing, QA against defined personas, before-and-after recordings, and a pull request with all of it attached, anywhere from about an hour to sixteen hours depending on the size of the task, often kicked off overnight or run in parallel in the cloud.

The review step often looks like this in miniature: watching the running app next to the agent's session, Kieran notices two logos where there should have been one, flags it, and has the agent fix it on the spot. Before merging, he runs a "compound" command to manually extract that correction into a lesson, so the next "lfg" run against the same brainstorm won't make the same mistake again.

The clearest example of the loop closing came from an actual failure. Kieran had deployed a change that included an index operation against a table with roughly 500 million rows, and the deploy failed: a timeout setting had changed, and the operation ran long enough to hit it.

He ran a debug command with the Render deploy link attached. Using the Render CLI, it pulled deployment information and logs, and found that a lesson about exactly this kind of operation already existed in the system, but had gone stale as the table had grown well past the size the original lesson assumed. The agent updated the lesson on the spot. The next plan that touches a similar database change will retrieve the refreshed version before it tries anything.

Kieran also runs a separate refresh command that periodically audits the full set of accumulated lessons and checks whether they're still relevant. Old guidance, in his framing, can be just as dangerous as missing guidance, especially as models, dependencies, and infrastructure keep changing underneath it.

Cora's stack is Rails, React, and Render. Kieran wanted infrastructure that didn't make him think about Docker or routine plumbing: "Some people love that. Thank you, Render, for not having to deal with that." He feels much the same about Rails itself: its opinionated conventions mean there's usually already a standard way to do something, which is what makes it easy for an agent to fall into good patterns rather than invent new ones.

That preference extended to his agents, not just to himself. He gave them direct access to the Render CLI, logs, deploys, jobs, and connected observability tools like AppSignal and Sentry, along with a skills MCP for pulling read-only production data, so production state is part of what an agent can actually consult, not something Kieran has to relay by hand. The goal is a platform that stays quiet while the application is healthy and becomes fully inspectable the moment a deploy fails, which is exactly what turned the 500-million-row incident from a mystery into an updated lesson instead of a repeated one.