iiinova — where your digital self keeps evolving

Cyril Mottier @cyrilmottier.com · 29/07/2026

Looking forward to knowing too! We "only" have 700-ish for now (well way more actually but the rest is Bazel-based). I guess you guys had multiple optimizations around config time. So might not be as visible proportionally. Didn't mention it but IDE sync times are also impacted very positively.

010

Cyril Mottier @cyrilmottier.com · 28/07/2026

Maintenant on attend Rust et Bazel 😛

101

Cyril Mottier @cyrilmottier.com · 28/07/2026

The structure itself is not fundamentally different. The shift is now we really modularize while we used to tend to merge modules together when they shouldn't just because modules were expensive.

010

Cyril Mottier @cyrilmottier.com · 28/07/2026

We’ve been running with Gradle’s Isolated Projects for a few months now, and it’s been a game changer for our build times 💥. An unexpected benefit: because modules are much cheaper now, we’ve completely rethought how we modularize our app.

370

Reposted by Cyril Mottier

Romain Guy @romainguy.dev · 21/07/2026

I published vibrance-0.1.0 on Maven, now with support for Compose for Desktop (JVM). The APIs let you mix colors yourself, or draw gradients as modifiers or Compose brushes. Next steps: refine the model training to improve some color transitions, better alpha support. github.com/romainguy/vi...

24110

Cyril Mottier @cyrilmottier.com · 18/07/2026

We already switched entirely to it a few months ago. It's a game changer so far. Much more consistent build times, way faster configuration times. Super happy so far.

010

Cyril Mottier @cyrilmottier.com · 17/06/2026

TIL kotlinlang.org/grammar/#nul...

110

Cyril Mottier @cyrilmottier.com · 02/06/2026

Tested again and config phase takes 25 seconds on my Mac. The fact we have 2 build systems (Bazel for everything native and Gradle for everything Android) running in parallel on the same machine is probably a problem too.

130

Cyril Mottier @cyrilmottier.com · 02/06/2026

Did it already back in the days but only on local machines where it's x2 to x5 faster at least. Need to redo it on CI! I also know it's impacted by our "special" setup (Gradle launching Bazel and its own configuration phase called analysis phase)

110

Cyril Mottier @cyrilmottier.com · 02/06/2026

About 1,5 to 2 minutes for 600 subprojects

000

Cyril Mottier @cyrilmottier.com · 01/06/2026

Are these numbers including the configuration phase? In our case (hundreds of modules and ephemeral runners), it's clearly the biggest pain point (2/3 of the whole time spent) 😔

100

Cyril Mottier @cyrilmottier.com · 20/05/2026

Can't wait to meet the Kotlin community @kotlinconf.com for the next 2 days. You can find me on Bump 😛. See you tomorrow 👋

040

Cyril Mottier @cyrilmottier.com · 11/05/2026

I often describe engineering leadership as choosing "the least flawed decision." There are no perfect trade-offs in software. Every choice has a cost. The job is to understand those costs, make them deliberately, and slow system entropy better than competitors.

050

Cyril Mottier @cyrilmottier.com · 06/05/2026

"Software engineering is programming integrated over time" has never resonated more. Programming is getting close to free. The hard part is building systems that can live, change, and remain reliable over time.

030

Cyril Mottier @cyrilmottier.com · 27/04/2026

A strong signal that your feature was designed well: it has clear boundaries. So clear that removing it feels like using a scalpel: delete a single directory, not start an excavation.

030

Cyril Mottier @cyrilmottier.com · 17/04/2026

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

020

Cyril Mottier @cyrilmottier.com · 10/04/2026

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

270

Cyril Mottier @cyrilmottier.com · 10/04/2026

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.

040

Cyril Mottier @cyrilmottier.com · 07/04/2026

Just because you can doesn’t mean you should.

120

Cyril Mottier @cyrilmottier.com · 18/03/2026

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.

040

Cyril Mottier @cyrilmottier.com · 09/03/2026

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

000

Cyril Mottier @cyrilmottier.com · 26/02/2026

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

060

Cyril Mottier @cyrilmottier.com · 05/02/2026

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.

010

Cyril Mottier @cyrilmottier.com · 03/02/2026

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.)

120

Cyril Mottier @cyrilmottier.com · 03/02/2026

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)

110

Cyril Mottier @cyrilmottier.com · 03/02/2026

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.

130

Cyril Mottier @cyrilmottier.com · 03/02/2026

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 😅 "

200

Cyril Mottier @cyrilmottier.com · 03/02/2026

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.

110

Cyril Mottier @cyrilmottier.com · 03/02/2026

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).

110

Cyril Mottier @cyrilmottier.com · 03/02/2026

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.

110

Cyril Mottier @cyrilmottier.com · 03/02/2026

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.

110

Cyril Mottier @cyrilmottier.com · 03/02/2026

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

100

Cyril Mottier @cyrilmottier.com · 22/01/2026

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?

010

Cyril Mottier @cyrilmottier.com · 21/01/2026

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.

020

Cyril Mottier @cyrilmottier.com · 19/01/2026

> We fixed a few minor bugs that were causing problems. Thanks for that detailed changelog. Super helpful 🤦‍♂️

120

Cyril Mottier @cyrilmottier.com · 13/01/2026

Look who joined the meetup 😂

230

Cyril Mottier @cyrilmottier.com · 13/01/2026

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

1100

Cyril Mottier @cyrilmottier.com · 06/01/2026

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

040

Cyril Mottier @cyrilmottier.com · 06/01/2026

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).

140

Cyril Mottier @cyrilmottier.com · 06/01/2026

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.

154

Cyril Mottier @cyrilmottier.com · 02/01/2026

That's one of the advantage of Android over iOS. On iOS, the choice is definitely not that easy...

020

Cyril Mottier @cyrilmottier.com · 23/12/2025

Big news. On January 13, 2026, amo is serving up something special for the @parisandroid.bsky.social 🚀. Think Metro DI insights and video magic from Composables. Stay tuned after the holidays for all the details!🍹

070

Cyril Mottier @cyrilmottier.com · 23/12/2025

Agree it's indeed more efficient in the backend (and can be cached). It comes with one major issue though: you get the backend point of view (i18n, l10n, blocked IPs, etc.)

110