We want to share it more broadly because we think it's useful well beyond Square, and it's one of the things we are most proud of building into our team culture.

Background

Keeping track of your professional wins is important. Let's face it, it's easy to forget or overlook them when things get busy. The idea of a hype doc started at Square within the Women in Engineering community. A former Square engineer wrote about it on Medium, breaking down why having a hype doc is a game-changer and how you can use it to advocate for yourself by keeping track of your own accomplishments. While people traditionally kept hype docs as personal Google documents, integrating them directly into Slack channels takes this practice to a whole new level of ease and effectiveness.

I started my hype doc in Slack¹ after struggling to maintain a traditional one. I wanted to keep track of my accomplishments, but found the usual approach full of friction:

• The doc lived outside of where work actually happened, which made it easy to forget.

• I had to copy messages, links, or screenshots across different tools, often breaking context or losing detail.

• It wasn't always clear what to include: should I paste a screenshot, a link, or both?

• Updates felt like a chore instead of something quick and lightweight.

To make the process easier, I worked with my manager to figure out how a dedicated Slack channel could serve as a living, low-friction hype doc. This setup allowed us to stay aligned in real time, capture wins as they happened, and reference specific accomplishments when it mattered most without ever needing to leave the tools we were already using every day.

This small adjustment to reduce friction ended up creating a lightweight system that anyone can adopt. Let me break down why hype channels can be so valuable, starting with the benefits for engineers.

For Engineers

Having your own dedicated hype doc channel in Slack has lots of practical benefits. Slack's real-time format makes it super easy to add your accomplishments on the fly. You can instantly forward messages, shout-outs, or project highlights into your hype channel, which means you're more likely to capture achievements as they happen. This can also track support work that takes place in Slack that otherwise goes untracked in other software such as Github (PRs) or Jira (tickets). Since Slack is already central to your everyday work, it's natural to update your hype doc regularly without extra hassle.

On top of that, this setup streamlines the entire process:

• Automatic time tracking - Timestamps are automatically recorded, so there's no manual logging required.

• Real time notifications - Interested parties can choose to be notified or tagged in real time making it easy to "manage up" or tag collaborators.

• Easy search and summarizing - Whenever wins need to be resurfaced, Slack has an excellent search interface that makes it painless to find what you need.

This habit boosts confidence, encourages proactively advocating for yourself, and helps you easily recall important accomplishments during performance reviews or when you're preparing for promotions.

One engineer I worked with created a Slack Workflow (IC Hype Tracker) to categorize & track hype feedback in a way that maps directly to engineering level expectations. This easily enables quick searching for relevant content in the hype channel when writing promo packets or reviewing performance with a manager.

Several engineers also made their hype doc channels open for transparency and as examples for others. 👏👏👏

Engineer Testimonials

Here's what some of the engineers who adopted this practice had to say:

Testimonial 1

I had previously kept a hype-doc using Google Docs, but transitioned to using a Slack channel to take advantage of some automation tricks and more easily track Slack-native content.

This engineer configured the Reacji Channeler Slack App to cross-post hype-doc content by reacting to Slack messages with a custom emoji. It had a few positive effects:

1. It removed friction from tracking hype-doc content.

2. It encouraged other individuals to track their own hype doc content by alerting followers of a message or conversation when hype doc content was logged.

3. It encouraged tracking smaller pieces of hype more often, creating a larger narrative pool to draw from when reviewing performance.

Testimonial 2

I tried using a notion doc and found myself just duplicate tracking my jira tickets.

This engineer shared some tricks they use in their hype channel:

Sharing private DMs. This will only share the one solitary message and not an entire thread, but is often sufficient for surfacing work with your EM that is brought to your attention in private DMs before you move it to a public channel, or if you're sent a kudos privately.

Leveraging slackmoji reactions for categorization and retrieval. You can flag each message with a slackmoji and later search your hype doc for a specific emoji. You could use this for easy retrieval for impact, behavior, and betterment.

Summarizing when forwarding. Each time you share a thread to your hype channel you can summarize what the hype is.

Testimonial 3

I had tried, unsuccessfully, to keep a hype doc in Google docs for years. Creating a slack channel was so much easier. Most of the work happens, or is documented, in Slack. It's trivial to share a post to my hype channel, and it usually already has screenshots, videos, and links. This makes it that much easier when assembling a promo packet, because you can quickly jump to the post and gather all of the context. It's also obviously a great platform to discuss your hype entries with your manager as they happen.

Testimonial 4

Like others, I've struggled to keep up a hype doc and when it came time for promo or performance conversations I needed to spend a lot of after hours time getting these artifacts together. I just started using a Slack channel, but with the automations available via emoji reactions and lower friction my initial experience has been positive.

For Managers

Managers get plenty of value from Slack-based hype docs too. When managers join these hype channels, they get to celebrate their team's wins right away. This makes it easy for them to stay informed about their engineers' successes, strengths, and growth areas in real-time. This is especially helpful for managers with a lot of direct reports or multiple teams.

These channels are also incredibly helpful when it's time to give feedback. They provide a steady stream of concrete examples that make it easier to offer thoughtful, consistent input, and they help make evaluations simpler, fairer, and more transparent.

Managers can quickly forward notable achievements from a hype channel into larger team or leadership channels, making recognition visible across the company. Another big perk: if there's ever a change in management, simply adding the new manager to the existing Slack hype channel immediately gives them all the historical context they need.

Creating a dedicated Slack section for ICs' hype channels also helps maintain Slack organization.

Summary

In short, turning hype docs into Slack channels makes tracking and celebrating accomplishments easy and effective. It simplifies the process for engineers, helps managers stay engaged and informed, and creates a positive, recognition-rich team culture. Adopting Slack-based hype docs contributes to happier, more motivated teams and a workplace where everyone's contributions are noticed, appreciated, and celebrated. Create yours today!

Footnotes

1. We used Slack and I refer to this throughout this post, but any tool you have at work where you can set up a channel for you and your manager should work!

