The Age of AI Overload

We live in the golden age of AI. Tools everywhere. Suggestions flying at you from every corner. “Build this.” “Try that.” “Here’s a starter template.” “Want me to scaffold the whole thing?”

And you say yes. To everything.

But here’s the question nobody’s asking: Are you burning your brain more than you’re burning AI tokens?

Because tokens are cheap. $0.01 per thousand, give or take. But your focus? Your mental clarity? Your ability to finish one damn thing before starting the next? That’s priceless. And you’re lighting it on fire every single day.

This post is a mirror. Not a lecture. Read it, and honestly ask yourself. Is this me?

What Science Says: Your Brain on AI

This isn’t just philosophy. Neuroscience is starting to show the damage.

In 2025, researchers at MIT Media Lab ran a four-month study called “Your Brain on ChatGPT” [1]. They put EEG sensors on 54 participants and asked them to write essays using three methods: ChatGPT, a search engine, or just their own brain. The results were alarming.

ChatGPT users showed the weakest neural connectivity across all groups. Their brains were literally doing less work. Worse, over time they got lazier. By the end of the study, most ChatGPT users had devolved into copy-pasting [2], barely engaging their own thinking at all. The researchers called it “cognitive debt”, a term that should terrify any engineer.

Harvard faculty weighed in too. In a Harvard Gazette feature [3], experts across neuroscience, philosophy, and education warned that excessive AI reliance contributes to “cognitive atrophy”, the shrinking of critical thinking abilities. When you stop exercising a muscle, it weakens. Your brain works the same way.

A study published in the International Journal of Educational Technology [4] found that heavy AI users among university students showed increased procrastination, memory loss, and poorer academic performance. Not better. Worse.

And it’s not just students. Harvard Business Review published “When Using AI Leads to Brain Fry” [5] in 2026, documenting how even senior engineers and product builders experience cognitive overload and stress when AI moves faster than their ability to comprehend it.

The pattern is clear: AI doesn’t make you dumber by being bad. It makes you dumber by being too good. When every answer is one prompt away, your brain stops doing the work that keeps it sharp.

So the next time you paste AI output without reading it, remember: you’re not saving time. You’re taking out a loan against your own cognitive future. And the interest compounds.

1. The AI Suggestion Trap

You open ChatGPT or Claude with a clear question. You get an answer. But then it says: “You might also want to consider…”

And just like that, you’re down a rabbit hole you never planned for. AI didn’t just answer your question. It gave you five new ones. And you followed every single one.

The problem isn’t that AI gives suggestions. The problem is that you treat every suggestion as a command. You forgot that AI is a tool, not your project manager. It doesn’t know your priorities. It doesn’t know your deadline. It doesn’t know that you were supposed to ship something today. Not explore three new frameworks.

The real skill in the AI era isn’t prompting. It’s filtering.

2. The 100 Unfinished Projects Syndrome

How many repos do you have that looked exciting on Day 1 and haven’t been touched since Day 3?

AI makes starting things embarrassingly easy. “Build me a full-stack app with auth and a dashboard.” Boom, scaffolded in 90 seconds. So you start Project A. Then AI mentions a cool side project idea. Project B. Then you see a tweet about some new agent framework. Project C.

Three days later, you have three repos, zero shipped products, and a growing sense that you’re “working hard” but getting nowhere.

Starting is not shipping. Motion is not progress. And AI is the most efficient unfinished-project generator ever built.

3. The Lost Thread

This one hurts the most.

You sit down at 9am with a clear goal: “Today I’m going to finish the authentication module.” You ask AI for help. It helps. But it also mentions that your error handling could be better. So you refactor error handling. Then it suggests a logging pattern. So you set up structured logging. Then it recommends a monitoring tool. So you research three monitoring tools.

It’s 4pm. The authentication module? Untouched.

AI didn’t lose your context. You did. The machine remembers exactly what you asked. You’re the one who chased every shiny object it reflected back at you.

4. The Illusion of Productivity

This is the most dangerous one. Because it feels real.

You’re prompting. Reading outputs. Copying code. Switching between tabs. Setting up new projects. Configuring tools. Installing packages. Writing READMEs for apps that don’t work yet.

From the outside, it looks like peak productivity. From the inside, it feels like you’re doing important work.

But ask yourself: What did you actually ship this week? What’s in the hands of a user? What problem did you solve that someone can benefit from today?

If the answer is “nothing”, you weren’t productive. You were performing productivity. There’s a massive difference.

5. The Copy-Paste Engineer

AI gives you 50 lines of code. You paste it. It works. You move on.

But do you understand what it did? Could you modify it if the requirements changed? Could you debug it at 2am when it breaks in production?

There’s a growing generation of engineers who can build anything with AI, and explain nothing without it. They’re assembling, not engineering. And the moment the AI gives a wrong answer (which it does, regularly), they’re stuck.

If you can’t explain what your code does without asking AI to explain it, you didn’t write it. You transcribed it.

6. Tool Hopping Addiction

Monday: “I’m going all-in on LangChain.”

Wednesday: “Actually, LlamaIndex seems better.”

Friday: “Wait, CrewAI just dropped a new version…”

Sunday: “Let me try building my own framework from scratch.”

The AI ecosystem moves fast. A new tool drops every week. A new model every month. And you feel like you need to try all of them. Because what if you’re missing out?

Here’s the truth: The engineers who ship products pick one stack and go deep. The engineers who chase every new release are perpetual beginners in twenty frameworks and experts in none.

Tools don’t build products. Focus does.

7. The Comparison Spiral

You scroll Twitter. Someone shipped an AI app in a weekend. Someone else built an agent that “replaces a whole team.” A 19-year-old made $50K with a ChatGPT wrapper.

And now you feel behind. So you start three projects at once to catch up. None of them ship. You feel more behind. So you start two more.

This is the comparison spiral, and AI supercharges it. Because AI makes everyone’s demos look incredible. What you don’t see is that most of those projects died a week later. Most of those wrappers made $50K and then $0. Most of those “agents” break on any input the demo didn’t cover.

Stop comparing your unfinished work to other people’s polished demos. You’re comparing your behind-the-scenes to their highlight reel.

8. Overthinking the Prompt, Underthinking the Problem

You spend 45 minutes crafting the perfect prompt. Adjusting the system message. Tweaking the temperature. Adding few-shot examples. Running it through three different models to compare outputs.

But did you spend even 10 minutes clearly defining the actual problem you’re trying to solve?

The best AI users don’t write better prompts. They have clearer thinking before they ever open the chat window. The prompt is the last step, not the first. If you don’t know what you want, no amount of prompt engineering will save you.

AI amplifies your clarity. If your thinking is fuzzy, AI gives you faster, more confident garbage.

So What Do You Actually Do?

This isn’t an anti-AI post. AI is the most powerful tool we’ve ever had. But a chainsaw in the hands of someone without a plan doesn’t build a house. It just makes a lot of noise and sawdust.

Here’s the real framework:

• Before you prompt, decide. Know what you’re building today. Write it down. Stick to it.
• Treat AI suggestions like a buffet, not a prescription. Take what serves your goal. Leave the rest.
• Finish before you start. One project at 100% beats ten projects at 10%.
• Understand before you paste. If AI wrote it, you should be able to explain it.
• Pick your tools and commit. Depth beats breadth. Every single time.
• Log off the timeline. Other people’s launches are not your failure.
• Think first, prompt second. Clarity in = clarity out. Garbage in = faster garbage out.

AI tokens are renewable. Your brain cells aren’t. Spend them wisely.

