How Gametime Engineering Hit Level 3 - and Why the Real Work Starts Now

FROM THE GAMETIME ENGINEERING BLOG - POST 001

Welcome. This is the first post from the Gametime Engineering team’s new blog. We are a passionate team on a mission to unite the world through shared experiences by providing the fastest, simplest, and most transparent, last-minute ticket-buying experience for live events. We’ve spent the last year rewiring how we build software around AI agents. We’re writing here in the open to share what we’re learning - what worked, what didn’t, and what we wish someone had told us six months ago. Expect future posts on harness design, evals, agent orchestration, the skills we’re shipping, and the team we’re building. Engineers, designers, and PMs from across the org will be writing. Kicking things off:

The harness around the AI matters more than the AI itself.

Figure 1. Where we sit on Dan Shapiro’s five-level framework.

A few months ago, if you’d asked me where Gametime engineering sat on the agentic coding curve, we would have said “somewhere between level 1 and 2, and we’re under-counting.” Today we can say it cleanly: our web and mobile repos are operating at Level 3 on Dan Shapiro’s five-level framework for agentic autonomy, our backend is in the high Level 2s, and we’re already building the scaffolding for Level 4.

The framework, briefly

Shapiro’s framing, which we’ve adopted as shared vocabulary:

Most engineering orgs talking about AI live between L1 and L2. The honest middle. We were there too - and we were drastically under-reporting it.

Where we are, in three numbers: Upwards of 80% of all our code is now co-authored by AI.

That split isn’t accidental. Web and mobile live in two monorepos, which means getting the right context into a coding agent is a one-time, low-friction lift. Backend is a different shape - distributed across many services, with the context fragmented across each of them. Some areas of our backend already operate at L3+; others sit at L2, and the variance itself is the work. As the rest of this post argues, the whole game turns on agent context, so the FE/BE gap is, in the end, mostly a context-distribution gap

This is the first in a series about how a ~200-person live event ticketing company is rewiring itself around AI-native engineering. We want to start with the how, because the gap between “we use Claude” and “we ship at Level 3” is mostly a harness problem, not a model problem.

The under-counted starting line

When we first started measuring AI-coauthored PRs at the start of the year, the dashboard told us we were around 30%. We knew that was wrong. Engineers were pasting Claude output without commit attribution. Cursor was generating most of the diff but the trailer didn’t say so. Copilot completions weren’t tagged at all.

So the first thing we did wasn’t ship more AI features. It was to make adoption visible. We built an internal AI dashboard to measure adoption.

The dashboard did something we didn’t fully predict: it created friendly competition. Once people could see who was at 40% and who was at 80%, the conversation shifted from “should I be using this?” to “what is that team doing that we aren’t?” Adoption stopped being a leadership push. It became peer pull.

The unlock was context, not capability

The single biggest jump in our trajectory goes beyond just a new model release. It was a working session in late February that turned into a sustained investment in three layers of agent context - each treated the way we’d treat onboarding docs for a new senior engineer.

At the top: org-wide standards - what is expected of all code written at Gametime. The universal bar on testing, observability, security, naming, and what “done” means anywhere in the company. In the middle: discipline-level files - how to do backend at Gametime, how to do mobile at Gametime, how to do data at Gametime - the conventions, and idioms specific to each function. At the leaf: repo-level CLAUDE.md and AGENTS.md files in our core repos - what this codebase actually believes, where the skeletons are buried, what you never do here.

The agent reads all three layers when it works. That stacked context - global standards inherited by every function, function-level rules inherited by every repo, repo-level specifics on top - is what turns a one-line prompt into a 400-line change that reads like one of your senior engineers wrote it.

By March, we’d folded that into the offsite. The pitch was simple:

The leverage isn’t in writing more code with AI. It’s in writing the agent context that makes every subsequent piece of code faster, safer, and more consistent.

That’s when adoption flipped.

Skills as the next abstraction