I originally wrote this guide while working at Square to help my teams address a recurring problem: feature flag overrides applied during incident response were quietly becoming permanent, creating drift between production and staging environments. The advice below is a generalized version of that internal doc, applicable to any team using a feature flag provider.

The Problem

When users report regressions after a new feature rollout, we often respond quickly by removing the affected user from the feature flag rollout or rolling back the flag entirely. While this is the right call for immediate mitigation, the response often creates a long-term maintenance burden: we forget to re-enable the flag or re-enroll the user after the issue is resolved.

These temporary overrides become permanent by accident.

Why This Matters

This leads to fragmented experiences:

• Invisible divergence: A user is running a different path than what we see in day-to-day development, making future bugs harder to reproduce or explain.

• Rollout inconsistency: Features meant to be universally available instead become fractured across the user base.

• Technical debt: Overrides accumulate and become difficult to audit, track, and reason about.

The Cost

Permanent overrides erode our confidence in rollout data and introduce edge cases we didn't plan for. They can also block future rollouts, since we end up tiptoeing around previous exceptions rather than treating the root cause.

In short: they reduce predictability and slow us down.

The Solution: Scheduled Rollback of Overrides

Most modern feature flag providers (LaunchDarkly, Statsig, Flagsmith, Split, etc.) support scheduling the automatic removal of an override. This should be your default approach whenever you respond to a user-facing issue with an override.

Rather than relying on human follow-up or future cleanup work, make the override temporary at the moment it's applied while moving forward to fix the underlying issue.

Example Workflow

Let's say a user hits a bug due to a recent flag rollout:

1. Override with an expiration. Target the user in your feature flag provider to disable the flag, and schedule the override to be removed automatically, timed to when you expect the fix to ship.

2. Fix the root cause. Plan and ship the fix through your normal release process.

Because the override already has a time-to-live, the user re-enters the rollout path automatically once the fix is deployed. No manual cleanup or tracking required.

How To Do It

The exact steps vary by provider, but the general pattern is:

1. Navigate to the flag in your provider's dashboard.

2. Add the affected user to an individual targeting or exception rule.

3. When adding the override, look for a "schedule removal" or "add expiration" option. Most providers surface this inline or through a calendar/date picker.

4. Set the expiration date to align with your expected fix deployment.

5. Confirm the scheduled change.

If your provider doesn't support scheduled removal natively, create a ticket or calendar reminder at the time of the override. The point is to make cleanup a commitment, not an afterthought.

This year at Square we started shipping aggressively. Powered by a completed migration, new feature roadmaps, and AI adoption, we shifted into a build, demo, iterate, ship cycle. My team was showing our work to other engineers all the way up to the C-suite. To help us stand out I put together a short framework of how to make demos great, especially while shipping fast and showing progressive improvement.

This is that framework.

Why Not What

The "what" in a demo is obvious, it's on the screen. The audience can see the buttons and the flow of the UI. What they can't see is why it matters. Stories ground the features we build by making an example of their usefulness. Without a story, the audience is left to guess the value.

Fine vs. Great

Fine Demo: What was built

"We added a modifier button to the order screen."

Great Demo: The problem it solves

"Baristas needed a faster way to customize drinks during rush hour without slowing the line."

Fine Demo: Walks through features

"First you tap here, then select the size, then add modifiers from this menu..."

Great Demo: Tells a customer story

"A regular walks in and orders their usual. The barista pulls up their history and the order is ready in two taps."

Fine Demo: Audience evaluates the work

"We implemented item search using the new API and added caching."

Great Demo: Audience imagines the user whose day got easier

"Now when the line is out the door, the barista isn't fumbling through menus, they're making drinks."

Lead With a Story

Before showing anything, answer these four questions from the user's perspective:

1. Who are you? Give the audience a person to root for.

2. What are you trying to do? Set up the job to be done.

3. What was painful before? Make the problem known.

4. What's different now? Show the contrast.

Demo Recipe

Follow this structure to build a compelling narrative!

1. Open with a one-sentence persona + goal

   "A seller at a busy counter needs to get someone checked out fast."

2. Name the pain in one sentence

   "Before, this meant digging through three menus to find the right option, which backed up the line."

3. Show the happy path first One clean flow. No detours, no edge cases. Just the thing that proves the value.

4. Call out the moment of value Don't make the audience guess. Say it:

   "This is the part that used to take 30 seconds. Now it's two taps."

5. Close with the outcome Time saved. Fewer errors. Clearer decisions. Happier customers. Name the win.

6. Save build details for the end Technical deep-dives are great for people who want them. Offer them as a follow-up, not the main event.

Make It Stick

Critical

• Visibility Matters - Introduce yourself and your team at the start, call out contributors by name when showing their work, and share credit generously. Demos are a team effort!

• Keep it short - A tight demo is 1–3 minutes, not 10.

• Trust your instincts - If it feels too short, it's probably right.

• Rehearse once - Even one dry run catches awkward transitions and filler words.

• One takeaway - What's the single sentence the audience should walk away with? Know it before you start.

Polish

• Clean your environment - No "Test User 69." Realistic data makes it believable.

• Consider a backup - Live is better, but a 30-second video or a few screenshots can save the moment.

• Handle questions at the end - "I'll cover that at the end" keeps the flow intact. Answering mid-demo often derails the story.

Credibility

• Own the gaps - Call out what is missing and what's coming next.

Common Traps

Don't apologize for what's not done yet

• ❌ "Sorry, this part isn't quite finished but…"

• ✅ "This is in progress - here's what's coming next."

Don't detour into bugs or edge cases

• ❌ "Now if you do this weird thing, it breaks but…"

• ✅ Save edge cases for Q&A unless they're critical to the story.

Don't narrate clicks

• ❌ "And then I click here, and then I click here…"

• ✅ "I'll add the modifier…" (while clicking)

Handling Q&A

• Repeat the question - Ensures everyone heard it and gives you time to think.

• Bridge back to the story - "That's a great question about [XYZ]. Remember our bartender…"

