I’ve spent a good part of this year writing about why experienced engineers have trouble working in agentic loops. Learning to delegate takes time. Building the harness around an agent is another skill to learn. Even engineers who adopt the tools and ship more can find the experience dispiriting, as I wrote in Coding’s Great Depresh.
At Duetto, we’ve been experimenting with inference since February. Our engineers have access to several approaches to harness engineering, including my own harness. I’d estimate that about 10% of our engineers have become exemplars of this way of working.
Then I ran a hackathon. Five finalist teams (of 10 who submitted first round proposals) built applications whose repositories hold nearly half a million lines by our authored-file count. Across their measured branches, 79% of commits carry an AI attribution. The workflow I’d been describing as hard to adopt was all over their commit history.
At the hackathon, the conditions around the work changed. I think that helps explain why people worked differently, and gives us something to try when they return to their usual projects.
What They Built
The hackathon had three rounds: a written proposal, a hack day on September 2–3, and a final build week on October 19–22. Five entries reached the final, where an in-person panel chose the winner by ranked-choice vote.
Each finalist built a standalone application against Duetto data:
An AI revenue-strategy assistant, the winning entry. Dashboards for rates, forecasts, opportunities and other revenue decisions, plus a chat assistant drawing on the same data through MCP tools.
A plain-language dashboard builder. A revenue manager describes a view, gets a custom dashboard, asks it what to do, and acts on the answer on the same screen.
A daily stand, plan and track loop for revenue managers. A workflow in place of a dashboard, with a Next.js front end and a Python back end.
A budget and P&L app. Upload hotel spreadsheets, build and review budgets, comment, export to slides, and read AI-assisted analysis.
A cost-anomaly agent linking revenue and finance. It compares hotel costs with peer sets and projects their dollar impact. A deterministic engine calculates the figures; the model explains them.
The descriptions and counts come from inspecting the repositories and their READMEs, without building, running, or testing the applications. That inspection gives us evidence of how the teams worked and the size of what they built. It doesn’t establish production readiness.
What Was Different
Greenfield work gave people room to play. Each entry had its own repository. Four began around the September hack day; the fifth started with a prototype from May. The teams could build a standalone application without fitting it into an existing release train. That is a substantial difference from ordinary work. When I counted my own sessions for Moving Past the 10-Tab Workflow, only two of ten were new projects. Most development responds to systems already in place.
The incentive was concrete. The five finalist teams earned a trip to Croatia for the final build week. The theme was “Agents that earn their keep.” The rubric scored AI depth, use of Duetto data, and business value. Its top band for AI depth read: “The AI is the product: remove it and there is nothing left to ship.” There was no score for code volume.
Product and engineering worked on the problem together. The rules called for teams of three to five, with at least one engineer and one product person. Commit authorship captures only part of that collaboration: one entry has two committers, while its pitch transcript names five people. In my view, this mix helped people get out of ticket-response mode. They could decide what to build together and get on with it.
I would like to carry those conditions into ordinary work. A hackathon gives people a bounded problem, a shared deadline, and room to make decisions. How much of that room do we leave them once the ticket queue resumes?
The Evidence in the Repositories
As of October 27, the five entries hold 489,480 lines, measured with cloc in files classified as authored. That excludes blank lines and comments, along with identified generated files, dependencies, lockfiles and data. The classification uses file paths and extensions, so it is an estimate of authored material. It also includes documentation and configuration. Restricting the count to programming, markup and style languages gives 434,567 lines. The snapshot uses four entries’ main branches and the fifth entry’s application branch; unmerged side branches are excluded.
The work was concentrated around two build periods, about six weeks apart. The active days in the table include work outside those periods, including the winning entry’s May prototype. During October 19–22 alone, the entries added 415,830 authored lines. That is a different measure from the table: it includes documentation, configuration and rewrites, some of which were later removed. It describes the intensity of the final build week, not how much code survived it.
The teams also used branches, pull requests and merges. Across the entries, they made 2,353 commits and merged 493 of 539 pull requests. Of those commits, 1,850 carry an AI attribution: a co-author trailer, a “Generated with” line, or a coding agent’s author identity. In the dashboard builder alone, an agent’s identity authored 1,077 commits.
The 79% is a lower bound on commits with agent involvement. Missing attribution doesn’t establish that a person wrote the code, and present attribution doesn’t tell us how much an agent wrote. It is not a percentage of lines written by AI. Nor does volume measure quality. Agents can produce verbose code and long documentation. The winner had fewer lines than two of the other entries, and the rubric rewarded what the application did.
The site that ran the hackathon belongs in the account too. An agentic session built its registration, proposals, judging, results, finals schedule, and assistant available on the site and in Slack. It holds another 93,597 lines by the same authored-file count, bringing the combined total to 583,077.
What I Would Carry Back to Work
Most engineering happens inside existing systems. A trip to Croatia isn’t a repeatable operating model. But teams can have more control over how they get from an idea to a working application.
I’d start with self-service ops. The entries set up their own databases, sign-in and deployments. Give teams a way to do those things as part of building. If an agent helps them produce a service in an afternoon but they still have to wait for someone else to provide an environment, that wait limits what the new way of working can deliver.
The infrastructure choices belong in that discussion. One entry’s README identifies Vercel as its build and deployment platform, another demo sits behind Vercel deployment protection, and the budget app uses managed Postgres on Neon. The management site’s assistant runs on Vercel with model calls through its AI Gateway. For standalone work, I’d give teams access to platforms like these and the authority to use them.
I’d also favor stacks agents handle well for new work. These entries were heavily TypeScript, with Python carrying one back end. Those are my starting choices for this kind of application. The hackathon doesn’t tell us how much of the result came from the stack, and an existing system won’t change languages because its team starts using agents.
And I’d provide enough inference access to work through a problem. Put it alongside environments and deployments in the resources a team can obtain for itself. The measurement doesn’t cover inference spend, so I can’t put a price on this hackathon or tell you what budget would reproduce it.
Each entry worked in its own repository. The management site coordinated the entrants, not their code. Ordinary engineering means many teams sharing services, schemas and on-call responsibilities. What happens when teams working this way build on the same codebase? I don’t know yet.
Bob Matsuoka is CTO of Duetto, a hospitality profit and revenue-management platform.
Related Reading:
What Is Harness Engineering?. Why harness engineering is the skill most engineers are missing, and why they don’t yet believe it
We Need to Teach Delegation as an Engineering Skill. Why expertise makes delegating to agents harder, and how to teach it
Moving Past the 10-Tab Workflow. Why most development work responds to existing systems, and where orchestration goes next
The Billion-Token Engineer. What happens when an organization hires engineers who each run a shadow army of agents
AI Power Ranking. Tool comparisons and benchmarks for AI practitioners
LinkedIn Newsletter. Strategic AI insights for CTOs and engineering leaders
Scenes From the Week
