I spent almost 13 years at SeatGeek. Before I left, I charted my git and issue tracker activity, quarter by quarter. I figured it'd be a fun trip down memory lane. It turned out to be a pretty good map of how my role evolved over the years, and how much product development changed too.
2013 to 2016: Jack of all trades
I joined as the first product hire. In practice, that meant a little bit of everything: product, design, and frontend.
Everything also took longer, in ways that are hard to explain now. We were in a PHP Symfony app, and a real chunk of every week went into stuff like browser compatibility, local environment debugging, and review app coordination. Design feedback lived in GitHub issues. Before you could even give the feedback, you had to describe in words which part of the design you were talking about. And since high fidelity designs and prototypes were expensive to make, wireframes were the default way to bring to life an idea.
In addition to IC dev and design work, I was also managing our sprint process. It was a lot of fun, but as we grew, it became hard to balance all three, so I had to decide which areas to focus on. Coding was an itch I could scratch on my own through side projects (in languages I enjoyed a lot more than PHP). Running sprints and deciding what to prioritize was much harder to get reps on alone, so I decided to focus on design and product management.
2014 to 2022: From maker to manager
Picking design and product turned out to be the first step toward management. As we hired more designers, someone needed to lead them, and I was the natural person to do so. It started with one report, then a couple, then a team. As the team grew, my time for IC work slowly dwindled, which you can see in my issue management activity trends.
While I expected issue creation to slow down as I shifted my time to leading the design team, I expected my comment activity to hold more steady. However, the data says otherwise. I don't think I stopped giving feedback, but rather the places where we gave feedback and had more conversations about what to build started to move outside of GitHub issues and into tools like Slack, Figma, and docs.
2022 to 2025: Back to building
After a tour of duty leading the design team, I realized I missed being more hands on and focused on the product. A lot of my day was in meetings and on zoom doing meta "work about the work" instead of being focused directly on customer pain points and product opportunities. So in the second half of 2022 I decided to move back into a hybrid IC role splitting my time across design, code and product.
A lot had changed since 2013. React and Typescript had exploded in popularity. SeatGeek was now using Next.js. And every merge request spun up its own review app. I got up to speed on the latest frameworks and tools the old school way: via tutorials and books.
And then in 2023 a little thing called Claude was very helpful for answering my questions. And then in 2024 the powerful combo of Sonnet 3.5 and Cursor helped reduce my reliance on my command, c, and v keys from all the back and forth with Claude. In some ways I feel lucky that I moved back to an IC role before things really picked up steam, as it helped me brush up on the foundations in a way that would be much harder to do today.
2026: AI accelerated
As the models and harnesses got better, AI was accelerating the speed at which I could bring ideas to life. This became particularly noticeable with Opus 4.5. All of the sudden what used to take me weeks was taking me hours or days. It became clear that the way we build products was about to change dramatically.
It wasn't until I was on paternity leave during the last few months of 2025 that I truly understood just how powerful these models were. For the past couple years they have been good enough to kickstart side projects. But then the codebases got too large and complex for the models to grasp. Not this time. I just kept going and going, building what would have taken me years in just a couple weeks.
When I came back in early 2026, it was as if I stepped into a new role. My first project was building our ChatGPT app alongside one other engineer. We didn't use Figma, but rather prototyped several directions directly in code. The divergent exploration, implementation, and refinement was done end to end in a fraction of the time it would have previously taken.
In the first half of 2026 I added 3x more lines of code than in my previous 3 years of IC work combined. Mostly the same job, but the way I did it changed a lot. Much of my design exploration and refinement happened in code. I also started building custom tools for specific projects, which opened up whole new workflows. Something could go from idea to behind a feature flag in hours. Execution got compressed, and more of my time went to review, dogfooding, and QA.
The hidden value of friction
Looking back, a lot of this story is friction disappearing. In 2013, a real chunk of my time went to fighting browser compatibility bugs, debugging my local environment, and writing GitHub issue novels to refine ideas with others. In 2026, I can take a large, complex idea to a working version in an afternoon.
There's no question that less friction made me faster. I'm shipping a lot.
But the extra time didn't all go where I expected. I'm really proud of what I built this year, and my impact went up, but most of it came from a few big, focused wins. The long tail of smaller improvements mattered a lot less. I shot from the hip a lot. And while it felt productive in the moment, looking back, I wish I'd spent more of that time going deeper on the few things that mattered most.
I think friction was doing more work than I gave it credit for. When an idea took two weeks to build, you had to really believe in it before you started. When it takes an afternoon, it's easy to skip that step. The temptation is to use the extra time to build more things, rather than make better ones.
Speed vs. direction
I suspect this goes beyond my own experience. Models have gotten incredibly powerful, but products don't feel like they're getting better at the same pace. Maybe it's early and the gains haven't shown up yet. Or maybe a lot of us are choosing quantity over quality.
Speed alone only gets you so far. The real opportunity is combining it with good judgment about what to build, a willingness to explore and refine the details, and the patience to keep iterating until it's great. None of that has fundamentally changed since 2013.
As building gets cheaper, knowing what to build and having the patience to make it great will matter more than ever. That's where I want to focus my energy.