• Defer deep dives - "That's a great technical question, let's sync after."

• Make space for multiple voices - Take the lead and go through the queue of people asking questions. Take one or two from an individual before moving on.

Know Your Audience

• Leadership - Focus on outcomes and metrics. "This saves $2 or 2 minutes per transaction."

• Engineers - Show the happy path, then offer technical deep-dive. "Want to see how we handle error handling?"

• Customers - Emphasize ease and reliability. "You'll never lose a sale again!"

At Square, most of the app is built on Workflow. There is an internal testing framework that lets you assert exactly how many render passes are triggered for a given interaction which is then enforced by CI.

I led the team that optimized the Select Payment Method screen in the Square Point of Sale app. We traced through the render tree, cut unnecessary render passes, and reduced overall latency by 30%! Each render was doing extra work, so consolidating effort and lowering the render count directly contributed to better performance.

The bigger win was what happened after. We wrote tests that asserted the the new and improved render counts we'd achieved. If a future change caused extra renders to show up, CI would fail and our performance gains couldn't silently regress.

The Problem with Compose

Workflows have renders. Compose has recompositions.

There's only a few ways to get insights into how Composables are performing.

• Layout Inspector requires being in an IDE¹, manually checking a running app, and it doesn't run in CI.

• "SideEffect guarantees that the effect executes after every successful recomposition" and can be used to count them. But they litter production code with debugging infrastructure.

Neither gives you a testable contract enforceable on every PR.

Introducing Dejavu

Dejavu turns recomposition behavior into test assertions. No production code changes beyond Modifier.testTag(). (which you are probably using already)

Setup

// Create a Recomposition Tracking Rule
@get:Rule
val composeTestRule = createRecompositionTrackingRule()

@Test
fun incrementCounter_onlyValueRecomposes() {
  // Perform an action
  composeTestRule.onNodeWithTag("inc_button")
    .performClick()

  // Assert that Composables change like you expect
  composeTestRule.onNodeWithTag("counter_value")
    .assertRecompositions(exactly = 1)

  // Or assert that they remain stable
  composeTestRule.onNodeWithTag("counter_title")
    .assertStable() // asserts recompositions = 0
}

Same pattern as any Compose UI test.

• Find a node by tag

• Perform an action

• Assert your expected recomposition count!

When a test fails, you get diagnostics that tell you why:

dejavu.UnexpectedRecompositionsError: Recomposition assertion failed for testTag='product_header'
  Composable: demo.app.ui.ProductHeader (ProductList.kt:29)
  Expected: exactly 0 recomposition(s)
  Actual: 1 recomposition(s)

  All tracked composables:
    ProductListScreen = 1
    ProductHeader    = 1  <-- FAILED
    ProductItem      = 1

  Recomposition timeline:
    #1 at +0ms — param slots changed: [1] | parent: ProductListScreen

  Possible cause:
    1 state change(s) of type Int
    Parameter/parent change detected (dirty bits set)

See the Error Messages Guide for more information.

What Makes Dejavu Different

Dejavu hooks into CompositionTracer so there's no compiler plugin, bytecode manipulation, or Gradle plugin.

Causality analysis is a best effort attempt to explain why we had a recomposition. It tracks Snapshot state changes and maps dirty bits back to parameter slots.

All Composable are tracked by default. testTag only required for the assertion API with onNodeWithTag("x").

The tracer itself tracks every composable that gets traced via CompositionTracer, regardless of whether it has a testTag. The tag mapping just bridges between testTag and function name so assertions can find the right counter.

An AI Agent's Blind Spot

AI agents are writing Compose code. They refactor screens, hoist state, extract components, and they're mostly good at it. There's currently no way for an Agent to deterministically know it negatively (or positively) affected recompositions.

We humans are relying on the model to get it right as the ever growing avalanche of PR reviews comes barreling towards us. UI tests could pass and look fine in the CI recordings, but users start leaving negative reviews about jank.

Dejavu gives you, your CI, and your Agents the ability to run UI tests and validate that there are no unexpected changes.

The error messages work for both audiences. A human or an agent can read the failure and knows what to fix. And if an agent regresses recomposition CI fails and the PR doesn't merge.

You can also stream events in real time with Dejavu.enable(app, logToLogcat = true). An agent running adb logcat -s Dejavu gets a live feed of per-instance composition state while iterating on a running app.

Get Started

androidTestImplementation("me.mmckenna.dejavu:dejavu:0.1.2")

Full documentation · Getting Started · Examples · API Reference · GitHub

If you've ever stared at Layout Inspector wondering why a composable recomposed, or wished you could just assert on it in a test, give this a try and please let me know how it goes!

Whats next?

Lots of real testing! I added a pretty expansive test suite to measure correctness, but Compose is so expressive and adaptable I'm sure there are things I missed. If you find bugs I'd love to know what they are.

Footnotes

1. At Square we were beginning to have weekly discussions about the value of an IDE in today's AI enabled world. Whats your take?

Claude Code supports custom status lines, so I put one together for my workflow as an Android dev, with some iOS support too!

Here's what I ended up with:

⌸ my-app · Opus 4.5 · [████░░░░▒▒] 45% · +127 -34 · $2.15 · feature/auth* · mcp:1
⬢ emulator-5560 · ⬡ emulator-5562

I'll walk through each piece and why I find it useful.

The Icon

The icon is purely decorative. Giving each project its own icon just makes switching between repos feel a little more intentional. It's just fun.

Directory

I often have multiple Claude instances running across different projects. Seeing which directory Claude is working in helps me stay oriented. The status line shows where Claude was started, and it abbreviates the path when it navigates into subdirectories so it doesn't take up too much space.

Model

Having the model name visible means I don't have to think about which one I'm using. Small thing, but it removes a bit of mental overhead.

Context

The [████░░░░▒▒] bar shows how much of the context window I've used. Before I had this, I’d get surprised by compaction. Now I can see when I'm getting close to the limit and wrap up more intentionally or preemptively compact. It's helped me be more proactive about starting fresh sessions when needed.