References

[1] Kosmyna, N. et al. “Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task.” MIT Media Lab, 2025. https://www.media.mit.edu/publications/your-brain-on-chatgpt/

[2] Chow, A. “ChatGPT May Be Eroding Critical Thinking Skills, According to a New MIT Study.” TIME, 2025. https://time.com/7295195/ai-chatgpt-google-learning-school/

[3] Mineo, L. “Is AI dulling our minds?” Harvard Gazette, 2025. https://news.harvard.edu/gazette/story/2025/11/is-ai-dulling-our-minds/

[4] Temler, M. “Is AI hurting your ability to think? How to reclaim your brain.” The Conversation, 2026. https://theconversation.com/is-ai-hurting-your-ability-to-think-how-to-reclaim-your-brain-272834

[5] Bedard, J., Kropp, M. & Hsu, M. “When Using AI Leads to Brain Fry.” Harvard Business Review, 2026. https://hbr.org/2026/03/when-using-ai-leads-to-brain-fry

This is Day 16 of my 31-day series: Mobile × AI: The Honest Truth. No hype. Just reality.

Back in 2020, I inherited a 3-year-old codebase at my last job. Around 47K lines total. One file had 10,000+ lines. All the views were in that one file.

No documentation. No architecture. No DI. No proper networking layer. Just… code that somehow worked.

CTO’s words? “Please, figure it out and try to refactor it.”

That project took me weeks to understand. Months to feel comfortable touching anything.

Now in 2026? If I got that same codebase today, I’d map it out in a couple hours. Not perfectly — but enough to stop feeling completely lost.

Here’s what changed.

💡 The “Explain This” Superpower

This is probably the most useful AI capability for working developers. Not code generation. Not autocomplete.

Just explanation.

You paste confusing code. You ask “what does this do?” And you actually get an answer that makes sense.

Simple as that.

When you’re staring at someone else’s code — legacy stuff, open source libraries, that one file your teammate wrote at 2am — AI becomes a patient tutor. Ask dumb questions. Get useful answers. No judgment.

What I ask:

• “What does this function do?”
• “Why is this structured this way?”
• “What could break here?”

What I get: Context that would’ve taken me hours of debugging to figure out.

One thing though — my first attempts were useless. I’d paste a whole class and ask “explain this.” The answers were so generic they could describe any Android app. You gotta ask specific questions about specific parts. That’s when it actually helps.

📊 Back to That 47K Line Codebase

Let me show you what I mean. Here’s how I’d approach that nightmare codebase today:

Hour 1: Bird’s Eye View

First, I’d look at the main entry point. The Application class or MainActivity — wherever everything starts.

// Paste the class, ask:
// "What is this class doing? What's it setting up on app launch?"

In that old project, I would’ve discovered:

• API calls happening directly in Activities (no repository, no use case, nothing)
• SharedPreferences scattered everywhere
• That weird singleton that everything depended on

Back in 2020, finding all that took me days of grep and println debugging.

Hour 2: The Monster File

Remember that 10K line file? All views in one place.

// Paste a section, ask:
// "What pattern is this trying to follow? How are these views connected?"

Turns out it wasn’t trying to follow any pattern. Just years of features piled on top of each other. But at least AI can tell you what it’s doing, even if the why doesn’t make sense.

The honest answer is sometimes “this is spaghetti, but here’s how the spaghetti flows.”

Hour 3–4: Finding the Landmines

This is where AI really helps. Take any scary-looking function and ask:

// "What could go wrong in this function? What bugs might be hiding?"

In legacy code, there’s always stuff like:

• Callbacks that might fire twice
• Null checks that are missing
• Network calls on main thread
• Memory leaks from context references

AI spots these faster than I can read through the code manually. It’s not perfect — it misses things. But it catches enough that I feel less scared to touch stuff.

💻 Simple Example

Here’s a typical legacy function you’d find:

fun loadData() {
    if (isLoading) return
    isLoading = true
    api.getData(object : Callback {
        override fun onSuccess(data: List<Item>) {
            items = data
            adapter.notifyDataSetChanged()
            isLoading = false
        }
        override fun onError(e: Exception) {
            showError(e.message)
            // isLoading never reset here
        }
    })
}

Ask: “What could go wrong here?”

AI catches it immediately — isLoading never resets on error. So after one failed request, the function stops working forever. I've shipped bugs like this. More than once.

🎯 Where This Works (And Where It Doesn’t)

Works great:

• Legacy code nobody documented
• Open source libraries you’re debugging
• Understanding algorithms before modifying them
• Regex (seriously, nobody remembers regex)

Be careful:

• Business logic — AI doesn’t know your company rules
• “Why did they do this?” — AI guesses, but doesn’t know the real history

Don’t trust:

• Security audits — use actual tools
• Code that calls external APIs — AI doesn’t know what the server actually returns

🧠 My Workflow

1. Start big — “What does this class do?”
2. Go small — “Explain this function”
3. Ask for trouble — “What could break?”
4. Check yourself — try to explain it back
5. Write it down — future you will forget

🧪 Try This

Find the messiest function in your current project. Paste it. Ask “what does this do and what could go wrong?”

Compare the answer to what you thought it did.

You’ll either feel validated or learn something new.

💬 What’s the worst codebase you’ve inherited? How long until you stopped feeling lost?

🔮 Tomorrow

Day 17: Refactoring Without Fear — How AI became my safety net for big changes. Including a breaking change I almost shipped.

🎯 Takeaway

Understanding code is half the job. We spend more time reading than writing.

AI just made the reading part way faster.

Not perfect. Not magic. But useful enough that I wish I had it back in 2020 staring at that 10K line file.

Go decode something old. 🚀

🔗 Real Resources

1. Claude for Developers — Anthropic’s AI, what I use for this

anthropic.com/claude

1. Firebender — AI that understands Android project context

firebender.com

1. Working Effectively with Legacy Code — Michael Feathers’ classic

oreilly.com

1. Refactoring Guru — Patterns for improving messy code

refactoring.guru

This is Day 15 of my 31-day series: Mobile × AI: The Honest Truth. No hype. Just reality.

I mass-produced my fifth LazyColumn few months ago. And I snapped.

I was halfway through the BookMate (fake name) checkout refactor — you know, the kind where you’re copy-pasting from your own code from three months ago because you can’t remember how you did the click handler last time. That’s when I finally let the AI write it for me.

45 minutes of boilerplate? Done in about 90 seconds. Give or take.

Week 3 is about the wins. The places where AI actually, measurably helps. Let’s start with the most satisfying one: killing boilerplate. Forever. (Or at least until the next framework rewrite.)

💡 The Boilerplate Problem

If you’ve built Android apps for more than a week, you know the drill:

• List UIs — LazyColumn, item composables, state hoisting, remembering which parameter goes where…
• API response models — data classes for every endpoint, nullable fields everywhere, Moshi annotations
• Test stubs — setup, mocks, that one assertion you always forget the syntax for
• Repository patterns — interface, implementation, the error handling you’ll “clean up later”
• Database entities — Room annotations, type converters, migrations that break at 2am

None of this is hard. But it’s tedious. It’s the kind of work where you zone out, make a typo, spend 20 minutes debugging said typo, and question your career choices.

Before AI, I’d dig through old projects, copy-paste, modify, debug the inevitable mistakes.

Now? I describe what I need. AI generates it. I review, tweak, ship.

📊 The Numbers (From My Actual Time Tracking)

