🚀 Introducing Flightpaths by Runway — read the announcement
🚀 Introducing Flightpaths by Runway — read the announcement

#29 - Jan 2026

Happy current year! It’s too late now to say “happy new year!” but this is our first newsletter of 2026, and we felt it was worth marking that with a special greeting. Anyway, welcome to 2026, which will be the Year of AI, just like 2025 was, and 2027 and 2029 will be. 2028 will not be the year of AI. Will it finally be the Year of Vision Pro? We’re not going to tell you so as not to spoil it.

What we will tell you, or at least share with you, are articles that discuss the sort of bugs caused by the 1000 commits problem, how to build AI agents in Kotlin, what mobile release teams are and when you might need one, the simple backend change that breaks every mobile app, and the winners of the App Store and Google Play awards.

Posts we liked

The 1000 commits problem

Claude Code’s latest release included a bug that broke the entire CLI. What’s interesting about the bug isn’t that it broke everything (what else is new?) but that it’s an emerging style of bug we should expect to see more of in the coming months: velocity bugs. As AI enhances every engineering team’s velocity, allowing them to ship 5 or 10 times as many commits, the sorts of bugs that may have previously been caught during a code review are now much more likely to ship. As Dave Kess puts it in his article, “We sped up the engine without upgrading the brakes.”

That simple backend change just broke our mobile app

How often have you heard something like this: “It’s just a small API change. Should be quick to update on your end, right?” Probably all the time. As we regularly hammer home in this newsletter, the web and backend engineers in your org likely don’t understand that a simple, quick update on their end is neither simple nor quick on yours, given the nature of shipping an app that people have to install on their own devices. Filipe Batista has written a guide you can share with the non-mobile devs in your org to help them understand.

The next two years of software engineering

We already revealed in the intro that 2026 and 2027 will both be Years of AI. But what exactly will that mean? Addy Osmani explores what the future holds for junior engineers (will the job market collapse or will junior engineers be in more demand to vibe code everywhere?), the role of engineers in general (will we be system orchestrators or LLM auditors?), whether coding skill will become more important as LLMs go wild creating their own unique forms of tech debt, and other open questions for the future of software development.

Building AI agents in Katlin - Part 4

Bruno Lanoo continues the series we linked to in the last Flight Deck about building AI agents using Koog, an open-source framework from JetBrains. He explores the process for building sub-agents, assigning each smaller tasks as you would software developers on an engineering team. He also very helpfully links to the previous parts of the series in case you missed them.

The genius system behind Uber’s real time map

In this very cool 10-minute video, Philipp Lackner explains exactly how Uber’s map works so well even as it manages real-time updates from millions of locations around the world every single minute. See how their in-house RAMEN (Realtime Asynchronous MEssaging Network) decides exactly when to push, what to push, and how to push it to the client.  

The App Store awards

Say one last goodbye to 2025 with Apple’s App Store Awards. Did you know that Cyberpunk 2077 was just released for Mac last year? This may be the first example of a game arriving late on Mac being a good thing that ensures players get the absolute best version. Also, the best game on iOS? It’s a Pokémon game.  

The Google Play awards

Actually, do you have another last goodbye to 2025 in you? See the apps and games that won Google Play’s Best of 2025. There’s no crossover in awards between the two platforms except for best game, which is, of course, a Pokémon game.

Go figure

Accelerating to a biweekly or weekly release cadence comes with obvious benefits, but it doesn’t imply that your team is now more efficient or better at releasing.

This won’t surprise you seeing as they’re shipping more often, but teams that release biweekly or faster experience proportionally more busywork and wasted time than those on slower schedules even though the whole point of shipping faster is to actually ship faster. Nearly half of these frequent releases cost 6 to 10 hours per cycle on tasks unrelated to the product.‍

As teams release faster, coordination becomes much harder without the right tools, and this has the counterintuitive effect of slowing down velocity and iteration. Larger organizations feel this even more, since their release processes are more complex. Learn more in our State of Mobile Release Management report.

Posts we wrote and events we hosted

[Recorded event] The hidden cost of mobile releases

Despite significant automation investments, mobile engineers still lose â…“ of their release cycles to busywork, coordination overhead, and firefighting. In this on-demand webinar, our panel of experts from Runway, Sentry, ClassPass, and Reddit explore the human and business costs of inefficient releases, as well as practical solutions for improving mobile DevEx.

What are mobile release engineering teams and when do you need one?

Very few mobile engineers have the bandwidth to focus both on building new features and wrangling the iffy Ruby scripts and automations that support releasing updates to those features, yet the expectation that they do both often lingers far past the point at which other teams in the org have specialized. So when is the right time to consider a dedicated person or team for mobile release engineering? Bruno Rocha has some great thoughts (as always).

Runway featured feature

As part of Runway’s rollback flow, we’ve always prepared rollback builds by re-signing an older, stable build. This is a quick and clean approach, but it comes with some limitations for certain teams.

You might be reading this right now and thinking “Rollback? You can’t rollback a mobile release, are you crazy?” And if you are thinking that, we encourage you to read more about Runway’s really real rollback feature.

Are you now at peace with the existence of a rollback option for mobile releases? Great! Because now there’s an alternative option for rollbacks to make them even more useful.  

Screenshot 2026-01-22 at 6.30.47 PM

This new option prompts Runway to automatically trigger the appropriate CI workflow on the appropriate commit and use the resulting build in the same way it would normally use a re-signed rollback build.

Events

It’s been a couple of months since we’ve had any events to announce. Now we have three, and they’re all happening at the exact same time across three continents. Turns out mobile releases aren’t the only mobile-related things that are hard to coordinate. In the month of April, come and see us at:

Until you’re able to see us at one of these events, feel free to visit one of our previous 28 newsletters and read about the events we were at in the past.

Release better with Runway.

Runway integrates with all the tools you’re already using to level-up your release coordination and automation, from kickoff to release to rollout. No more cat-herding, spreadsheets, or steady drip of manual busywork.