Lines Changed

Seeing +127 -34 keeps me mindful of my teammates. Someone is going to review this code, and I want to make that experience as smooth as I can.

When I notice the numbers getting larger, it's a good signal to pause and commit what I have. Smaller changes are easier to review and easier to talk through. This little reminder has helped me stay more thoughtful about the code I'm generating before handing it off.

Cost

I find it helpful to see what a session is costing. It's not about watching every dollar, it's more about staying aware. Some problems need deep exploration, others should be quick. Having the number visible helps me calibrate.

Branch

Seeing the current branch helps me avoid mistakes. Nothing fancy, just useful to have in view.

MCP

If you're using MCP servers, mcp shows they're connected. Helpful for ruling things out when debugging. Sometimes they can fail to start.

Devices

This is the part that's most specific to mobile dev.

The second line shows my connected emulators and simulators. I can see what's available, which device is currently targeted, and through configuration the version of an app installed on each one. This makes it easy to ask Claude to target a specific device, and I can verify that builds installed correctly without switching windows.

If you're working on Android or iOS, having visibility into your devices is really helpful.

Try it for yourself at claude-mobiledev-statusline! It’s configurable via a json file.

If something's missing or broken, let me know on Bluesky or open an issue. PRs are welcome! 💚

My typical setup is one agent on a larger task, a feature or refactor, and one or two others on smaller things like a UI tweak or bug investigation.

As an Android dev, there’s an obvious downside. My laptop takes a beating when running multiple gradle tasks.

When both agents decide to run Gradle at the same time, my machine grinds to a halt. One instance of Gradle is already resource intensive and running multiple builds at the same time makes them compete for resources. A build that normally takes 3 minutes stretches to 15. The fans spin up. Everything freezes. And if they're both trying to deploy to the same emulator, you get task clashing on top of it.

The agents don't know about each other. They can't coordinate.

The Workarounds

There are a few options here, and none of them are great.

You could run multiple emulators so each agent has its own target. Now you're burning even more resources on a machine that's already struggling and we didn’t solve the multiple expensive task problem.

So you could manually sequence the tasks yourself. Wait for Agent A to finish its build before letting Agent B run. But now you're babysitting the agents instead of doing your own work. The whole point of running multiple agents is to get more done in parallel, not to become a human task scheduler.

Either way, you're giving up something, time, resources, or attention.

What I Tried First

I built a CLI wrapper. The idea was simply wrap the command and the calling context and they go into a First In First Out (FIFO) queue. One runs at a time, the rest wait.

queue ./gradlew build

Technically it worked, but there was a problem I didn't anticipate.

AI coding tools have shell timeouts.

Claude Code gives you about 2 minutes by default. Cursor hard-codes 30 seconds. If your command is waiting in queue when the timeout hits, it gets killed.

Then the agents “be smart” and try to run the command without calling into the queue mechanism defeating the whole purpose.

I tried extending the timeouts with environment variables. That helped for Claude, but Cursor's limit isn't configurable. Even with longer timeouts, the issue of waiting compounds because we realistically only want timeouts for execution time, not waiting time.

Why Model Context Protocol Works Better

Model Context Protocol (MCP) Tool calls don't go through the shell. The agent connects directly to an MCP server, and that connection stays alive until the Tool returns. There's no external timeout to worry about.

With a CLI, the agent spawns a shell process, the shell runs your command, and if the shell process takes too long, the agent kills it. With MCP, the agent calls a Tool and waits for the response. No shell, no timeout!

So I rewrote the queue as an MCP server. Same concept, FIFO queue, one build at a time, but the timeout problem goes away.

How It Works

Agent A calls run_task with a Gradle command. The MCP server queues it, runs it, returns the result. If Agent B calls the same Tool while A is running, B waits in the queue until A finishes. Both agents block on their Tool calls, but neither times out.

Here's what that looks like in practice:

Agent B's build only took 32 seconds because it didn't have to compete with Agent A. Gradle's daemon was warm, caches were populated, the machine was free.

Total time: 3:45. Without the queue, both builds fighting each other would've taken 10+ minutes, and my laptop would've been unusable.

The implementation is about 600 lines of Python. SQLite with Write-Ahead Logging (WAL) mode for the queue state. Process groups to clean up orphaned builds if an agent crashes. Output goes to log files to avoid eating up context window tokens.

If you're using Claude Code, you'll want to add instructions to your CLAUDE.md telling it to prefer the MCP Tool over the built-in Bash for build commands. Otherwise it'll just run Gradle directly and skip the queue. The README has the snippet that I use.

Try It Out!

If you're running multiple AI agents on the same machine and they're triggering expensive operations (builds, tests, docker commands) this might help. The agents serialize automatically instead of fighting over resources.

It's open source under Apache 2.0 and you can install it with uvx:

uvx agent-task-queue@latest

Works with most AI coding tools that support MCP. Check out the repo at github.com/block/agent-task-queue for setup instructions.

If you try it out, I'd love to hear how it goes. Open an issue on GitHub or reach out on Bluesky!

In mechanical engineering, "tolerance" is the permissible limit of variation in a physical dimension. It is the acknowledgement that the world isn’t perfect, and designs needs to account for that.

A plastic cup holder in a car has high tolerance. If the mold is off by a millimeter, or if the plastic warps slightly in the summer heat, it doesn’t matter. Your drink will still fit. The user experience remains intact.

A piston ring inside the engine block has extremely low tolerance. If it is off by a fraction of a millimeter, the seal fails, the compression drops, the engine seizes. The margin for error is effectively zero.

We can understand this intuitively in the physical world. You wouldn't use cheap plastic for a piston, and you wouldn't precision machine a cup holder out of hardened steel.

In software, we tend to treat our code bases more or less as uniform constructs. We apply the same processes, the same speed expectations, and increasingly, the same AI tools to every part of the system. We are being asked to "vibe code" our way through mission critical code and it’s dangerous.