I tracked boilerplate tasks for about a month. Here’s what I found — and yeah, these are rough estimates, not lab-controlled experiments:

Compose List UI (LazyColumn + state + click handling):

• Before: 40–50 minutes (depending on how distracted I got)
• With AI: Maybe 2 minutes, plus 3–4 minutes reviewing
• Savings: Somewhere around 85%? Hard to say exactly.

API Response Models (batch of 5 endpoints):

• Before: ~30 minutes
• With AI: Couple minutes to generate, couple more to verify
• Savings: 80–90%, depending on complexity

Unit Test Stubs (10 basic tests):

• Before: 20–25 minutes of copy-paste-modify
• With AI: ~3 minutes + longer review (tests need more eyeballing)
• Savings: Maybe 65–70%

Room Entity + DAO:

• Before: ~20 minutes
• With AI: Under 5 minutes total
• Savings: Around 75%

Rough total? I’m saving 4–6 hours a week on stuff that wasn’t making me a better developer anyway.

💻 Example: The LazyColumn That Took 90 Seconds

Last Tuesday, I needed a booking list for a client project. Here’s what I told Firebender:

Create a Compose LazyColumn for a list of BookingItem objects.
Fields: id, title, subtitle, timestamp, status (enum: PENDING, CONFIRMED, CANCELLED).
Include click handler. Use Material3 styling.

What I got back (after about 90 seconds):

