I'll be in the Bay Area for a few days Week 18. Ping me if you are around and wanna grab a coffee.

18.1 MB for a hello world app and nobody complains. Don't wanna live in this world anymore 😅

AI isn’t changing the job of engineering leadership. It’s amplifying it.
Our job has always been to turn raw contributions into reliable systems.
Before, that meant juniors & new hires.
Now, it also means agents & AI-augmented engineers.
What changed is the throughput.

Just because you can doesn’t mean you should.

Divide and conquer still wins.
Separation of concerns still wins.
Modularity still wins.

Why? Because complexity is expensive. For humans (cognitive load, pace, quality) and for AI (reasoning depth, latency, token burn).

Fighting complexity still pays off.

The fundamental shift with modern AI: the time it takes to execute is starting to match the speed at which ideas appear.

AI in software engineering is a megaphone: it makes both good and bad developers louder. The difference? One is music. The other is noise.

The more I read about it, the more I think it should be a build system responsibility instead. Can be done instance leveraging Bazel module visibility for instance.

Two rooms, two vibes

We already have a branch (thanks Codex) where we switch to it and TBH it is much better than it used to be. But you still have some stuff to deal with manually (manifest generation, manifest merging, etc.)

We are seriously considering migrating to Bazel. Of course because everything but Android is Bazel built at amo forcing us to have interop between Gradle and Bazel. But also because of the poorly design configuration phase (vs analysis phase on Bazel)

We also have "sample apps" (I guess your "dev apps") but they I consider them as "patches". They come with drawbacks: lots of "non production" code and, friction on LSC, increase combinatory in your product/states, hard to distribute internally (product want a single app with all features…), etc.

Interesting. On CI, our experience is CC is useless because not "sharable". Also, 80% of the time, a gradle.kts file changed.

Configuration on demand: we build absolutely everything on CI so 😅 "

We have another problem with this approach: Gradle configuration time 😅. Because Gradle (for now - Isolated Projects 👀) sequentially configures projects, adding new modules slows down build time a lot (basically 2/3 of our build time is configuration vs execution).

But agree with the approach.

3. The identifiers module undermines extreme modularization. For example, if you create a new app using only a subset of your main app’s features, you’ll end up with irrelevant types at compile time (though tree shaking can remove them).

2. The identifiers module has no strong ownership that it’s unclear who truly owns it, especially since it contains identifiers from multiple features. If everyone can edit it, it effectively belongs to everyone. And thus to no one.

1. The identifiers module becomes a sink module that every other module depends on. Any change to its ABI will force recompilation of all dependents.

It’s interesting because we discussed this exact topic with colleagues for an hour yesterday. Half of the team supported your approach, while the other half, myself included, opposed it. While our contexts differ, my main arguments are

It will remove the message (default behavior) or remove/keep the check entirely.

We've been doing it since day 1 already. Any reason it's not done for "throw" checks @rahulrav.com?

Compile-time flagging is a game-changer for large codebases. Just be sure to expose these variants only at the highest level of your build. If you don’t, you’ll end up with combinatorial complexity leaking everywhere in your code.

> We fixed a few minor bugs that were causing problems.

Thanks for that detailed changelog. Super helpful 🤦‍♂️

Look who joined the meetup 😂

🙈

🤷‍♂️

The @parisandroid.bsky.social is about to start. Let's begin with Compose magic 🤩

Meetup de Janvier chez amo 👑, Tue, Jan 13, 2026, 7:00 PM | Meetup Bonne année 2026 à tous 🥳! On vous souhaite une bonne dose de Kotlin, d'Android, d'interfaces réactives & intuitives et surtout du code bien propre ✨! Pour commencer sur

Thrilled to meet the Android community tomorrow and dive into video generation, dependency injection, and compiler plugins!

Don’t miss out, register now: www.meetup.com/android-pari...

We talk a bit about it here: amo.co/tech-stack-a...

We indeed migrated to Metro back in August 2025 all of our Android project (~500 modules). We have nothing using KMP. Everything is fully Android specific as we have our own approach to multi-platform (shared Rust code).

Meetup de Janvier chez amo 👑, Tue, Jan 13, 2026, 7:00 PM | Meetup Bonne année 2026 à tous 🥳! On vous souhaite une bonne dose de Kotlin, d'Android, d'interfaces réactives & intuitives et surtout du code bien propre ✨! Pour commencer sur

Don’t forget to register: the number of spots is limited! 👀

www.meetup.com/android-pari...

Join us with @ParisAndroidUG at @amoamoamo HQ on Jan 13, 2026! 🚀

On the agenda: generating videos off-screen and off-main thread from Composables, why & how we switched from Hilt to Metro DI, and how to build your own Kotlin compiler plugin.