If we want to use AI to accelerate delivery we need to stop asking "Can AI write this?" and start asking "What is the tolerance of this part of our system?"

I want to propose a way to categorize this into three specific software engineering tolerances.

1. Logical Tolerance

This is the permissible limit of deviation from truth. How "correct" does the output need to be?

• High Tolerance: An animation, a prototype script, or some internal tooling. If the animation jiggles a bit or the script needs a retry, the failure state is annoyance.

• Medium Tolerance: Search rankings, recommendation feeds, or "eventual consistency" counters (like a view count). If a user has 42 likes but the screen says 41 for a few seconds, or if a search result is ranked #2 instead of #1, the product may be “imperfect”, but it is still viable.

• Low Tolerance: Idempotency keys, math, encryption standards, and payment execution. The failure state here isn't annoyance; it’s liability.

Generative AI is a probabilistic tool. It is a variance generator. It excels in High Tolerance zones because "mostly right" is often good enough. In Low Tolerance zones, like the payment path my team manages, correctness is binary. Code that is 99% correct will 100% fail for some uses.

2. Volatility Tolerance

This is the permissible limit of change a system can absorb. How stable is the system throughout change?

• High Tolerance: A standalone microservice, a one-off migration script. These can change daily with minimal blast radius.

• Medium Tolerance: Feature-level business logic, like a User Profile screen or a Settings page. These evolve regularly based on product requirements, but they rely on stable foundations and can't break every week.

• Low Tolerance: Core platform libraries, API schemas, persistent storage, and foundational data models. These evolve slowly as their impact exponentially grows.

AI promises infinite velocity, to push code as fast as it consumes electricity. Not every part of a system can survive infinite velocity. In an area with low Volatility Tolerance, the constraint isn't how fast you can write code, but how safely you can integrate it over time.

3. Cognitive Tolerance

This is the limit of complexity, and the rate of change, a human can verify and internalize in a reasonable time frame.

• High Tolerance: Boilerplate, standard patterns, and simple unit tests. The code is obvious. If AI writes it, it can be scanned in seconds and stamped with "LGTM."

• Medium Tolerance: Standard data mapping (DTO to Domain), form validation, or ViewModel state management. It requires actual reading and context, but the logic is generally linear and self-contained.

• Low Tolerance: Distributed system logic, concurrency handling, and security protocols.

This isn't just about the verification tax: the time it takes to reason about a complex block of code. It is about the erosion of confidence.

Engineers rely on deep mental models to predict how a system will behave. These mental models are built on assumptions and historical understanding. If we are encouraged and AI allows us to change too much code too quickly, our mental models can’t keep up. Even if the new code is "better", if it invalidates our core assumptions faster than we can relearn them, we lose our ability to reason about the system.

In Low Tolerance zones, we need the code to match our mental model. If we lose that alignment, we are effectively shipping instant legacy code, systems that become brittle immediately because we are too afraid to change what we don't fully understand.

The Core Thesis

AI can be a powerful accelerator, but it is introducing a new way of building software where we need to be very aware of these tolerances .

To use it effectively, we have to map our code base against these three axes.

You cannot readily apply high-variance tools to Low Tolerance zones (the Pistons) without risk of seizing the engine. Conversely, you shouldn't leverage your engineers' time hand-crafting the High Tolerance cup holders.

As the industry pushes for more and more AI adoption, these terms allow us to move the conversation from "Can we use AI?" to "What is the cost?" to “How do areas of our code base thrive with AI?”

We can use this framework to explain that while AI might accelerate code generation in some critical paths, it introduces risks to Logical Tolerance that require a disproportionate investment in verification. It gives us the nuance to say, "If we accelerate here, we are trading off Cognitive Tolerance, which means our future maintenance costs will go up."

The goal of this series is to establish Logical Tolerance, Volatility Tolerance, and Cognitive Tolerance as a shared vocabulary for these trade-offs such that they can be used in key engineering decisions.

This was Part One of The Tolerance Trilogy, thanks for reading! Up next, we’ll dive into why AI written code specifically struggles within large software systems and how we can go about using it successfully.

If you don’t know it, git bisect is basically a binary search for bugs. You have an issue that did not exist before, so you grab two commit hashes, one good and one bad, and build, repro, build, repro until you find the exact commit that introduced the bug.

git bisect Hates Mobile

Constant building and shifting of your dependency graph is a HUGE pain for mobile devs. Our builds can take multiple minutes, especially if we have to go to a previous release and we don’t have recent build caches. Git bisect requires a lot of builds. This can take a TON of time.

I was investigating an issue between two releases (release_8 and release_9) which had 1300 commits between them. This is about 11 bisect steps or:

• 22 minutes of build time with 2 minute builds

• 55 minutes with 5 minute builds

The reality is going to be some mix of these build times depending on which way the bisect goes. Regardless, this is a large amount of time to simply wait.

AI to the Rescue?

For this issue, we couldn’t reproduce it locally and didn’t have clear steps. Doing 10+ builds would’ve been a waste of time.

So instead, I grabbed a big diff.
We knew the bug appeared in the recent release but not the previous one:

git diff release_8 release_9

This command produced 413,032 lines changed.

Instead of bisecting I asked an AI Agent to look at this diff with relevant information from our issue. This only took a few minutes!

The AI analyzed the diff, grouped related changes, and surfaced a few areas that might be tied to the behavior we were seeing:

• Code paths that touched relevant data

• New conditions around feature flags

• etc.

No builds. No waiting. Just instant context.

Why This Works So Well

Bisecting exists because it’s impossible to reason about that much change at once. It helps us narrow the scope so we can test smaller chunks and confirm behavior step by step. That’s how we make the problem manageable.

This is exactly what large language models are good at. They can take in the full context of a change and reason about the entire picture at once.

Instead of checking each commit, I tell the agent to get the diff between good and bad commits and ask, “Given these changes and this bug, what looks connected?” and it points me towards areas of interest.

I’m still debugging, just with more context than I can hold in my head, and without having to wait for the compiler.