@Composable
fun BookingList(
    bookings: List<BookingItem>,
    onItemClick: (BookingItem) -> Unit,
    modifier: Modifier = Modifier
) {
    LazyColumn(modifier = modifier) {
        items(bookings, key = { [it.id](<http://it.id>) }) { booking ->
            BookingCard(
                booking = booking,
                onClick = { onItemClick(booking) }
            )
        }
    }
}

@Composable
fun BookingCard(
    booking: BookingItem,
    onClick: () -> Unit,
    modifier: Modifier = Modifier
) {
    Card(
        onClick = onClick,
        modifier = modifier.fillMaxWidth().padding(8.dp)
    ) {
        Column(modifier = Modifier.padding(16.dp)) {
            Text(booking.title, style = MaterialTheme.typography.titleMedium)
            Text(booking.subtitle, style = MaterialTheme.typography.bodyMedium)
            Row(
                modifier = Modifier.fillMaxWidth(),
                horizontalArrangement = Arrangement.SpaceBetween
            ) {
                Text(booking.timestamp.formatAsDate())
                StatusChip(status = booking.status)
            }
        }
    }
}

Was it perfect? Nope. I tweaked the padding, added a ripple effect, changed the status chip colors. But 80% of the boring work was done.

(First attempt on a different project? The AI (using OpenAI 5.2)gave me RecyclerView code. In 2025. I had to laugh.)

🎯 Where This Actually Works

Here’s my honest breakdown after a few months of doing this:

Works great:

• List UIs and item composables
• Data classes and API models
• Database entities and DAOs
• Test setup and basic assertions
• Retrofit/Ktor interface definitions
• CRUD repository implementations

Works, but check carefully:

• Anything with custom business logic baked in
• Complex state management
• Edge cases in data parsing
• Tests that need domain knowledge (AI doesn’t know your app)

Don’t even try:

• Payment flows. Just don’t.
• Authentication logic
• Anything touching user data privacy
• Security-sensitive code

I learned that last one the hard way on a fintech client project. Let’s just say code review caught it before I did.

🧪 Mini Challenge

If you haven’t tried this yet, here’s a 10-minute experiment:

1. Think of a boilerplate task you’ve been putting off
2. Describe it to your AI tool like you’re explaining it to a junior dev
3. Time how long it takes to get something usable
4. Compare to how long it usually takes you

I bet you’ll be surprised. And maybe a little annoyed you didn’t start sooner.

💬 Question for you: What’s your most-hated boilerplate task? The one you’ve copy-pasted from Stack Overflow so many times you could probably recite it?

🔮 Tomorrow

Day 16: The “Explain This” Superpower — how I use AI to understand legacy code in seconds. Including a 5-year-old codebase I inherited last month. (It had Hungarian notation. In Kotlin. I have questions.)

🎯 Takeaway

Boilerplate isn’t creative work. It’s pattern repetition — and pattern repetition is literally what AI does best.

The time I used to spend on adapters and data classes? Now I spend it on architecture, UX, the stuff that actually makes the app better.

Boilerplate is dead. And honestly? I don’t miss it.

#MobileAI #AndroidDev #Boilerplate #HonestTech #AIProductivity #Tech2026

🔗 Real Resources

1. Jetpack Compose Lists Documentation — Official guide to LazyColumn and LazyRow

https://developer.android.com/develop/ui/compose/lists

1. Firebender — AI for Android Studio — The tool I’ve been using for boilerplate generation

https://firebender.com/

1. JetBrains AI Assistant — Alternative if you’re in the IntelliJ ecosystem

https://www.jetbrains.com/ai/

1. Room Database Guide — Official Android persistence library docs

https://developer.android.com/training/data-storage/room

76% of developers now use AI tools. Only 43% say they understand the code it generates.

That stat from Stack Overflow’s 2024 survey haunted me all week.

Week 1 was history class. Week 2 was show-and-tell — no theory, no predictions, just what I actually experienced, measured, and observed.

Now let’s turn 7 days of reality into a toolkit you can actually use.

🧭 The Context

This week I:

• Audited my AI toolbox and deleted half of it
• Tracked a real weekend building session with AI
• Tested on-device AI frameworks in production
• Investigated “AI-powered” apps that weren’t
• Published my actual productivity numbers (30 days of data)
• Observed how new developers code differently than I did

The result? 7 Reality Checks — honest truths about AI in development today.

Not optimistic. Not pessimistic. Just realistic.

✅ The 7 Reality Checks

Reality Check 1: Most AI Tools Don’t Survive the 3-Week Test

From Day 8: I installed 12 AI tools. 5 survived. The rest solved problems I didn’t actually have.

The truth: The tools that last solve real friction — not imaginary problems invented by marketing teams.

🎯 Action: Before adopting any AI tool, ask: “What specific friction does this remove from my daily workflow?” If you can’t name it in one sentence, you don’t need it.

Reality Check 2: AI Is a Multiplier, Not a Replacement

From Day 9: In my weekend session, AI crushed boilerplate (10x faster). Architecture decisions? Still 100% me.

The truth: AI accelerates the easy parts. The hard parts — system design, trade-offs, debugging novel problems — still require a human brain.

🎯 Action: Use AI for generation. Use your brain for judgment. Never outsource the thinking.

Reality Check 3: The Gap Between Demo and Production Is Still Massive

From Day 10: ML Kit and Core ML work great for specific use cases. But “just add AI” to any app? Still a fantasy.

The truth: On-device AI is production-ready for: image classification, text recognition, pose detection, and a few other well-defined problems. Everything else is research-grade.

🎯 Action: When scoping AI features, start with “What’s proven?” not “What’s possible?” Ship boring AI that works.

Reality Check 4: “AI-Powered” Is the New “Cloud-Based”

From Day 11: I tested 5 “AI-powered” apps. 3 were just API wrappers. 1 was literally if-else statements with a chatbot skin.

The truth: Marketing has outpaced reality. The label “AI-powered” means nothing without specifics.

🎯 Action: When evaluating AI products (or building them), ask: “What model? What’s the latency? What happens offline?” Vague answers = vague value.

Reality Check 5: Productivity Gains Are Real but Uneven

From Day 12: My 30-day data showed 2.1x faster for boilerplate, 1.4x for bug fixes, 0.8x for architecture work (AI actually slowed me down).

The truth: The “2x productivity” headlines are cherry-picked. Real gains are task-specific and context-dependent.

🎯 Action: Track your own numbers. Don’t trust industry averages. Your workflow is unique.

Reality Check 6: Speed Without Depth Is Technical Debt

From Day 13: Junior devs I mentored shipped code 3x faster than I did at their stage. But when it broke? They couldn’t debug without AI.

The truth: We’re trading understanding for velocity. That’s a loan, not a gift. The interest compounds.

🎯 Action: For every AI-generated solution you ship, spend 5 minutes understanding why it works. The debugging session you prevent is worth more than the time you save.

Reality Check 7: We’re in the Messy Middle

From Days 8–13: Some tools are genuinely useful. Some are pure hype. Most are somewhere in between.

The truth: We’re past the “AI is magic” peak and heading into the “okay, what actually works?” phase. This is where real value gets built.

🎯 Action: Stop waiting for AI to be “ready.” Start experimenting now. The developers who figure out what works will have a 2-year head start.

📊 The Week 2 Recap

• Day 8: My AI Toolbox — What Stayed, What Got Deleted → Most tools don’t survive real use
• Day 9: A Weekend AI Session — Building My Side Project → AI multiplies, doesn’t replace
• Day 10: On-Device AI — What’s Production-Ready → Demo ≠ production
• Day 11: The “AI-Powered” Label — Marketing vs Reality → Labels are meaningless without specifics
• Day 12: The 2x Productivity Claim — My Actual Numbers → Gains are uneven and context-dependent
• Day 13: How New Devs Code Now vs How I Started → Speed without depth is debt
• Day 14: Week 2 Complete — 7 Reality Checks → We’re in the messy middle

🔮 What’s Next: Week 3 — The Good

Week 1 was about where we came from.

Week 2 was about where we actually are.

Week 3 is about where AI genuinely helps.

Starting tomorrow:

• Day 15: Boilerplate Is Dead (And I Don’t Miss It)
• Day 16: The “Explain This” Superpower
• Day 17: Refactoring Without Fear
• Day 18: Documentation I Actually Write Now
• Day 19–21: Learning faster, reviewing smarter, building magic

No hype. Just the stuff that works.

See you tomorrow.

💬 Question for you: Which reality check surprised you most? Which one did you already know but needed to hear again?

🎯 Takeaway

Week 2 taught us that AI in 2026 is powerful but uneven.

Some tools save hours. Some waste them.

Some claims are real. Most are marketing.

Some developers are thriving. Others are building on sand.

The difference? Honest assessment.

The developers who win in this era won’t be the ones who adopt everything or reject everything. They’ll be the ones who test, measure, and decide for themselves.

You’ve just leveled up. Now go test something. 🚀

🔗 Real Resources

1. Stack Overflow Developer Survey 2024 — AI tool adoption and usage patterns

https://survey.stackoverflow.co/2024/ai

1. GitHub Copilot Research — Productivity impact studies

https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/

1. Google ML Kit Documentation — Production-ready on-device AI

https://developers.google.com/ml-kit

1. Apple Core ML Documentation — On-device machine learning

https://developer.apple.com/documentation/coreml

I watched a bootcamp grad debug code last month. They asked AI 7 times before reading the error message once.

I’m not judging — I’m worried. After mentoring some interns and junior devs in 2025–26, I’ve seen patterns that keep me up at night. Here’s what’s changed, what’s concerning, and what gives me hope.

🕰️ How I Learned to Code (2012–2014)

No AI. No Stack Overflow copy-paste shortcuts. Just pain.

My debugging process:

1. Read the error message (carefully)
2. Re-read my code line by line
3. Add print statements everywhere
4. Google the exact error (if lucky, find a forum post)
5. Read documentation (actual docs!)
6. Ask a senior dev (after trying everything)

Time to first useful contribution: ~3–4 months

What I learned along the way:

• How the language actually works
• How to read stack traces
• How to form mental models of code flow
• The patience to struggle productively

// My 2013 debugging toolkit
fun debugTheHardWay() {
    println(">>> Got here 1")
    println(">>> value = $suspiciousVariable")
    println(">>> Got here 2")
    // Repeat 47 times until enlightenment
}

👶 How New Devs Code Now (2025–2026)

I’ve mentored more than 8 grads and interns over the past year. Here’s what I observed:

The New Debugging Process

1. See error → paste into AI
2. AI suggests fix → apply without reading
3. New error → paste into AI again
4. Repeat until it works (or give up)
5. Never actually understand what went wrong

Time to first contribution: ~2–4 weeks

What they often miss:

• Understanding why the fix works
• Building mental models of the system
• Reading comprehension of code
• The ability to debug without AI

😬 Real conversation I had:
Me: “Why is this API getting called 50 times per second?”
Intern: “I have no idea, the code looks totally normal…”

Me: “You’re using LaunchedEffect with a key that changes on every recomposition."
Intern: “…what’s a recomposition?”

📊 The Data: What I Actually Observed

I tracked behaviors across 8 junior developers over 6 months. While this is a small sample from my personal mentoring experience, broader research supports these trends.

According to a 2024 Stack Overflow survey, 76% of developers now use or plan to use AI tools in their workflow — but only 43% say they “always” or “often” understand the AI-generated code they use.

Problem-Solving Patterns (My Observations)

Read error message first:

• Pre-AI era juniors: ~90%
• AI-era juniors (2025): ~23%

Check documentation:

• Pre-AI era juniors: ~75%
• AI-era juniors (2025): ~12%

Try to understand before fixing:

• Pre-AI era juniors: ~85%
• AI-era juniors (2025): ~31%

Can explain their own code:

• Pre-AI era juniors: ~80%
• AI-era juniors (2025): ~45%

Debug without AI assistance:

• Pre-AI era juniors: ~95%
• AI-era juniors (2025): ~28%

Speed vs. Understanding Tradeoff

AI-era juniors were faster at:

• Writing boilerplate code
• Setting up projects from templates
• Generating test stubs
• Producing “working” code quickly

But slower (or unable) at:

• Debugging novel problems
• Understanding system architecture
• Modifying code they didn’t write
• Explaining technical decisions

🚨 The Concerning Patterns

1. The “Copy-Paste Confidence” Problem

Juniors ship code they don’t understand. It works — until it doesn’t.

// Junior's AI-generated code (not fully understood)
suspend fun fetchData(): Result<Data> = withContext(

When I asked the junior who wrote this: “Why Dispatchers.IO instead of Dispatchers.Default?"

Answer: “That’s what the AI suggested.”

2. The “Learned Helplessness” Pattern

Without AI, some juniors literally cannot function.

Experiment I ran: Asked 4 juniors to fix a simple bug with AI tools disabled.

• 2 eventually solved it (took 3x longer than expected)
• 1 gave up after 30 minutes
• 1 asked if they could “just use ChatGPT real quick”

3. The “Shallow Knowledge” Problem

They know what works but not why it works.

Quiz I gave:

• “What is a coroutine?” → 2/8 could explain
• “Why use withContext(Dispatchers.IO)?" → 1/8 knew
• “What’s the difference between launch and async?” → 3/8 correct

These are juniors who use coroutines daily.

🌟 The Hopeful Patterns

It’s not all doom. Some things are genuinely better:

1. Faster Onboarding (Surface Level)

New devs can contribute something in days, not months. For simple tasks, this is great.

2. Less Fear of Trying

AI reduces the fear of looking stupid. Juniors experiment more because they have a safety net.

3. Better Code Formatting

AI-generated code is often cleaner than what I wrote as a junior. Consistent style, reasonable naming.

4. The Curious Ones Still Shine

The best juniors I mentored used AI and asked “why?” They:

• Used AI to generate, then studied the output
• Asked me to explain AI suggestions
• Deliberately practiced without AI sometimes
• Built mental models alongside the shortcuts

⭐ The standout intern: Used AI to generate code, then spent 20 minutes understanding every line before committing. Slower at first, but after 3 months, they could debug circles around their peers.

🧭 What Senior Devs Should Do

If you mentor juniors, consider:

1. “Explain It Back” Rule

Before merging AI-generated code, juniors must explain what it does.

2. “AI-Free Fridays”

One day a week, practice debugging without AI. Build the muscle.

3. Teach the “Why”

Don’t just review code — explain the concepts. AI can’t teach system thinking.

4. Assign “Understanding” Tasks

Not just “fix this bug” but “explain why this bug happened and how you’d prevent it.”

🎓 What Junior Devs Should Do

If you’re new to development:

1. Read the Error First

Before AI, spend 60 seconds actually reading the error message. You’ll be surprised.

2. Understand Before Committing

If you can’t explain it, you don’t own it. AI-generated code is your responsibility.

3. Practice Without AI

Schedule time to code without assistance. The struggle is where learning happens.

4. Ask “Why” Not Just “What”

Don’t just ask AI for a fix. Ask it to explain the concept. Then verify with docs.

🧪 Mini Challenge

For junior devs:

Next time you hit an error, set a timer for 5 minutes. Try to understand it before asking AI. Write down what you learned.

For senior devs:

Ask your junior to explain their last PR without looking at the code. Note where understanding breaks down.

💬 Question for you: If you mentor juniors, have you noticed these patterns? If you’re junior, how do you balance AI speed with deep understanding?

🔮 Tomorrow’s Preview

Day 14: Week 2 Complete — 7 Reality Checks about AI in development today. The honest summary before we explore what actually works.

🎯 Takeaway

AI has made junior devs faster at producing code but potentially slower at becoming real engineers.

The gap isn’t about age or talent — it’s about deliberate understanding vs. convenient shortcuts.

The best juniors in 2026 will be those who use AI as a learning accelerator, not a thinking replacement. And the best seniors will be those who teach why, not just review what.

The question isn’t “should juniors use AI?” — it’s “are they learning, or just generating?”

You’ve just leveled up. Now go teach someone. 🚀

#MobileAI #JuniorDev #Mentorship #HonestTech #Tech2026

🔗 Real Resources

1. Stack Overflow Developer Survey 2024 — AI tool adoption and comprehension data

https://survey.stackoverflow.co/2024/ai

1. Coding Bootcamp Market Report 2025 — Outcomes and employment trends

https://www.coursereport.com/reports/coding-bootcamp-market-report

1. Stack Overflow Blog: The Dangers of AI-Dependent Learning — How AI affects developer skill-building

https://stackoverflow.blog/2024/06/10/ai-coding-tools-learning-developers/

1. Kotlin Coroutines Official Guide — Understanding Dispatchers and context

https://kotlinlang.org/docs/coroutines-guide.html

“AI makes developers 2x faster!” Great. Where’s the data?

I tracked my own productivity for 30 days. The AI industry tracked theirs too. Spoiler: We’re both unreliable narrators. Here’s what the numbers actually show.

💡 The Productivity Myth

Every AI coding tool promises massive productivity gains. GitHub claims Copilot makes developers 55% faster. Marketing decks throw around “2x” and “10x” like confetti.

But in July 2025, METR — an AI safety research organization — ran an actual randomized controlled trial with experienced open-source developers working on their own repositories.

The result?

Developers using AI tools took 19% LONGER to complete tasks. Not faster. Slower.

Even more shocking: developers thought they were 20% faster. They were wrong by almost 40 percentage points.[1]

📊 The Real Numbers (2025–2026 Data)

What the Research Actually Shows

METR RCT Study (July 2025)[1]

• Experienced developers on their own repos
• With AI: 19% slower than without
• Developer self-assessment: “20% faster” (completely wrong)

DORA State of AI-Assisted Development (2025)[2]

• Gains in code generation → lost to “downstream chaos”
• Real team outcomes: 0.8x — 1.2x range
• Negative effects more common than positives

JetBrains Developer Ecosystem (2025)[3]

• 85% of developers use AI tools regularly
• 62% use at least one AI coding assistant
• 15% still haven’t adopted AI tools

Codemanship Analysis (Jan 2026)[4]

• “Claims of 2x, 5x, 10x don’t stand up to scrutiny”
• “No shortage of anecdotal evidence, but not a shred of hard data”
• “When we measure it, the gains mysteriously disappear”

🧪 Why We’re Unreliable Narrators

The METR study exposed something uncomfortable: developers can’t accurately assess their own productivity.

Why?

🧠 Cognitive Load Shifting

• AI generates code fast → feels productive
• But reviewing, debugging, integrating AI code → takes longer
• We remember the fast generation, forget the slow fixes

🎭 Expectation Bias

• We want AI to make us faster (we paid for it)
• Confirmation bias kicks in
• We attribute wins to AI, blame losses on other factors

⏱️ Wrong Metrics

• Lines of code per hour? Up.
• Working features per week? Often down.
• “Faster cars ≠ faster traffic” — optimizing a non-bottleneck makes real bottlenecks worse

📈 My 30-Day Self-Experiment

After reading the METR study, I tracked my own work for 30 days:

data class ProductivityLog(
    val task: String,
    val estimatedTime: Duration,
    val actualTime: Duration,
    val aiUsed: Boolean,
    val aiHelpfulness: Int // 1-5
)

// My results after 30 days:
val summary = mapOf(
    "Tasks with AI" to TaskStats(
        avgTimeVsEstimate = 1.15, // 15% over estimate
        completionRate = 0.92,
        bugRate = 1.3 // 30% more bugs caught in review
    ),
    "Tasks without AI" to TaskStats(
        avgTimeVsEstimate = 1.08, // 8% over estimate
        completionRate = 0.89,
        bugRate = 1.0 // baseline
    )
)

My Honest Results

Where AI actually helped:

• Boilerplate generation (adapters, models, test stubs)
• Explaining unfamiliar codebases
• Drafting documentation
• Regex and complex queries

Where AI cost me time:

• Complex business logic (had to rewrite AI suggestions)
• Architecture decisions (AI doesn’t know my system)
• Debugging AI-generated code (subtle bugs)
• Context switching between AI chat and IDE

Net result: Roughly break-even — maybe 5–10% faster on some tasks, 10–15% slower on others.

🔑 The “Downstream Chaos” Problem

The DORA report nailed it: code generation isn’t the bottleneck.

Software development time breakdown:

📝 Writing new code: ~20% of time

🔍 Reading/understanding code: ~30% of time

🐛 Debugging: ~25% of time

🤝 Communication/meetings: ~15% of time

📦 Deployment/ops: ~10% of time

AI optimizes the 20%. But if that 20% produces buggier code, it increases the 25% debugging time. Net effect? Often negative.

🚗 The traffic analogy: Faster cars don’t reduce traffic. They just let you reach the traffic jam faster. Similarly, faster code generation doesn’t reduce delivery time — it just moves the bottleneck.

✅ How to Actually Measure Your Productivity

Don’t trust your gut. Track these metrics:

🎯 Task Completion Time

• Time from “started” to “merged and deployed”
• Not just “code written”

🐛 Defect Rate

• Bugs found in code review
• Bugs found in QA
• Bugs found in production

🔄 Rework Rate

• How often do you revisit “done” code?
• How many review cycles before merge?

💭 Cognitive Load

• Do you understand your own code?
• Can you debug it without AI?

🧪 Mini Challenge

Track your productivity for one week:

1. Log every task with estimated vs actual time
2. Note whether you used AI assistance
3. Track bugs found in review
4. At week’s end, calculate honestly:

• Average time vs estimate (with AI)
• Average time vs estimate (without AI)
• Bug rate comparison

Share your results. I bet you’ll be surprised.

💬 Question for you: Have you tracked your actual productivity with AI tools? Did the numbers match your expectations?

🔗 Tomorrow’s Preview

Day 13: How New Devs Code Now vs How I Started — I observed bootcamp grads and interns in 2025–26. The differences are fascinating… and concerning.

🎯 Takeaway

The 2x productivity claim is marketing, not measurement. When researchers run actual controlled experiments, the gains disappear — or reverse.

This doesn’t mean AI is useless. It means:

1. Measure, don’t assume — track your actual output
2. Optimize the real bottleneck — usually not code generation
3. Use AI where it actually helps — boilerplate, explanation, drafts
4. Stay skeptical of vendor claims — they’re selling, not measuring

The best developers in 2026 aren’t the ones using the most AI. They’re the ones who know when to use it — and when to think.

You’ve just leveled up. Go measure something real. 🚀

🔗 Real Resources

1. METR Study: AI Makes Experienced Developers 19% Slower
2. DORA State of AI-Assisted Software Development 2025
3. JetBrains State of Developer Ecosystem 2025
4. The AI-Ready Developer: Same Game, Different Dice
5. Where’s the Shovelware? Why AI Coding Claims Don’t Add Up
6. arXiv: Measuring AI’s True Impact on Developer Productivity

“AI-powered” is the new “organic” — everyone claims it, few actually deliver.

I spent a week testing apps that promise AI magic. Some delivered. Most didn’t. Here’s my honest breakdown of what’s real and what’s just marketing.

💡 The “AI Washing” Problem

Remember when every product became “cloud-based” even if it just saved a file to Dropbox? Welcome to 2026, where everything is “AI-powered” — even if it’s just a basic algorithm or, worse, actual humans pretending to be AI.

The term: AI washing — inflating or fabricating AI capabilities to attract users, investors, or hype.

The FTC launched “Operation AI Comply” in 2024 specifically to crack down on this. But the problem has only grown.[1]

🔍 5 “AI” Claims That Weren’t What They Seemed

1. 🛒 Nate — The Shopping “AI” That Was Actually Humans

The claim: AI-powered universal checkout. One tap to buy from any website.

The reality: The “AI” was actually call center workers in the Philippines and Romania manually completing purchases. Founder Albert Saniger raised $40 million and is now facing fraud charges.[2]

Red flag: If an “AI” handles complex, unpredictable tasks perfectly every time — ask how.

2. 🏗️ Builder.ai — The “AI Assistant” That Was 700 Engineers

The claim: Chat with Natasha, their AI, and get a custom app built automatically.

The reality: 700 human engineers in India were posing as “Natasha” in chat conversations, then manually coding the apps. Microsoft-backed startup, exposed in 2025.[3]

Red flag: “AI” that produces complex, creative outputs with no visible generation time.

3. 📱 Apple Intelligence — Features Advertised Before They Existed

The claim: iPhone 16 marketing showed AI features as available.

The reality: The Better Business Bureau found Apple “reasonably conveyed” that features were available at launch when they weren’t. NAD recommended Apple stop implying availability of unreleased features.[4]

Red flag: Marketing shows AI doing things the actual product can’t do yet.

4. 🎬 Fake “Sora” Apps — Riding the Hype Wave

The claim: Multiple App Store apps claimed to be OpenAI’s Sora video generator.

The reality: Scam apps got 300,000+ installs before being caught. They either did nothing, charged subscriptions for fake features, or harvested user data.[5]

Red flag: Hot AI tool available on app stores before official release.

5. 🤖 Generic “AI Photo Enhancers” — Just Filters With Extra Steps

The claim: “AI-powered” photo enhancement, background removal, face beautification.

The reality: Many are just applying pre-built filters or using basic algorithms that existed for years. The “AI” label is purely marketing. Some legitimate ones exist (like ML Kit’s segmentation), but many are just… filters.

Red flag: Results look identical regardless of input. No processing time. Works offline on devices that can’t run AI models.

📊 The Real Numbers

95% of business AI applications have failed to deliver promised value.[6]

The New Yorker’s 2025 review: “The tech industry overpromised and underdelivered” on AI.[7]

🧪 How to Spot Fake “AI” — A Developer’s Checklist

fun isLikelyRealAI(app: App): Boolean {
    return when {
        // Real AI needs processing time
        app.responseTime < 100.milliseconds -> false
        
        // Real AI varies its outputs
        app.outputsAreIdentical -> false
        
        // Real AI has size (models are big)
        app.sizeInMB < 10 && app.claimsOnDeviceAI -> false
        
        // Real AI has documented model info
        app.hasNoModelDocumentation -> false
        
        // Real AI companies show their work
        app.companyHasNoAIResearch -> false
        
        else -> true // Maybe real, investigate further
    }
}

✅ Apps That Actually Deliver (2026 Edition)

Not everything is fake. After all the hype and hustle, some apps actually do what they claim — with real models, real research, and real results you can verify yourself.

Here’s my curated list of 10 apps that pass the sniff test. They have documented AI/ML pipelines, verifiable offline modes (where applicable), and the companies behind them publish their technical work openly.

🤖 LLM & AI Assistants

🤖 ChatGPT — GPT-4o/4.1, #1 downloaded app in US (2025). → OpenAI

🧠 Claude — Anthropic’s AI, 5M+ downloads, voice mode, Android integration. → Anthropic

✨ Gemini 3 Pro — Google’s flagship reasoning model, multimodal, via AI Studio. → Google AI

🔎 Perplexity — AI-native search with citations. Daily Google alternative. → a16z Top 100

💻 Developer Tools

🐙 GitHub Copilot — AI pair programmer with measured productivity gains. → GitHub Blog

🧠 JetBrains AI — IDE-native AI with project context and refactoring. → JetBrains AI

💻 Claude Code — Agentic coding in terminal/IDE, VS Code extension, Claude Sonnet 4.5. → Claude Code

🔥 Firebender — AI coding assistant for Android Studio, YC-backed, real-time SDK support. → Firebender

🚀 Google Antigravity — Next-gen agentic IDE. Synchronized control across editor, terminal, browser. → Antigravity

👁️ Vision & Search

🔍 Google Lens — On-device ML Kit models. Works offline. → ML Kit

🍏 Apple Photos — Core ML–powered face & object detection, on-device. → Core ML

✍️ Writing & Productivity

🌐 DeepL — Neural machine translation with strong benchmarks. → DeepL Blog

✍️ Grammarly — Large-scale NLP models for grammar, style, and tone. → Engineering Blog

📝 Notion AI — LLM + retrieval over your workspace, default in product. → Notion AI

🎨 Design & Creative

🎨 Canva — Magic Design, Magic Media — production-grade at scale. → a16z Top 100

🎨 Gamma — AI presentation maker, 250M+ decks generated, has API. → Gamma

🍌 Nano Banana — Gemini’s creative suite. Doodle-to-image, style transfer, on-device. → Google

💡 Pro tip: If an app claims “on-device AI,” turn on airplane mode and try it. Real on-device models keep working.

🧪 Mini Challenge

Test an “AI-powered” app in your phone:

1. Turn on airplane mode
2. Try the “AI” feature
3. If it works identically → might be real on-device AI
4. If it fails or degrades → it’s cloud-dependent (not necessarily fake, but know what you’re getting)
5. If it works perfectly for complex tasks → be suspicious

💬 Question for you

Have you encountered an “AI-powered” app that turned out to be fake or misleading? What gave it away?

🔗 Tomorrow’s Preview

Day 12: The 2x Productivity Claim — I tracked my actual numbers for 30 days. Here’s the truth about AI-assisted coding speed.

🎯 Takeaway

The “AI-powered” label has become meaningless. Some apps are genuinely using machine learning. Others are using humans, basic algorithms, or nothing at all.

As developers, we have a responsibility to be honest about what our apps actually do. And as users, we should demand proof, not promises.

The best AI is invisible. The worst “AI” is a lie with a marketing budget.

You’ve just leveled up. Go build something honest. 🚀

🔗 Real Resources

• FTC Operation AI Comply — Consumer Alerts
• AI Washing Explained — TechTarget
• Why AI Didn’t Transform Our Lives in 2025 — The New Yorker
• 95% of AI Applications Have Failed — ZDNet
• Apple AI Ads Misleading — PCMag

Not all “AI features” need the cloud. Some of the most useful ones run entirely on your user’s phone.

I’ve spent the last few weeks testing what’s actually production-ready in on-device AI. Not demos. Not “coming soon.” Real APIs you can ship today.

Here’s my honest breakdown.

💡 The Three Players

🤖 ML Kit (Android)

Google’s workhorse for on-device machine learning. Been around since 2018, battle-tested, and genuinely production-ready.

What actually works well:

Text Recognition — Scans documents, receipts, business cards. Supports 100+ languages. Fast enough for real-time camera input. I’ve shipped this in production apps — it just works.

Barcode Scanning — QR codes, barcodes, all formats. Faster than any third-party library I’ve tried. Zero cloud dependency.

Face Detection — Detects faces, landmarks, expressions. Good for camera filters, attendance systems, photo organization. Not face recognition (that’s different and harder).

Pose Detection — 33 body landmarks in real-time. Fitness apps, physio tracking, gesture controls. Works surprisingly well even on mid-range devices.

Image Labeling — “This is a dog. This is a car.” Useful for auto-tagging, accessibility features, content moderation.

My verdict: If your feature fits one of these categories, ML Kit is the answer. It’s stable, well-documented, and won’t surprise you in production.

🍎 Core ML + Foundation Models (iOS)

Apple’s approach is different. Core ML lets you run any converted model on-device. The new Foundation Models framework (iOS 18.4+) gives you direct access to Apple Intelligence’s on-device LLM.

What actually works well:

Core ML — Convert models from PyTorch/TensorFlow, run them on-device with hardware acceleration. Great if you have your own models. Learning curve is steeper than ML Kit, but more flexible.

Vision Framework — Text recognition, face detection, object tracking. Apple’s equivalent to ML Kit’s vision APIs. Solid and reliable.

Foundation Models (new in 2025) — Access Apple Intelligence’s on-device model for summarization, text extraction, guided generation. Three lines of Swift code. But only works on devices with Apple Intelligence (iPhone 15 Pro+, M-series Macs).

My verdict: If you’re iOS-only and want maximum flexibility, Core ML is powerful. The new Foundation Models framework is exciting but device-limited.

✨ Gemini Nano (Android)

Google’s on-device LLM. The promise: run generative AI without cloud costs or latency.

What actually works (as of late 2025):

ML Kit GenAI APIs — Summarization, proofreading, rewriting. Available through the ML Kit SDK. Works on Pixel 8+ and select Samsung devices.

Google AI Edge SDK — More experimental access to Gemini Nano capabilities.

The reality check:

• Device support is limited (flagship phones only)
• Still marked as “experimental” for some features
• Quality varies by task — good for short text, struggles with complex reasoning
• No custom fine-tuning yet

My verdict: Exciting for the future, but not ready for “ship to all users” production. Great for progressive enhancement on supported devices.

📊 The Honest Comparison

ML Kit (Android):

• ✅ Production-ready since 2018
• ✅ Works on almost any Android device
• ✅ Well-documented, stable APIs
• ❌ Limited to pre-defined tasks (no custom LLM)

Core ML (iOS):

• ✅ Run any converted model
• ✅ Hardware acceleration on Apple Silicon
• ✅ Foundation Models for Apple Intelligence
• ❌ Steeper learning curve
• ❌ Foundation Models limited to newer devices

Gemini Nano (Android):

• ✅ On-device generative AI
• ✅ No cloud costs for supported tasks
• ❌ Limited device support
• ❌ Still experimental for many use cases

💻 Code Example: ML Kit Text Recognition (Kotlin)

val recognizer = TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS)

val image = InputImage.fromBitmap(bitmap, 0)
recognizer.process(image)
    .addOnSuccessListener { result ->
        val recognizedText = result.text
        // Use the text
    }
    .addOnFailureListener { e ->
        // Handle error
    }

That’s it. No API keys. No cloud setup. No network calls. Just works.

🧪 Mini Challenge

Try this in the next 30 minutes:

1. Pick one ML Kit feature (text recognition is easiest)
2. Add the dependency to your Android project
3. Run it on a real device with a sample image
4. Time how long it takes to get results

You’ll be surprised how fast on-device inference actually is.

💬 Question for you

Have you shipped any on-device AI features? What worked? What didn’t?

🔗 Tomorrow’s Preview

Day 11: The “AI-Powered” Label: Marketing vs Reality — 5 apps I tested that don’t do what they claim.

🎯 Takeaway

On-device AI isn’t the future — it’s the present. But only for specific, well-defined tasks. ML Kit for Android and Core ML for iOS are genuinely production-ready. Gemini Nano is promising but not quite there yet.

The best on-device AI feature is the one your users never notice — because it just works.

You’ve just leveled up. Go build something weird. 🚀

🔗 Real Resources

• ML Kit Documentation — Google Developers
• Core ML — Apple Developer
• Foundation Models Framework — Apple Developer
• Gemini Nano on Android — Android Developers
• ML Kit GenAI APIs — Android Developers Blog

Here’s what a weekend side project session actually looks like with AI — no corporate polish, just reality.

Yesterday I told you which tools survived my purge. Today I’ll show you how I actually use them — on my own time, for my own projects. This isn’t about impressing anyone. It’s about what genuinely works when I’m building something I care about.

⏰ A Saturday Afternoon: Building a Feature for My Side Project (Not related to my real project)

☕ 2:00 PM — Starting Fresh

Tool: Firebender

Task: I’m adding a new feature to my side project — a taxi booking app I’m building in my free time. Firebender is already running in Android Studio. I ask it to help me scaffold a booking confirmation screen.

Reality check: Firebender knows my codebase. It pulls patterns from my existing screens and generates a layout that actually fits my app’s architecture. 70% usable on the first try.

🔧 3:00 PM — The Bug Hunt

Tool: Firebender

Task: Something’s broken in the payment flow. The logs are confusing. I highlight the error in Android Studio and ask Firebender to explain what’s happening.

Reality check: It pinpoints a null pointer issue in my callback chain. Took 2 minutes instead of the 30 I would’ve spent with println debugging. This is where Firebender earns its keep.

🤖 4:00 PM — Delegating the Boring Stuff

Tool: Junie

Task: I’ve been putting off updating dependencies and fixing lint warnings for weeks. I ask Junie to handle it: “Update all dependencies to latest stable versions and fix critical lint errors.”

Reality check: Junie picks it up right inside Android Studio. While I grab a coffee and watch something on YouTube, it works through the changes. I review it later — 90% good, 10% needs manual tweaking. But I didn’t have to do the grunt work.

🍕 5:00 PM — The Human Recharge

Tool: None

Task: Pizza. Fresh air. Zero screens.

Reality check: My best architecture decisions happen away from the keyboard. No AI can replicate what a clear head gives you.

📝 6:00 PM — Documentation Nobody Wants to Write

Tool: Claude

Task: I need to document the booking API for future-me (who will definitely forget how this works in 3 months). I describe the endpoints to Claude, it drafts the docs.

Reality check: First draft is too wordy. I cut half of it. But starting from something is better than staring at a blank README.

🤯 7:00 PM — The Overconfidence Trap

Tool: Firebender

Task: Feeling lazy, I ask Firebender to refactor my entire networking layer in one go. “Just clean this up,” I say, selecting 500 lines of code.

Reality check: It breaks 4 things. I spend 20 minutes undoing the damage. Lesson learned: AI works best on focused tasks, not “fix everything” requests.

🏁 8:00 PM — Wrapping Up

Tool: Junie

Task: I ask Junie to write unit tests for BookingConfirmationViewModel. It generates test stubs directly in my project. I’ll review and polish them tomorrow.

Reality check: It’s not perfect, but it’s a starting point. And I didn’t have to write boilerplate test setup code myself.

📊 The Honest Scorecard

AI Time Saved: ~1.5 hours
AI Time Wasted: ~25 minutes (the refactor disaster)
Net Gain: ~1 hour
Biggest Win: Junie handling dependency updates while I took a break
Biggest Fail: Asking Firebender to refactor 500 lines at once

💡 The Pattern I’ve Noticed

AI works best for:

• Explaining — Stack traces, legacy code, “what does this do?”
• Scaffolding — Boilerplate, layouts, test stubs
• Async grunt work — Dependency updates, lint fixes, version bumps (Junie)

AI struggles with:

• Big-picture refactoring — It doesn’t understand why your code is structured a certain way
• Business logic — It doesn’t know your users or your domain
• Knowing its limits — It’s confidently wrong sometimes

🧪 Mini Challenge

Try this on your next side project session:

1. Pick one boring task you’ve been avoiding (dependency updates, docs, tests)
2. Delegate it to an AI tool
3. Track: Did it save time or create more work?

Be honest with yourself. Not every task is worth automating.

💬 Question for you

What’s the one task you’d love to hand off to AI on your personal projects?

🔗 Tomorrow’s Preview

Day 10: On-Device AI: What’s Actually Production-Ready — ML Kit, Core ML, Gemini Nano. Tested, not theorized.

🎯 Takeaway

AI isn’t about using it everywhere. It’s about using it where it actually helps — and being honest when it doesn’t.

You’ve just leveled up. Go build something weird. 🚀

🔗 Real Resources

• Firebender — AI for Android Studio
• Junie — JetBrains AI Coding Agent
• Claude for Developers — Anthropic
• Time tracking for developers — Wakatime

I’ve tried over a dozen AI coding tools in the past year. Only 4 earned permanent spots.

The graveyard includes billion-dollar tools that everyone swears by. Some I used for months. Some didn’t survive the trial. But four tools became part of my daily workflow — and understanding why matters more than which ones.

💡 The Survivors (And Why)

✅ What Stayed

Firebender — AI assistant built for Android Studio. Knows my codebase, logs, emulator. Why it stayed: Android-native context (knows the SDK)

Junie — JetBrains’ AI coding agent for IntelliJ/Android Studio. Assign tasks, it plans and executes autonomously. Why it stayed: Native JetBrains integration + async task execution

Antigravity — Google’s agent-first IDE. Agents plan, execute, verify. Powered by Gemini 2.5 Pro. Why it stayed: End-to-end autonomous building

Claude Models — Not Claude Code — Claude’s models for reasoning, architecture, explaining legacy code. Why it stayed: Deep reasoning and explanation

Note on usage: These tools overlap throughout my day. Firebender runs in my IDE while Junie handles background tasks. I switch to Antigravity for greenfield work and ping Claude when I need to think through something. It’s not 11 hours of AI — it’s AI woven into ~8 hours of work.

Why these four? No overlap. No redundancy. Each earns its place by solving a different problem.

❌ What Got Deleted

GitHub Copilot — Great autocomplete — but Firebender fits my Android workflow better. Status: 🗑️ Uninstalled

ChatGPT for coding — We have real agents now. No more copy-paste between chat and IDE. Status: 🗑️ Stopped

Cursor — Interesting approach, but didn’t fit my JetBrains-based workflow. Status: ⏸️ Trial only

Gemini in Android Studio — Tried it, didn’t feel natural. Firebender does the same thing better. Status: 🗑️ Disabled

The pattern: Tools that tried to do everything lost to tools that did one thing exceptionally well in my specific workflow.

📊 The Numbers Behind My Choices

Market Reality (2025–2026):

• GitHub Copilot: 20+ million all-time users, used by 90% of Fortune 100 companies
• Junie: JetBrains’ agentic AI, deeply integrated with IntelliJ-based IDEs
• Antigravity: Powered by Gemini 3 Pro, supports autonomous agents with direct system access
• Firebender: Y Combinator backed, built specifically for Android developers

Sources: TechCrunch (July 2025), Google Blog (Aug 2025), Firebender (2025)

🧪 My Selection Framework

Before adopting any AI tool, I ask three questions:

1. Does it solve a problem I actually have? (Not a problem marketing invented)
2. Does it fit my existing workflow? (JetBrains/Android Studio-based)
3. Can I verify its output? (If I can’t check it, I can’t trust it)

If #1 is “no” or #2 is “poorly” — I don’t keep it.

🎯 The Honest Truth

Popular ≠ best for you.

GitHub Copilot has 20 million users. But for my Android-focused workflow, Firebender + Junie + Antigravity work better. The “best” tool is the one that fits your stack, your workflow, your brain.

My rule: If a tool doesn’t feel natural within the first week, it’s gone. Life’s too short to fight your tools.

🧪 Mini Challenge

Try this in the next 30 minutes:

Open your IDE. Count how many AI extensions you have installed. For each one, ask: “When did I last actually use this?” If the answer is “I don’t remember” — uninstall it. Right now.

One focused tool beats five forgotten plugins.

💬 Question for you

What AI tools survived your purge? And which popular ones did you drop?

🔗 Tomorrow’s Preview

Day 9: On-Device AI: What’s Actually Production-Ready — ML Kit, Core ML, Gemini Nano. Tested, not theorized.

🎯 Takeaway

The best AI toolbox isn’t the most popular one. It’s the one where every tool fits your workflow like a glove.

You’ve just leveled up. Go build something weird. 🚀

🔗 Real Resources

• GitHub Copilot crosses 20M users — TechCrunch
• Junie — JetBrains AI Coding Agent
• Antigravity — Google’s Agent-First IDE
• Firebender — AI for Android Studio
• Gemini in Android Studio — Android Developers