Once context was solved, the next layer was reusable agent primitives. We started with some open source skills and built the rest of the skills - packaged bundles of prompts, scripts, and checklists an agent can invoke for recurring work.

The gsd skill alone killed an entire class of “Claude wrote 400 lines solving the wrong problem” failures. The first time review-concierge caught a critical security issue that two human reviewers had already approved, the team's posture changed permanently.

These all live in a shared internal repo. New skills are written, peer-reviewed, and propagated like any shared library - the org’s collective memory of what good looks like.

We picked a platform, not a tool

A small but important decision: we standardized on Claude Code as the mass adoption surface, while staying multi-tool underneath. But the shared skills, context files, and review primitives target Claude - because picking one platform for the 80% case is what makes the harness work compound. The orgs we see struggling either bet the stack on one tool and got locked in, or stayed so tool-agnostic that nothing could be standardized.

Where we are today

Our dashboard (now telling the truth) puts us at roughly 80% AI-coauthored PRs across engineering, with web and mobile in the ~90% range and backend in the high L2s. Roughly a third of all merged PRs are now fully agentic - the human role is review, not authorship.

Two velocity unlocks compounded with the AI work. A web experimentation framework lets us start exposure on a new feature at a tiny percentage and scale up automatically as the metrics behave - agentic implementation plus low-risk rollout shrinks “code complete to production traffic” from weeks to hours. Over-the-air updates for our mobile app take the App Store gate out of the critical path for a large class of changes; AI-authored mobile fixes can ship the same day they’re written.

We have solid examples of projects that are shipping in days instead of weeks, in weeks instead of months.

One thing we’re clear-eyed about internally: velocity is not impact, and adoption is not efficiency. Velocity gets us to impact faster; an 80% adoption number measures shots on goal, not goals scored. We watch both, and we’re careful not to mistake the leading indicator for the result.

This is what L3 actually feels like. The AI is the developer. We are the managers.

Why L4 is a harness problem, not a model problem

Here’s the thesis we keep coming back to:

The companies that move from “we use AI” to “we engineer the harness around the AI” are the ones that pull ahead.

At L3, the bottleneck has shifted. Generating the change is no longer the slow step - verifying it is. The interesting harness work for L4 is about giving agents enough context and capability to prove a change is the right change: removing human reasoning from the PR review step itself, not just from the code-write step. That’s the next compounding move.

We’ve spent a decade on SDLC. The last several years on PDLC. The next loop is AIDLC - the AI Development Life Cycle. It requires primitives the previous loops never needed:

• Test infrastructure an agent can run, read, and respond to autonomously.
• Deploy paths with eval gates, automatic canary, and clean rollback.
• Eval harnesses that score agent output against acceptance criteria, regression suites, and business metrics.
• Observability an agent can query as easily as a human can.
• Human-in-the-loop and human-on-the-loop primitives that escalate the right decisions and let people intervene without stopping the loop.

That stack is what L4 looks like for us. Not “use Claude harder.” A real harness, owned and operated like any other piece of critical infrastructure.

The honest tradeoffs

A few parts aren’t tidy. Agentic workflows shift cost - less on typing, more on review, evals, and infra. They concentrate failure modes; when an agent is wrong, it’s wrong fast and at volume. They change what “senior engineer” means, and we’re being deliberate about how we onboard, mentor, and grow people in a world where the easy code writes itself. And we are watching the industry’s near-misses - agents touching the wrong database, agents running for hours unsupervised - closely. Speed without harness is a liability.

What’s next

This is the first of a series. Future posts will go deeper on the harness framework, evals as gates, the adoption dashboard, the skills repo, and what AIDLC looks like when it’s load-bearing rather than aspirational.

If you build infrastructure for a living, if you want to see what it looks like when an engineering org actually rewires itself around agents instead of bolting AI onto the side, we’re hiring. The interesting problem isn’t writing more code. It’s writing the harness that lets a small, sharp team out-ship orgs significantly larger in size.

Come build it with us.