Try It Yourself

Next time you hit a tricky regression, grab an AI agent and look at a diff between the good and bad commits. Let it scan the changes and tell you what stands out.

git bisect still matters. When you can reproduce the issue cleanly and builds are quick, it’s the right tool. When the bug is vague or builds take forever, this approach can save a lot of time.

Reverse Lookup a Screen

You’re debugging a UI, see some text, and have no idea where it’s coming from. You start in strings.xml, follow the ID through the ViewModel, check the Composable, maybe even grep the whole project. It’s the least interesting scavenger hunt in Android development, but an extremely common pattern to reverse lookup the UI that’s being rendered.

Now I just drop a screenshot into an AI Agent and ask where that text lives. It’ll usually tell me the string resource name, where it’s referenced, and which file renders it. It’s the kind of task that’s perfect to hand off. Something that used to take a few minutes and some effort is now no concern.

Example Prompt

First Pass Review

I still rely on teammates for real code review, but AI’s great for a quick first pass. Before I open a PR, I’ll paste the diff or ask an agent to look at my commit history. Then I ask for feedback on readability, potential issues, and edge cases.

Time Saved!

I work in a large project and we generally can’t sync all of our modules at once. Doing this first pass of review has saved me time where I missed updating an override when adding a new function to an interface whether its in a fake in tests or an implementation in another module. Typically CI/CD would catch this for me, but that takes much longer to run.

Example Prompt

Unused Resource Cleanup

All projects collect junk over time. You’ll find string resources that aren’t referenced, drawables from redesigns, or xml layouts replaced by Compose. They all sit there bloating the project and slowing builds.

AI Agents are pretty good at walking the reference graph across modules and telling you what’s safe to delete.

This is especially helpful for large projects where not all modules are synced or the Unused Resource tool simply falls over.

Example Prompt

Supercharging Find in Files

We all love the Find in Files feature (Cmd+Shift+F), but plain text search can often show way too much noise. There’s a little "regex" checkbox that unlocks a lot of potential! Although writing regex is usually not fun. This is a task I’m happy to hand off.

Describe the code to find in plain English and let the AI generate the complex pattern for the search box.

Example 1: Hunting Hardcoded Strings

You're trying to stamp out hardcoded strings in your Jetpack Compose code. A simple search for Text(" is a noisy mess that misses half the cases and incorrectly flags others. Now, I just ask for a smart regex that finds Text("Hello") and Text(text = "World") but correctly ignores Text(stringResource(R.string.hello)).

Example Prompt

Example 2: Auditing Theme Colors

You're migrating to Material 3 and need to find every layout that’s still using a hardcoded color (like #A4C639) instead of a theme attribute (?attr/colorPrimary). Instead of manually scanning hundreds of XML files, I can get a single regex to find every violation.

Example Prompt

If you’ve found other ways AI boosts your mobile workflow, I’d love to hear about them!

Thanks for reading 💚

typealias Handler = (result: Result) -> Unit

It looks innocent. Give a function type a name and tidy up the signatures, great!

Then a bug hits. The Handler is gone in the debugger and in stack traces only (Result) -> Unit remains. Our alias has disappeared at the scene of the crime.

That is the trick, a typealias does not create a new type. It is only a name for the function type.

Enter the functional interface

fun interface Handler {
  fun handle(result: Result)
}

Now the Handler exists. It has identity, it can carry documentation, and the method name handle shows up in stack traces and search results. Usage is still light:

val handler: Handler = Handler { result ->
  println(result)
}

Evidence

Overloading

Aliases collapse to the same function type, which prevents overloading:

typealias Handler = (Result) -> Unit
typealias Completion = (Result) -> Unit

fun process(h: Handler) { }
fun process(c: Completion) { } // Won't compile, same JVM signature.

Functional interfaces are distinct types, so overloads compile:

fun interface Handler { 
  fun handle(result: Result)
}
fun interface Completion {
  fun complete(result: Result)
}

fun process(h: Handler) { }
fun process(c: Completion) { }

Multiple handlers with the same alias

Using a single alias for several callbacks in the same type invites mistakes. The compiler cannot help if you swap them. It also won’t tell you which was called while debugging or looking at a stacktrace.

// One alias for two different callbacks
typealias Handler = (Result) -> Unit

data class Screen(
  val onClick: Handler,
  val onDismiss: Handler
)

val click: Handler = { println("clicked: $it") }
val dismiss: Handler = { println("dismissed: $it") }

// Compiles, but the handlers are reversed
val screen = Screen(onClick = dismiss, onDismiss = click)

With functional interfaces you can give each callback a distinct type, so it is impossible to construct the Screen incorrectly and stacktraces name the method you expect.

fun interface ClickHandler { fun onClick(result: Result) }
fun interface DismissHandler { fun onDismiss(result: Result) }

data class Screen(
  val onClick: ClickHandler,
  val onDismiss: DismissHandler
)

// Will not compile if you swap types
// val screen = Screen(onClick = DismissHandler { ... }, onDismiss = ClickHandler { ... })

val screen = Screen(
  onClick = ClickHandler { println("clicked: $it") },
  onDismiss = DismissHandler { println("dismissed: $it") }
)

Kdoc and Discoverability

You can put kdoc on a functional interface and it surfaces in the IDE. You can also add small helpers as extensions:

/** Called once per operation with the final result. */
fun interface Handler {
  fun handle(result: Result)
}

fun Handler.logged(): Handler = Handler { result ->
  Log.d("Handler", "Handled: $result")
  this.handle(result)
}

Stacktrace Comparison

With a typealias, the alias name is not present. You will usually see $lambda$ or Function1:

java.lang.IllegalStateException: boom in typealias
    at FileKt.main$lambda$0(File.kt:27) // What was called here??
    at FileKt.main(File.kt:30)
    at FileKt.main(File.kt)

With a functional interface, the interface and its method are visible, which makes searching and triage simpler:

