Hero of prod: Sean Skiver

If you’re standing outside a stadium using Gametime to buy a last-minute ticket and the purchase fails, you’re not thinking about a data pipeline. You’re wondering why you don’t have your ticket.

A lot of what I work on at Gametime is ingestion. Every ticket starts with a supplier who sends inventory into our system, usually through an API. That same seat might be listed across several marketplaces at once, prices are constantly changing, and tickets can sell somewhere else at any moment. If ingestion falls behind, a customer can try to buy against stale data and have the purchase rejected, alerting my team. Even then, figuring out what happened isn’t always straightforward. Maybe our price was out of date. Maybe the seller rejected the offer for another reason. From our side, those outcomes can look very similar.

I’ve been at Gametime for nearly five years and my role has changed quite a bit during that time, especially as of recent. I still write code, but I spend more time now working with product on what we should build, figuring out how we’re going to build it, and looking for engineering problems underneath what the business is seeing.

Life before AI

Before AI, debugging production meant doing a lot of the digging yourself. One particular incident that sticks with me started when our ingestion pipeline slowed to a crawl. Latency was flashing red, worker queue depth was sky high, and the logs showed Postgres deadlocks. We’d seen deadlocks before, so we assumed concurrency might be the problem. We restarted Postgres and scaled in the application service, hoping fewer concurrent operations would relieve the pressure. It didn’t. Latency stayed high, disk usage spiked, and restarting Postgres only bought us temporary relief. We spent about an hour doing what I described at the time as giving the database CPR while trying to figure out what we were missing.

Eventually, we noticed the write-ahead log had grown enormously and started querying the Postgres system tables. That led us to a rogue data-syncing job running an expensive query against a read replica. The WAL was backing up, draining disk on the primary, and slowing Postgres enough to bring ingestion almost to a halt. We canceled the job, storage recovered, and ingestion returned to normal.

All of that was pretty normal at the time. You’d check the dashboards you already had, move into the logs, start pulling metric queries, and keep going until you found the answer. You might end up looking in ten different places before you understood what was happening.

Life after AI

For me, the change really started around the beginning of 2026. Coding was the obvious use case, but I’ve probably felt the bigger difference in everything surrounding the code.

I can take work that might have sat in my backlog indefinitely, hand off a first pass, review the implementation, and get it shipped. I also use AI heavily for analysis. If I want to understand why conversion changed across a group of events, I can have AI write the SQL and put together the reports and visualizations. Additionally, a surprising amount of engineering context lives in old Slack threads and scattered documents. If I want to know why we store a certain value in the database or what it’s used for, I can ask and get the history back without spending an afternoon reconstructing it.

And on the production side, when we have issues, I reach for Resolve. I can have Resolve look through metrics, find signals that look unusual or correlated, check whether a deploy lines up with what we’re seeing, and pull the relevant context together. I’m still deciding what matters and what we should do about it, but I don’t have to manually work through every dashboard, log, and metric query before I can start making those calls.

Paving the road for agents

I think there are two ways the engineering role changes from here. One looks a lot like platform engineering. Today, platform engineers make it easy to provision servers, get logging and metrics, put code quality and security controls in place, and deploy safely. We’re going to need the same kind of infrastructure for agents so they can write, test, and eventually deploy code with less human intervention.

The other side is knowing what you actually want them to build. You can tell AI to build a React app today and, without much more direction, you’ll probably get the same generic-looking React app every time. Engineers now must understand their product well enough to give AI the right context and know how a change interacts with the rest of the system. This becomes especially important as products get more complex. You might change one feature without realizing there’s another feature that heavily overlaps with it, or that the same data is being used somewhere else. Engineers have always had to carry some of that map in their heads, and I don’t see that going away.

AI still has a way to go, but I can already see myself spending more time paving the road for agents to do more of the implementation, so that us humans can spend time directing the build of what we actually want.