java.lang.IllegalStateException: boom in fun interface
    at LoggingHandler.handle(File.kt:18) // Clear name of the caller and override!
    at FileKt.main(File.kt:38)
    at FileKt.main(File.kt)

This will also happen in the call stack in the debugger leaving you stranded as you attempt to navigate through your breakpoints.

Testing with fakes

A named type makes simple fakes straightforward:

val calls = mutableListOf<Result>()
val handler: Handler = Handler { result -> calls += result }

// exercise code that calls handler.handle(...)

check(calls.isNotEmpty())

Verdict

typealias makes code look cleaner but they do not provide type identity. If you want names that survive code navigation, debugging, and evolution, prefer a functional interface.

Try it yourself!

When to use a typealias?

When dealing other cases that aren’t lambdas, especially with complicated or nested generic types. They are great for turning complex types into readable, reference-able, and remember-able types!

But the analogy doesn’t sit right with me. The phrase carries weight and it falls unfairly on real junior engineers.

A quick note on the term “junior”

I want to acknowledge upfront that “junior” is not a perfect term. It’s vague, sometimes patronizing, and can be tied more to time served than to actual capability. In this context, I’m using it intentionally because it’s the phrase that gets used in these AI comparisons and trainings.

Junior engineers are people, not metaphors

A junior engineer is a human being. They’re capable of learning from experience, synthesizing context across domains, showing initiative, and growing rapidly. They have motivations, feelings, and ambitions. They can build deep understanding, ask critical questions when something doesn’t make sense, apply judgment, and come up with novel solutions in ways that no language model can.

LLMs don’t grow easily¹. They don’t mature into someone you trust with architectural decisions or tough tradeoffs. They don’t start to anticipate edge cases, advocate for users, or question a spec because something feels off. They don’t take responsibility. They don’t improve with mentorship. They just respond based on patterns.

So when we call an AI a “junior engineer that needs hand holding,” we’re not just making a lazy analogy. We’re erasing the path that real people take to develop into leaders. We risk under investing in the very people who have that potential, because we’ve convinced ourselves a tool can stand in for them.

We need the junior engineers to grow, gain experience, build confidence, and the ability to make difficult decisions. And to make the comparison even more unfair…

LLMs don’t have the same capacity as junior engineers

LLMs don’t learn the way people do. They don’t develop understanding. They don’t carry memory across tasks². They can’t reflect or introspect or ask for clarification. They can produce code, sure, even elegant and useful code, but they do so without comprehension. Having to constantly “reteach” the same concepts is exhausting. A junior engineer might need reminders, but then they grow. They internalize. They become the teacher.

LLMs don’t know what the code is for. They don’t understand how it fits into a product, or how that product fits into someone’s life. They have no sense of the impact it might have on the people who use it.

Describing LLMs as junior engineers misleads people about what these tools are and are not capable of. It sets the wrong expectations and erases the fundamental differences between real cognitive development
and probabilistic pattern matching.

Why I care

Words shape how we work. If we start thinking of AIs as “almost-human,” we will misuse them and undervalue the actual humans we hire to be on our teams.

LLMs are useful. But they’re tools, not teammates.

Footnotes

1. Sure new models are coming more and more frequently, but they take massive amounts of energy and new material.

2. Unless you explicitly engineer that behavior, and even then the context window is way too small to fully synthesize understanding across tasks.

Video

Source

Slides

Mentioned Links

• Bluesky AndroidDev Starter Pack

• MCP Kotlin SDK

• Goose

• Block's Playbook for Designing MCP Servers

• Hugo Visser’s Drum MCP

• Android MCP SDK

Discussion started up at work this week about the different merge strategies available in GitHub. I looked around online to see if I could find a good article to send to share a quick snapshot of the differences represented visually and didn’t find any I liked, so here’s my take!

Merging your Pull Request

You wrote all your code and are ready to merge! Let’s go! At the bottom of your Pull Request (PR) you’ll find a button with a drop down arrow that shows three options with descriptions, but what do they actually do? Sometimes it’s helpful to actually see how these things play out.

Before the Merge

(aka you wrote code on feature-branch and are ready to merge back to main)

• main branch: D → E

• feature-branch branched from D and adds commits A → B → C

1. Merge Commit

• Preserves full commit history

• Shows when branches were merged

• Creates an extra merge commit (M)

After merge:

• The feature branch is merged with all its history intact.

• A new merge commit (M) is created.

  • These usually read like Merge pull request #---- from feature-branch in your git history.

2. Squash Merge

• Clean history with a single commit

• Loses individual commits from the feature branch

After squash merge:

• The entire A → B → C branch is squashed into a single commit S, removing individual commits.

3. Rebase Merge

• Retains individual commits

• Creates a linear history

• Rewrites commit history (be careful in shared branches)

After rebase:

• The commits are replayed on top of main, making history linear.

• New commit hashes (A', B', C') are created because their parent commits changed.

Final Comparison

Which one do you prefer? Let me know and thanks for reading!

Imagine buying a fleet of delivery trucks for a new small bakery, committing a large pool of resources to solving a problem that doesn’t exist yet. This is optimizing for a level of business that the bakery doesn’t have potentially wasting those resources.

In software engineering, this might mean delaying a release to implement a feature that might be needed in the future. This is optimizing for user needs that may never materialize. In personal productivity, it could mean procrastinating because we're too busy perfecting our project management system. Have you ever said you wanted to write more and instead rewrote your website?

The key is to focus on the problems you do have and create solutions for the outcomes you want. By focusing on the "whats" instead of the "what ifs," you'll deliver real value, make meaningful progress, and ultimately be more productive. The hypothetical bugs or slow code may indeed end up being real, but in the meantime your users have something that helps them and they can provide feedback to help you prioritize whats next.

Maybe your feature could be faster, but maybe it’s also fast enough.

Instead of easy, try conveying that sentiment with more detail. Saying that something is straightforward or small in scope, even if it requires effort, will be clearer and help engineers feel empowered. As an example the phrase "Implementing this feature will be small in scope” is clearer than “Implementing this feature is easy” giving some context that we might not have dependencies on other teams. Replacing "This bug is easy to fix" with "This bug has a straightforward fix." implies that the task has a clear start and end.

When it comes to describing something challenging, be specific and descriptive! Rather than saying a task is "hard," explain why. Is it challenging because it requires critical thinking? Is it complex because it involves many different factors? Or perhaps it's demanding and requires a lot of effort or mental load.

This opens up a lot of new possibilities! We wouldn't say something is easy and hard, but we can say something is straightforward and demanding!

By choosing our words thoughtfully and providing more descriptive context, we empower people to take ownership and provide room for growth. Engineers will still need help, but being more descriptive and switching out a few words makes them feel in control and not incompetent. By avoiding these negative feelings, they are more likely to ask for help when they do run into trouble which leads to an inclusive and faster team.

It was a dark and stormy night. My hands were flying across the keys when suddenly the codebase began to exhibit strange behavior. Hashes, which once returned the same values for identical objects, suddenly became unpredictable. Collections shuffled unexpectedly, deduplication failed, and instances thought to be identical went unrecognized. Today we dive into this mystery, revealing the culprit.

Act 1: The Setup

We introduce the protagonist of our story, DetectiveDataClass.

data class DetectiveDataClass(
    val name: String,
    val age: Int,
    val alias: String,
    val onDetectiveAlert: () -> Unit
)

Here, DetectiveDataClass includes a lambda, onDetectiveAlert, meant to serve as a callback when an alert is triggered. All seems calm until…

Act 2: A Case of Mistaken Identity

The team quickly notices something off. When two detectives are instantiated with identical properties, they’re expected to be the same, right? Not quite, it seems.

val detective1 = DetectiveDataClass(
    name = "Sherlock",
    age = 40,
    alias = "Holmes",
    onDetectiveAlert = { println("Elementary!") }
)

val detective2 = DetectiveDataClass(
    name = "Sherlock",
    age = 40,
    alias = "Holmes",
    onDetectiveAlert = { println("Elementary!") }
)

println(detective1 == detective2)
// Expected true, but is actually false

println(detective1.hashCode() == detective2.hashCode())
// Expected true, but is actually false

Surprise! Although the detectives have identical names, ages, aliases, and even identical alert messages, Kotlin reports them as different. The code’s consistency is broken, and it’s clear that hashCode and equals are not behaving as expected.

Act 3: Tracking the Evidence

Why does this happen? It turns out that each lambda (even if it looks identical) is unique. When a lambda is created, it holds a distinct memory reference, meaning onDetectiveAlert in detective1 and detective2 are fundamentally different objects in memory. The identity of the lambda breaks the hashing logic, and here’s proof:

// Unique ID for the first lambda
println(System.identityHashCode(detective1.onDetectiveAlert))

// Unique ID for the second lambda
println(System.identityHashCode(detective2.onDetectiveAlert))

A System.identityHashCode returns an object’s location in memory. Meaning that it is not a content based hashcode like data class hashcode functions. So even if two objects contain the same information, because they are not the literal same object in memory, they will have a different identity hashcode.

So each lambda instance has a unique identity hashcode, highlighting the critical difference that affects equality and hashcode results. To collections and hash-based logic, these objects are not the same!

Act 4: The Clues Come Together

To solve the mystery, let’s redefine our suspects with a new plan. We’ll exclude the onDetectiveAlert lambda from our equality and hashcode calculations by overriding them:

data class DetectiveDataClass(
    val name: String,
    val age: Int,
    val alias: String,
    val onDetectiveAlert: () -> Unit
) {
    override fun equals(other: Any?): Boolean {
        if (this === other) return true
        if (other !is DetectiveDataClass) return false

        return name == other.name &&
               age == other.age &&
               alias == other.alias
    }

    override fun hashCode(): Int {
        return name.hashCode() * 31 + 
            age * 31 + 
            alias.hashCode()
    }
}

Now, let’s run the check again:

val detective1 = DetectiveDataClass("Sherlock", 40, "Holmes") {
  println("Elementary!")
}
val detective2 = DetectiveDataClass("Sherlock", 40, "Holmes") {
  println("Elementary!")
}

println(detective1 == detective2) // Now true
println(detective1.hashCode() == detective2.hashCode()) // Now true

With this solution, the detective instances match as expected.

Act 5: The Mystery is Solved

By excluding the lambda from equals and hashCode, we’ve eliminated the source of instability. This allows objects to be considered identical based on core attributes rather than transient callbacks.

This increases maintenance cost and breaks the hashcode function we get from data classes for free. Any new fields added to DetectiveDataClass will also need to be added to our overridden equals and hashCode functions.

Instead you can consider:

• Using a method reference so that the same lambda is called.

  •   fun alertFunction() {
          println("Elementary!")
      }
    
      val detective1 = DetectiveDataClass(
          name = "Sherlock",
          age = 40,
          alias = "Holmes",
          onDetectiveAlert = ::alertFunction
      )
    
      val detective2 = DetectiveDataClass(
          name = "Sherlock",
          age = 40,
          alias = "Holmes",
          onDetectiveAlert = ::alertFunction
      )
    

• Using interfaces for lambdas or callbacks if stable references are needed.

  •   interface DetectiveAlert {
          fun onAlert()
      }
    
      data class DetectiveDataClass(
          val name: String,
          val age: Int,
          val alias: String,
          val onDetectiveAlert: DetectiveAlert
      )
    
      object ElementaryAlert : DetectiveAlert {
          override fun onAlert() {
              println("Elementary!")
          }
      }
    

• Store lambdas separately from data classes when object equality matters.

• Override equals and hashCode carefully to exclude fields that could vary unexpectedly, or you know don’t matter to your equality.

Epilogue

With the mystery unraveled, our detectives can rest assured, knowing their identities are now stable and consistent. The tale of the unstable hash is a warning to all: in the world of Kotlin, lambdas may be useful but can be fickle co-conspirators when data class hashing is involved.