DEV Community: Md Jamilur Rahman

Blinkist Just Admitted AI Narration Failed. That Should Worry Every AI Optimist.

Md Jamilur Rahman — Sun, 14 Jun 2026 09:19:08 +0000

On June 14, 2026, Blinkist sent an email to its millions of subscribers with a subject line that cut through the noise: "No more AI narration at Blinkist."

In an era where every company is racing to inject AI into their products, Blinkist just did the opposite. They tried AI narration for two years, tested it extensively, refined it — and concluded it wasn't good enough.

They're going back to humans.

What Blinkist Actually Said

The email, signed by Thomas Anderson, VP of Content at Blinkist, was unusually honest for a corporate announcement:

"We tested extensively; we refined; we genuinely believed we could close the gap between AI and human narration. But ultimately, we couldn't."

"No AI-narration — no matter how polished — can deliver the same depth that a human narrator can. Our narrators are experts in sharing key insights in ways that spark your curiosity and get the information to stick. Even the best AI cannot do this as well."

This isn't a company making a symbolic gesture. Blinkist pioneered audio learning back in 2014, before the podcast boom. They launched their first audio Blinks a decade ago. Audio is their core product — not a side feature.

They're not removing existing AI-narrated content from their library (it'll be marked as AI-generated so users can choose), but every new Blink going forward will be narrated by humans.

Why This Matters Beyond Blinkist

Blinkist's decision fits a growing pattern in 2026. The initial wave of AI hype — where companies slapped AI onto everything and called it innovation — is colliding with reality.

The numbers tell the story:

Gartner reports 80% of AI projects fail to deliver business value
Morgan Stanley found only 21% of S&P 500 companies can point to a measurable AI benefit
Companies that cut staff to fund AI saw identical financial returns to those that kept their teams, per S&P 500 data
Salesforce laid off staff from its Agentforce AI team while four senior AI executives departed in three months

The gap between AI spending and AI results has become too wide for many organizations to justify. Global AI capex is projected at $527 billion for 2026 (Goldman Sachs), yet companies are quietly scaling back where AI doesn't deliver.

The "Good Enough" Trap

The AI narration debate exposes a flaw in how the tech industry thinks about quality.

When AI voice generation crossed the "uncanny valley" — when it stopped sounding robotic and started sounding human — many assumed the problem was solved. The voices were smooth, the pronunciation was correct, the pacing was natural.

But Blinkist discovered something that benchmarks can't measure: connection.

A human narrator doesn't just read words. They interpret them. They emphasize the right phrase. They pause for effect. They bring an author's personality to life. These are not technical problems that more training data can solve — they're emotional and artistic ones.

Blinkist's own framing is telling. They didn't say AI narration was "bad." They said it couldn't deliver the same depth. It couldn't spark curiosity. It couldn't make information stick.

This is the difference between "good enough" and "good." And for a product whose entire value proposition is learning retention, "good enough" isn't good enough.

The Broader Pattern: AI as Tool, Not Replacement

Blinkist isn't abandoning AI entirely. They still offer "Blinkist AI" as a Pro feature for summarizing articles, PDFs, and videos. AI handles the mechanical work — extraction, summarization, organization. Humans handle the part that requires artistry: narration, interpretation, emotional connection.

This is the model that actually works in 2026:

AI for scale: Summarizing 8,000+ books, processing content at machine speed
Humans for craft: Narrating, editing, curating — the work that creates emotional resonance

The companies thriving with AI aren't the ones replacing humans. They're the ones using AI to eliminate drudgery so humans can focus on the work that actually matters.

What This Means for Developers and Product Builders

If you're building AI-powered products, Blinkist's reversal carries three lessons:

1. Measure what users actually value, not what AI can do. Blinkist tested AI narration and found users didn't engage as deeply. The technology worked. The experience didn't.

2. "Good enough" is a trap. AI that's 90% as good as a human sounds impressive in a demo. In production, against a competitor using humans, that 10% gap is the difference between retention and churn.

3. Honesty builds trust. Blinkist's email didn't bury the admission. It led with it. They told users they were wrong, explained why, and committed to doing better. In a market saturated with AI hype, admitting AI failed in a specific use case is more credible than pretending it didn't.

The Real AI Divide

The narrative in 2024-2025 was simple: AI will replace humans everywhere. Companies that don't adopt AI will die.

The reality in 2026 is more nuanced. AI is powerful for specific tasks — code generation, data analysis, content summarization, customer support triage. But it fails at tasks requiring emotional intelligence, artistic interpretation, and human connection.

Blinkist spent two years and significant resources learning this lesson. They could have quietly kept AI narration to save costs. Instead, they chose to prioritize product quality over cost optimization.

That's the signal worth paying attention to. Not every AI reversal means AI is failing. But each one reveals where the technology's actual limits are — and those limits are more real than the hype cycle admits.

The companies that win won't be the ones with the most AI. They'll be the ones who know exactly when to use it — and when not to.

Sources:

Blinkist email to subscribers, "No more AI narration at Blinkist," signed by Thomas Anderson, VP Content (June 14, 2026)
Grey Journal, "Why Companies Are Pulling Back From AI in 2026"
Technology.org, "Tech leaders are abandoning generative AI en masse" (February 2026)
Forbes, "AI Companies Race To Clean Up AI Slop Because Model Performance Depends On It" (February 2026)
Inkfluence AI, "AI vs Human Audiobook Narrators: Quality Comparison 2026"

Jetpack Compose Just Got Styles, Grid, and CSS-Like Media Queries

Md Jamilur Rahman — Sun, 14 Jun 2026 09:00:10 +0000

Google's Android team quietly shipped some of the most significant Jetpack Compose updates since its launch. Compose 1.10 and 1.11 introduce layout primitives that feel surprisingly familiar to web developers — Styles, Grid, FlexBox, and MediaQuery are here, and they change how Android UIs are built.

Compose Is Now the Standard

Nick Butcher from Google's Android team made it clear in the latest Android Developers video: Jetpack Compose is no longer the "new way" to build UIs. It is the way.

Google is pushing a "Compose First" approach, with new tools to convert legacy XML layouts into Compose code directly in Android Studio. The message to teams still on XML Views is unambiguous — the migration window is closing.

The Big Three: Styles, Grid, MediaQuery

Three experimental APIs in Compose 1.11 fundamentally expand what's possible in declarative UI.

Styles API

The Styles API lets developers declare style variations against component state in a single block. Previously, styling a button's pressed, disabled, and focused states required stacking modifier chains and managing InteractionSource objects with remember blocks.

Now, pressed-state gradients, padding variations, and sizing changes become style properties — declared once, applied consistently.

This is conceptually close to CSS pseudo-classes (:hover, :active), and that comparison isn't accidental. Google is borrowing proven patterns from the web.

Grid — A 2D Layout System

Compose finally has a proper 2D grid layout built on tracks, gaps, and cells. Items can span multiple rows or columns, reflow dynamically, and be sized using Dp, percentages, intrinsic constraints, or flexible Fr units.

The mental model is closer to CSS Grid than the existing LazyVerticalGrid. Best suited for static dashboards and rich content layouts where precise 2D placement matters.

MediaQuery — Declarative Environment Queries

MediaQuery replaces the boilerplate of manually tracking window layout sizes and reacting to foldable postures. Instead of observing WindowInfoTracker and writing conditional logic, developers describe what they want:

"If tabletop posture, show split layout."

The system handles the rest. This is CSS @media queries for Android — and it's long overdue.

FlexBox

FlexBox adds wrapping behavior, multi-axis alignment, and grow/shrink controls. Paired with Grid, Compose now covers the full spectrum of responsive layout strategies that web developers have used for years.

Performance Improvements

Beyond new APIs, Compose 1.11 ships under-the-hood performance work:

Trackpad input now reports as PointerType.Mouse instead of touch events, aligning Chromebook and tablet behavior
Shared element debugging via LookaheadAnimationVisualDebugging — overlays target bounds and animation trajectories
Composition host defaults — clipboard, focus manager, and soft input services flow through the Compose runtime instead of Android-specific locals, simplifying Kotlin Multiplatform shared modules
@PreviewWrapper annotation — define theme injection and fake CompositionLocal setups once, apply across all previews

TikTok's Case Study: 58% Less Code

The most compelling argument for Compose adoption comes from TikTok.

TikTok's Android team adopted Compose to address technical debt and improve development velocity. Their results, published on the Android Developers Blog in March 2026:

58% reduction in code size for migrated features
Faster page loading times, starting with QR code screens
Simplified view hierarchies reducing performance bottlenecks
Improved testability across the board

Key lessons from TikTok's migration:

Migrate entire ViewHolders to Compose, not partial ones — partial migrations created more complexity than they solved
Start small — QR codes first, then expand to larger features
Centralize the design system in a shared Compose library before scaling adoption
Optimize ComposeView usage carefully — wrapping legacy views in Compose has performance costs

TikTok plans to steadily increase Compose adoption as its preferred framework across the app.

Testing v2: The Breaking Change Nobody's Talking About

The most disruptive change in Compose 1.11 isn't a new component — it's the testing framework.

Testing v2 is now the default. The dispatcher moved from UnconfinedTestDispatcher (immediate execution) to StandardTestDispatcher (queued execution). This means recompositions now queue rather than executing immediately in tests.

Developers must explicitly advance recompositions with advanceUntilIdle() or runOnIdle. This eliminates a class of flakiness where tests would "read ahead" of recompositions — but it also breaks any test that implicitly relied on the old immediate flush.

If you maintain a large UI test suite, expect migration work. Google has published a testing migration guide to help.

Adaptive Layouts and TV Support

Compose 1.11 expands beyond phones:

Adaptive layout APIs respond to different screen sizes, foldable postures, and device types automatically
Google TV pointer remote support — Compose now handles D-pad and pointer interactions for Android TV, replacing the aging Leanback framework with a declarative focus model

This means one codebase can target phones, tablets, foldables, and TVs with shared composables — a first for Android.

What's Next

Compose 1.12 will require compileSdk 37 and AGP 9. Teams should plan toolchain bumps now to avoid being caught off guard.

The broader trend is clear: Google is systematically porting proven web layout concepts to Android. Styles, Grid, MediaQuery, FlexBox — these aren't coincidental names. They're an acknowledgment that the web solved layout problems decades ago, and Android is catching up fast.

For teams still on XML Views, the case for migration keeps getting stronger. TikTok proved it works at scale. The tools to convert legacy code are here. And every release makes the gap between Compose and XML wider.

Sources:

Android Developers, "What's new in Jetpack Compose" (YouTube, June 2026)
Android Developers Blog, "TikTok reduces code size by 58% with Jetpack Compose" (March 2026)
Dove Letter Release Notes, "Jetpack Compose — April 2026 Updates" by Jaewoong Eum (doveletter.dev)
Kotlin Multiplatform Docs, "What's new in Compose Multiplatform 1.11.1" (kotlinlang.org)
Google Compose First documentation: goo.gle/compose-first

Open Source Maintainers Are Quitting Because of AI

Md Jamilur Rahman — Sun, 14 Jun 2026 08:17:16 +0000

A new kind of contributor is flooding GitHub. They don't read your codebase. They don't file issues. They fire off a prompt, paste the output into a pull request, and expect you to merge it.

And open source maintainers are exhausted.

The "Reverse Centaur" Problem

Cory Doctorow coined a term for what's happening: reverse centaurs. In Greek mythology, the centaur was half-human, half-horse — the human was in control. A reverse centaur is the opposite: a human serving a machine.

That's exactly what open source maintainers say they've become. Instead of reviewing code written by developers who understood the project, they're now reviewing code extruded by LLMs — code generated by someone who typed a prompt without reading the documentation.

Miguel Grinberg, author of the O'Reilly book Flask Web Development and maintainer of several popular Python projects, wrote about this on June 13, 2026:

"All these people who submit drive-by pull requests to my projects are pushing me to spend more and more of my time reviewing and merging code that was extruded by machines."

His solution? He now requires contributors to file an issue and discuss the change before submitting a PR. Unsolicited pull requests get closed immediately.

He's not alone.

The Scale of the Problem

The volume of contributions to open source projects has exploded since AI coding tools went mainstream. But quality hasn't kept up.

Maintainers report that LLM-generated pull requests share telltale signs:

Generic descriptions with excessive formatting, emojis, and bullet points
No reference to the project's existing patterns or architecture
Changes that technically work but don't fit the codebase
No genuine engagement — the contributor can't explain why the change matters

Before AI, an unexpected pull request meant someone cared enough about your project to spend hours understanding it and writing a fix. Now, it often means someone spent 30 seconds typing a prompt.

Why This Matters Beyond Open Source

This isn't just a GitHub problem. It's a preview of what happens when AI generates work faster than humans can review it.

The same pattern is appearing in:

Code review at companies — senior engineers drowning in AI-generated diffs
Content moderation — platforms flooded with AI-generated posts
Academia — professors reviewing AI-generated submissions
Customer support — agents reviewing AI-drafted responses

In every case, the human becomes a quality gate for machine output. The machine scales. The human doesn't.

The Economics of AI-Assisted Contributions

Here's the uncomfortable math: it costs almost nothing to generate an AI pull request. But it costs a maintainer real time — often 30+ minutes — to review it properly.

When a contributor can generate 10 PRs in an hour using AI, but a maintainer can only review 5, the system breaks. The maintainer becomes the bottleneck in a pipeline designed to overwhelm them.

Some maintainers have started adding "AI-generated contributions will be closed" to their guidelines. But as Grinberg noted: LLMs don't read contribution guidelines.

What Maintainers Are Doing About It

Several strategies are emerging:

Issue-first policies — Require discussion before code submission
Proof of understanding — Ask contributors to explain their change in their own words
Contribution tests — Small quizzes about the project before allowing PRs
AI detection — Tools to flag LLM-generated code patterns
Slowing down — Some maintainers are simply processing fewer contributions and accepting that good ones will be missed

The Bigger Question

Grinberg raised a point that goes beyond pull requests:

"The main reason I love coding is that it is a challenge, and I think this is actually the same reason why a lot of people prefer to give money to an AI lab and get a machine to spit out code for them."

If the next generation of developers never learns to code without AI assistance, who will maintain the open source infrastructure that AI itself depends on?

The tools that generate these pull requests — the models, the frameworks, the libraries — are themselves built on open source. When AI erodes the maintainer culture that created that foundation, it's eating the hand that feeds it.

Sources:

Miguel Grinberg, "I Am Not a Reverse Centaur" (blog.miguelgrinberg.com, June 13, 2026)
Cory Doctorow, reverse centaur concept (pluralistic.net)
Hacker News discussion (#1 front page, June 13, 2026)

Uber's $1,500/Month AI Limit Tells You Everything About Where Coding Tools Are Headed

Md Jamilur Rahman — Sun, 14 Jun 2026 08:12:04 +0000

Uber's $1,500/Month AI Limit Tells You Everything About Where Coding Tools Are Headed

Uber burned through its entire 2026 AI budget in four months. Now it's capping engineers at $1,500 per tool. That number is more useful than you think.

Last month, Bloomberg reported that Uber now limits every employee to $1,500 per month in token spending for each AI coding tool. Cursor and Claude Code are the two main ones. The limit applies per tool, so using both means $3,000 monthly.

If that sounds like a lot, consider the backstory.

What happened

Uber rolled out Claude Code to its engineering team in December 2025. Usage doubled by February. By April, engineers had consumed the entire year's AI budget. The CTO told the company they were "back to the drawing board" on AI budgeting.

How did it happen so fast? Individual engineers were spending between $500 and $2,000 per month on API calls. Some were sending massive chunks of code through Claude Code's multi-step reasoning, and the bills added up quickly.

Here's the part that stuck with me: 95% of Uber engineers now use AI tools monthly. And 70% of committed code originates from AI. That's not a pilot program anymore. That's the workflow.

Think about that for a second. Seven out of ten code changes that land in Uber's production systems now come from AI. That's a staggering number for a company that moves billions of dollars in rides and deliveries every year. Every safety-critical system. Every payment flow. Every routing algorithm. All of it now has AI fingerprints on most of the code.

The math

Simon Willison did some quick napkin math that I think is more revealing than the headline.

Uber's median software engineer compensation in the USA is about $330,000 per year. If each engineer has two AI tools at $1,500 each, that's $36,000 annually. That works out to roughly 11% of median compensation.

Is 11% a lot? It depends on what you're getting for it.

If a tool saves an engineer 30 minutes a day, that's maybe $75 of salary per day, or $1,600 per month. The tool costs $1,500 per month. The ROI is thin, but it's there.

If a tool only saves 15 minutes a day, the math breaks. You're paying $1,500 for $800 worth of time.

The real question Uber is wrestling with: how much time do these tools actually save?

There's another way to think about it. If an engineer writes 200 lines of code per day without AI and 300 lines with AI, that's a 50% productivity increase. At $330,000 per year, 50% more output is worth $165,000. The AI tool costs $36,000. That's a 4.6x return.

But productivity isn't just about lines of code. It's about speed, quality, and whether the code actually works. Writing code faster doesn't help if you're introducing more bugs. And AI-generated code can be subtly wrong in ways that take longer to find than it took to write.

The honest answer is that nobody really knows the ROI yet. Companies are spending the money because the tools feel useful, not because they have precise measurements. That's how most technology adoption works. You figure out the value after you've already committed to it.

Why $1,500 is the number that matters

The cap itself isn't the story. The story is that Uber is putting a concrete dollar value on AI coding productivity, and that number is now public.

Before this, companies talked about AI tools in vague terms. "Transformative." "Game-changing." "We're seeing massive productivity gains." Nobody put a price on it.

Uber just did. And the price is $1,500 per month per tool.

That number is now a benchmark. If you're an engineering manager at a mid-size company, you're looking at this and thinking: can we afford that? Can we afford not to?

For context, Claude Pro costs $20 per month for individuals. But that's the consumer plan with usage limits. Enterprise API pricing is different. You're paying per token, and heavy usage gets expensive fast.

Uber's $1,500 cap suggests their engineers are using the tools intensely, not just occasionally. This is daily, multi-hour usage. That's the kind of adoption that changes how you work, not just what you work on.

I've talked to developers at other companies who say they're seeing similar patterns. One friend at a fintech startup told me his team went from spending $500/month on AI tools to $3,000/month in three months. Nobody told them to stop. They just kept finding more uses for the tools.

The bigger picture

Uber isn't alone. Fortune reported in May that the company's COO said it's getting harder to justify money spent on "tokenmaxxing" (yes, that's the actual term now). Corporate America is starting to ration AI spending.

This is a familiar pattern with new technology. First comes the gold rush. Then the bill arrives. Then someone says "we need to be more thoughtful about this."

Cloud computing went through the same cycle. Companies migrated everything to AWS, then got surprise bills, then spent six months optimizing their cloud spending. AI coding tools are following the same trajectory, just faster.

But here's what's different this time: nobody is talking about going back. Uber isn't reducing AI usage. They're putting guardrails on it. There's a meaningful difference.

95% of engineers using these tools monthly means the habit is formed. You can't un-ring that bell. The question is no longer "should we use AI coding tools" but "how much should we spend on them."

The industry is moving from adoption to optimization. That's a sign of maturity, not failure.

What this means for you

If you're an individual developer, this is actually good news in a weird way. Uber's budget constraints don't apply to you. You can use Claude or GPT-4 for $20/month and get most of the same benefits.

If you're an engineering leader, you now have a number to work with. $1,500/month per tool is apparently what heavy usage looks like at scale. Whether that's your ceiling or your target depends on your own ROI calculation.

If you're an AI company selling coding tools, Uber just set your enterprise pricing expectations. $1,500/month per seat is apparently acceptable, but not much more. That's useful information when you're negotiating contracts.

And if you're a developer wondering whether to learn these tools, the answer is yes. The skills transfer. The workflows transfer. And the companies that use them heavily are going to expect you to know them.

The job market is already shifting. I've seen job postings that mention "experience with AI coding tools" as a nice-to-have. That won't be a nice-to-have for long.

My take

I've been using Claude Code and Cursor for a few months now. I spend maybe $200/month total across both. But I'm a solo developer working on smaller projects. At Uber's scale, with thousands of engineers pushing code daily, the math is completely different.

The thing that surprises me isn't the cost. It's the speed of adoption. Four months from rollout to "entire annual budget consumed." That's not a technology story. That's a human behavior story.

Engineers don't adopt tools that don't work. They especially don't adopt tools that cost them time to learn and integrate. The fact that 95% of Uber's engineers are using AI tools monthly tells me these tools are genuinely useful, not just shiny.

But $36,000 per engineer per year is real money. And the productivity gains are hard to measure precisely. Uber is now in the same boat as every other company that adopted cloud computing in 2010: the benefits are obvious, but the costs keep growing, and someone in finance wants to know where the ceiling is.

The answer, as always, is probably "it depends." But now at least we have a starting point for the conversation.

There's also a social dynamic here. When 70% of code comes from AI, the 30% that doesn't becomes the hard part. The complex architectural decisions, the security-sensitive code, the parts that need deep domain knowledge. AI is good at the boilerplate and the patterns. It's less good at the judgment calls.

So the real question might not be "how much are we spending on AI tools" but "what are we spending human attention on?" If AI handles the routine stuff, engineers should be spending more time on the hard stuff. Whether that's actually happening is an open question.

Some engineers I've talked to say they use the time savings to write more code. Others say they use it to think more about architecture. The ones who seem happiest are the ones who use AI for the boring parts and save their brain power for the interesting parts.

That might be the real ROI. Not lines of code per hour, but better decisions per day. The problem is that's really hard to measure. And companies need numbers for their budgets.

The $1,500 number is the real takeaway here. Not as a cap, but as a signal. AI coding tools have crossed from "interesting experiment" to "line item in the budget." That's progress, even if the invoice stings.

Google Just Released a Multimodal AI That Runs on Your Laptop — And It's Free

Md Jamilur Rahman — Sun, 14 Jun 2026 08:11:40 +0000

Google Just Released a Multimodal AI That Runs on Your Laptop — And It's Free

Gemma 4 12B is Google's boldest move yet to put powerful AI in everyone's hands. No cloud required.

Google DeepMind dropped a bombshell today. They released Gemma 4 12B, a new open-source AI model that can process images, audio, and text — all running locally on a laptop with just 16GB of RAM.

This isn't another cloud API. This isn't a gated beta. It's a fully open model under the Apache 2.0 license, meaning anyone can download, run, modify, and deploy it without paying Google a dime.

Let's break down why this matters.

What Is Gemma 4 12B?

Gemma 4 12B is the latest in Google's Gemma family of open language models. But this one is different from its predecessors in a fundamental way.

It's multimodal. It can understand images. It can understand audio. And it can reason about both using natural language — all within a single model that fits on consumer hardware.

Google describes it as a model designed to "bring agentic multimodal intelligence directly to laptops." That's marketing speak, but the substance behind it is real.

Here's the quick summary:

Parameters: 12 billion
Modalities: Text, vision (images), audio
Minimum hardware: 16GB RAM or VRAM
License: Apache 2.0 (fully open source)
Release date: June 3, 2026

The model sits between Google's smaller E4B (designed for edge devices) and their larger 26B Mixture of Experts model. But here's the kicker: Gemma 4 12B performs nearly as well as the 26B model on standard benchmarks, while using less than half the memory.

The Big Innovation: No Encoders

Most multimodal AI models work like this: you have separate components that handle different types of input. A vision encoder processes images. An audio encoder processes sound. Then those encoders feed their outputs into the main language model.

This approach works, but it has problems. Those extra encoders add latency. They increase memory usage. They make the system more complex and harder to optimize.

Gemma 4 12B throws out the encoders entirely.

Instead, vision and audio inputs flow directly into the language model backbone. For vision, Google replaced the traditional vision encoder with what they call a "lightweight embedding module" — essentially a single matrix multiplication, positional embeddings, and normalizations. The main language model handles the rest.

For audio, the approach is similar. Audio tokens go straight into the transformer with no separate processing pipeline.

The result is a unified architecture that's simpler, faster, and uses less memory than traditional multimodal designs.

Why 16GB RAM Changes Everything

This is the part that should make every developer pay attention.

You can run a state-of-the-art multimodal AI on your laptop.

Not a toy model. Not a heavily quantized approximation. A 12-billion parameter model that handles images, audio, and text with performance approaching Google's much larger 26B MoE model.

With 16GB of RAM — which most modern laptops ship with — you can run Gemma 4 12B locally. No cloud GPU. No API costs. No latency from network round trips.

Think about what that enables:

Privacy-first AI assistants that process sensitive documents without sending data to the cloud
Offline-capable applications that work in airplanes, rural areas, or secure facilities
Real-time processing without API rate limits or queuing
Embedded systems that need to understand both images and speech

The model also ships with Multi-Token Prediction (MTP) drafters built in. This technique allows the model to generate multiple tokens at once instead of one at a time, significantly reducing inference latency. It's like going from a single-lane road to a multi-lane highway for token generation.

The Numbers Behind the Claims

Google published benchmark results comparing Gemma 4 12B against other models. Here's what stands out:

Performance vs. 26B MoE: Gemma 4 12B scores within striking distance of Google's own 26B Mixture of Experts model on standard benchmarks. That's a model with more than twice the parameters.

Memory efficiency: At roughly 12B parameters, the model needs significantly less memory than the 26B MoE while delivering comparable results. For developers, this means lower infrastructure costs and broader hardware compatibility.

Download scale: The Gemma 4 family has now crossed 150 million downloads from the developer community. That's not just enterprise adoption — it's indie developers, researchers, hobbyists, and students worldwide.

Real-world projects built on Gemma include wearable robotic arms for physical assistance and enterprise-grade AI security systems. The open model approach is clearly working.

What This Means for the AI Industry

Google's strategy with Gemma 4 is clear: democratize multimodal AI by making it run everywhere.

For months, the narrative has been that powerful AI requires massive cloud infrastructure. OpenAI, Anthropic, and others have pushed users toward API-based access, where you pay per token and send your data to their servers.

Google is pushing back. By releasing a 12B model that handles three modalities under an open license, they're saying: you don't need our cloud. Run it yourself.

This matters for several reasons:

Competition: It puts pressure on closed-source providers. If a free model runs locally with comparable performance, why pay per API call?
Innovation: Open models enable research and experimentation that locked-down APIs can't. Anyone can fine-tune, modify, and build on Gemma 4 12B.
Trust: Running AI locally means your data never leaves your machine. For healthcare, finance, legal, and government applications, this isn't a nice-to-have — it's a requirement.
Cost: API costs add up fast. For startups and small companies, a free local model eliminates a major expense line.

How to Get Started

Getting up and running with Gemma 4 12B is straightforward. Here's the quick path:

Step 1: Install the dependencies. You'll need Python 3.10 or later, and a framework like Hugging Face Transformers or Google's own serving tools. If you're using a Mac with Apple Silicon, you can also run it through llama.cpp or MLX.

Step 2: Download the model. Head to the Hugging Face model page and pull the weights. The full 12B model is around 24GB on disk (model weights plus config files). You'll want a stable internet connection for this one.

Step 3: Load and run. With the model loaded, you can start processing images, audio, and text immediately. The Hugging Face API makes this a few lines of Python:

from transformers import AutoProcessor, GemmaForConditionalGeneration

model = GemmaForConditionalGeneration.from_pretrained("google/gemma-4-12b")
processor = AutoProcessor.from_pretrained("google/gemma-4-12b")

From there, you can pass images, audio files, or plain text to the model and get multimodal responses back.

For production use, consider using vLLM or TGI for optimized inference. These serving frameworks are optimized for Gemma models and can significantly improve throughput and latency on your hardware.

Real-World Use Cases

Where does a model like Gemma 4 12B actually shine? Here are the scenarios where it makes the most impact:

Document Processing: Companies handling invoices, contracts, or medical records can process these locally without exposing sensitive data to third-party APIs. The model reads images of documents and extracts structured information using natural language.

Accessibility Tools: A laptop running Gemma 4 12B could serve as a real-time assistant for visually impaired users — describing what the camera sees, reading text from signs, or narrating the contents of screenshots.

Education: Students and researchers can experiment with state-of-the-art multimodal AI without needing cloud credits or institutional access. This levels the playing field for AI education worldwide.

IoT and Edge Computing: While the 12B model is too large for tiny embedded devices, it runs well on edge servers, Raspberry Pi 5-class devices with sufficient RAM, and industrial equipment. Manufacturers could build smart cameras, voice assistants, and quality control systems that process data locally.

Development and Prototyping: For developers building AI-powered apps, Gemma 4 12B is a free sandbox. Test ideas, iterate on prompts, and build proofs of concept without worrying about API bills.

The Catch (There's Always One)

No model is perfect, and Gemma 4 12B has limitations worth noting.

12B parameters is still smaller than frontier models. While the benchmarks are impressive, don't expect it to match GPT-4-class performance on every task. Complex reasoning, nuanced coding challenges, and edge cases will still favor larger models.

Local inference requires capable hardware. While 16GB RAM is the minimum, you'll want a modern CPU or GPU for acceptable speed. Older laptops may struggle with real-time audio processing.

Apache 2.0 doesn't mean no restrictions. Google's license is genuinely permissive, but responsible use guidelines still apply. The model comes with built-in safety features, and developers should test thoroughly before deploying in production.

My Take

This is a significant release, and not just because of the model itself.

Google is playing a different game than its competitors. While OpenAI and Anthropic focus on building the most capable cloud models, Google is investing heavily in making AI accessible at the edge. Gemma 4 12B is a statement: the future of AI isn't just in data centers. It's on your laptop, your phone, and your embedded devices.

The unified encoder-free architecture is technically impressive. It simplifies the multimodal pipeline in a way that should become the standard. Other model developers will likely follow this approach.

But the real impact is cultural. Every time Google releases a model this capable under an open license, it shifts the conversation from "which API should I use?" to "why am I paying for an API at all?"

For developers, the message is clear: download Gemma 4 12B, experiment with it, and start building. The barrier to multimodal AI just dropped to zero.

Gemma 4 12B is available now on Hugging Face and through Google's official channels. Apache 2.0 licensed. Runs on 16GB RAM. No API key required.

What do you think — will local multimodal AI change how you build? Drop your thoughts in the comments.

Elixir v1.20 Just Dropped — And It Changed Everything

Md Jamilur Rahman — Sun, 14 Jun 2026 08:09:59 +0000

Elixir v1.20 Just Dropped — And It Changed Everything

The 4-year bet on types finally paid off.

For years, the Elixir community had one big question hanging over it: when are we getting types?

Today, the answer arrived. Elixir v1.20 is officially released, and it makes Elixir a gradually typed language. No more guessing. No more type annotations required. Your existing code just got smarter — for free.

Let's break down what this means and why it matters.

The Backstory

Elixir was created by José Valim, the same person who announced this release. The language launched in 2012 on the Erlang VM. For over a decade, Elixir stayed dynamically typed. No int, no string, no type signatures — just pattern matching and runtime checks.

That changed in 2022, when the Elixir team publicly announced their effort to add set-theoretic types to the language. A year later, in June 2023, they published an award-winning paper on the type system's design. The work transitioned "from research to development."

Fast forward to June 3, 2026: the first milestone is complete.

What v1.20 Actually Does

Here's the core idea:

Every Elixir program is now automatically type checked.

Not partially. Not with opt-in annotations. Every line of code you write gets analyzed. If the compiler finds a bug that is guaranteed to fail at runtime, it tells you. These are called "verified bugs" — they aren't warnings or suggestions. They're certainties.

And it works without any type annotations. You don't have to add @spec or @type to your functions. The compiler figures out the types on its own.

How It Passes the "If T" Benchmark

The team submitted Elixir's type system to the "If T: Benchmark for Type Narrowing", a standardized test for how well type systems can figure out the shape of values as your code runs.

Elixir passes 12 out of 13 categories.

For comparison, many established typed languages struggle with this benchmark. Elixir's type system can recover precise type information from ordinary, dynamically-written code — no annotations needed.

A Real Code Example

Let's see what a verified bug looks like. Here's a function that returns either a number or a string:

def percentage_or_error(value) when is_integer(value) do
  value_or_error =
    if value > 1 do
      value
    else
      "not well"
    end

  if value > 1 do
    value_or_error / 100
  else
    String.upcase(value_or_error)
  end
end

In a traditional typed language, this would trigger two false positives. The / operator expects only numbers, and String.upcase expects only strings. The variable value_or_error is both types, so both calls look wrong.

But the program is actually correct! The if checks guarantee that each branch uses the right type.

Elixir's type system handles this elegantly. It tags value_or_error as dynamic(integer() or binary()). When the types overlap with what's accepted, no violation is reported. Zero false positives.

Now imagine someone accidentally writes:

String.upcase(value_or_error)

without the if guard. The type checker knows integer() and String.upcase are disjoint — they share nothing. It flags a verified bug. This will fail at runtime, guaranteed.

That's the sweet spot: catch the real bugs, stay silent on the valid code.

Why `dynamic()` Is the Secret Weapon

Most gradual typed languages use an any() type. It basically says "I give up, anything goes." You turn off the type checker in those spots. Not great.

Elixir does something different. Its gradual type is called dynamic(). It has two key properties:

1. Compatibility

When you have a value of type dynamic(integer() or binary()), the type checker doesn't panic. It knows this value could be either type at runtime. So it only flags a violation if the types are completely disjoint — meaning there's zero overlap.

Example: You have a variable that might be a number or a string. You use it with / (which only takes numbers). If the variable could be a number at runtime, Elixir stays quiet. No false positive. But if you pass it to Kernel.halt() (which takes atoms), Elixir flags it — because numbers and atoms have no overlap.

2. Narrowing

This is the clever part. When you use if, case, or pattern matching on a dynamic() type, Elixir narrows the type. After an if value > 1 check, the variable is now known to be integer(). No false positives downstream.

This means your code gets more precise the more you branch. The type system follows your logic.

Binary Decision Diagrams Under the Hood

Here's a fun technical detail. Elixir's set-theoretic types are implemented using Binary Decision Diagrams (BDDs) — a data structure from computer science that efficiently represents Boolean functions. Types like integer() or binary() are encoded as BDD nodes, and set operations (unions, intersections, negations) become graph operations.

The team published multiple blog posts in 2025 about optimizing these BDDs. They used techniques called "Lazy BDDs with Eager Literal Intersections" and "Lazy BDDs with Eager Literal Differences" to make the type checker fast enough for real-world use.

This matters because type checking a large codebase needs to be fast. No one will use a type system that adds 30 seconds to every compile. The BDD optimizations keep Elixir's compile times reasonable.

Why Not Just Use a Type Annotation System?

You might wonder: why not just copy TypeScript's approach and require type annotations?

Elixir's team considered this. Their argument:

Annotations are overhead. Requiring @spec for every function slows down development. Many Elixir developers value the language's dynamic feel.
Most existing code has no annotations. If the type system only works with annotations, it's useless for legacy codebases. Elixir has thousands of packages with zero type specs.
Gradual typing bridges the gap. The dynamic() type lets you mix typed and untyped code seamlessly. You can add annotations later, at your own pace.

This approach means the type system works today — not after everyone rewrites their code.

What Makes It Different from Other Typed Languages

Feature	Elixir	TypeScript	Python (mypy)
Annotations required?	No	Yes (mostly)	Yes
Gradual by design?	Yes (`dynamic()`)	Yes (`any`)	Yes (`Any`)
False positive control	Disjoint check	Inferred	Strict mode
Verified bugs	Yes	No	No
Underlying model	Set-theoretic (unions, intersections, negations)	Structural	Nominal

The big difference: Elixir's type system uses set-theoretic types. Types are built from unions, intersections, and negations — like sets in math. This makes the model both powerful and composable.

Who's Paying for This?

The type system was built through a partnership between:

CNRS (French National Centre for Scientific Research) — academic muscle
Remote (a global HR company) — real-world use cases

Current development is sponsored by:

Fresha (beauty industry platform)
Tidewave (a new Elixir-focused company)

This is one of the most significant open-source type system efforts funded by actual companies using the language in production.

The Journey: 4 Years from Idea to Release

Year	Milestone
2022	Set-theoretic types announced
2023	Award-winning paper published; transition to development
2024	Type checking of function calls, LSP listeners, built-in JSON
2025	Type checking of protocols, anonymous functions; 4x faster compilation
2026	Full gradual type inference on all programs

Each release added more capabilities. v1.18 checked function calls. v1.19 checked protocols. v1.20 checks everything.

What Other Languages Can Learn

TypeScript made gradual typing mainstream. Python followed with mypy and Pyright. Ruby has Sorbet. Go is slowly adding types.

But most of these bolted types onto existing languages with minimal redesign. Elixir took a different path: four years of academic research before writing a single line of production code.

The result is a type system that feels native to the language. It doesn't fight Elixir's dynamic nature. It works with pattern matching, guards, and the Erlang VM's process model.

Other language teams should study this approach. Types aren't just about adding annotations. They're about understanding your language's semantics deeply enough to make the type system fit.

What This Means for Elixir Developers

For existing codebases

Zero changes needed. The compiler now type checks your code automatically. You'll start seeing warnings about dead code and verified bugs you didn't know about.

For new projects

You get the flexibility of a dynamic language with the safety of a typed one. Pattern match on types without writing type specs. The compiler catches your mistakes.

For the ecosystem

Library authors can start adding @spec annotations to their public APIs. This doesn't change behavior — it just makes the type checker more precise.

The Bigger Picture

This is a huge deal for the Erlang VM ecosystem.

Erlang has always been about "let it crash" — fault tolerance through process isolation, not type safety. Adding types to Elixir doesn't replace that philosophy. It complements it. You get:

Process-level fault tolerance (from Erlang)
Compile-time bug detection (from the new type system)
Zero annotation overhead (from gradual typing)

This is exactly what José Valim described in his 2023 paper: types that are sound (they mean what they say), gradual (you can opt in over time), and developer friendly (clear errors, no noise).

The HN Reaction

The release hit Hacker News with 300 points and 90 comments within hours. The community reaction was overwhelmingly positive:

Many developers shared stories of bugs that would have been caught by the new type system
Questions about IDE support and editor integration came up frequently
Some wondered if this would finally push Elixir into mainstream adoption
Others asked about performance impact — the team confirmed compile times stay fast

The top comment summed it up: "Elixir's team did types the right way. Research first, implementation second."

My Take

This is one of the most thoughtfully executed type system rollouts I've seen.

Most languages bolt on types and immediately break half the ecosystem. Elixir's approach — four years of research, careful dynamic() semantics, verified bugs instead of fuzzy warnings — shows they learned from everyone else's mistakes.

The fact that it passes 12/13 categories on the "If T" benchmark on day one is remarkable. That's not a toy type system. That's production-grade inference.

If you've been on the fence about Elixir, this release is the sign you were waiting for.

What Comes Next

The Elixir team isn't done. Their roadmap includes:

More precise type inference — catching even more bugs without annotations
Better error messages — pointing you to exactly what went wrong and how to fix it
IDE integration — autocomplete, go-to-definition, inline type info
Optional type annotations — when you want to be more explicit about your API's contract

The v1.20 release is the foundation. The next releases will build on it.

If you're an Elixir developer, now is the time to update. Run mix deps.update --all and see what the type checker finds. You might be surprised.

If you're not an Elixir developer, this release is worth watching. Elixir just became one of the most type-safe dynamic languages in existence. That's a big claim, and they've got the benchmarks to back it up.

Elixir v1.20 is available now. Install it with asdf, mise, or from the official download page.

Written June 3, 2026.

DaVinci Resolve 21 Just Dropped — And the Free Version Is Absurd

Md Jamilur Rahman — Sun, 14 Jun 2026 08:09:56 +0000

DaVinci Resolve 21 Just Dropped — And the Free Version Is Absurd

Blackmagic Design released DaVinci Resolve 21 this week. If you do any kind of video editing, color grading, or audio post-production, you need to know about this. Not because of the AI features (though those are wild), but because of what the free version now includes.

I've been using Resolve for about five years. Started with the free version, eventually bought the Studio license. It was the best $295 I ever spent on software. And version 21 just made it even better.

Hacker News agreed — the announcement hit 328 points with 151 comments. The community is buzzing, and for once, the hype seems justified.

What's Actually New

The headline feature is the Photo page. Blackmagic basically added Lightroom into Resolve. You can now manage and edit still photos alongside your video projects. It uses the same color science that Hollywood colorists rely on — and it's in the free version.

For photographers who also shoot video, this is a big deal. One app for both workflows. No more juggling between Lightroom and your NLE. The Photo page supports RAW files from major camera manufacturers, and you get the full suite of color grading tools that Resolve is famous for.

One HN commenter put it bluntly: "It may be the best photo management/editor on Linux. Yes, I know about darktable and rawtherapee and I stand by what I said." That's high praise from a community that doesn't hand it out easily.

But the AI stuff is what everyone's talking about.

The AI Tools Are Genuinely Useful

Blackmagic added a whole suite of AI-powered tools. Some of them are practical, some are flashy. Here's what stood out to me:

AI IntelliSearch lets you search through your media by content. Type "person in red jacket" or "car" and it finds matching clips. You can even search for specific faces. This saves serious time when you're working with hours of footage. Instead of scrubbing through timelines, you describe what you're looking for and it finds it.

AI Speech Generator creates voiceovers from text. You can use Blackmagic's voice models or train it on your own voice. They claim it needs just 10 seconds of audio to create a unique voice. You can adjust speed, pitch, and inflection. I haven't tested this extensively yet, but the demos look promising. For quick narration or placeholder dialogue, this could eliminate the need for a recording setup entirely.

AI CineFocus is the one I'm most excited about. You click on a focal point in a shot and adjust the depth of field after the fact. You can even keyframe it to rack focus. This could save shots that were slightly out of focus — or create focus pulls you didn't get on set. The tool lets you select aperture shape and add optical effects like bokeh. It's not going to replace a good DP, but it's a powerful safety net.

AI Face Age Transformer does exactly what it sounds like. Analyze a face, set an age, and adjust the offset slider. Useful for flashbacks or continuity issues. The results I've seen look decent, not perfect, but better than I expected. You can add or remove wrinkles, adjust facial fullness, and maintain consistency across scenes.

AI Face Reshaper lets you modify facial features on a moving subject. After detecting and tracking a face, you can adjust eyes, nose, mouth, eyebrows, and overall face shape. Manual controls let you fine-tune the results. This is the kind of tool that would have cost thousands in VFX work just a few years ago.

AI Blemish Removal cleans up skin while keeping natural texture. There's a strength slider so you can dial it in. Nothing revolutionary here, but having it built into the color page is convenient. No more bouncing between apps for basic retouching.

AI Slate ID reads clapperboard details automatically. It extracts metadata from the slate in the frame, even in dark or blurry shots. If you've ever spent hours entering metadata manually, you know why this matters. This is the kind of unsexy feature that saves real time on real projects.

The Non-AI Stuff Is Just as Important

Here's the thing: even without the AI features, this is a massive update.

Fusion got 70+ new graphics through the Krokodove toolset. From what I've seen in the beta, these are enough to replace basic After Effects work. And Fusion is in the free version. Motion graphics artists on a budget should take a serious look.

Fairlight added a folder function for audio track management. If you're working with complex audio sessions, this makes navigation much easier. It's a small change, but anyone who's scrolled through 50+ tracks knows how much this matters.

Edit and Cut pages have improved keyframing and better graphic format support. Small quality-of-life improvements that add up over time.

Color page got MultiMaster trim passes, layer list node graphs, and group versions. These are professional-grade features that used to require expensive third-party tools or convoluted workarounds.

And there's increased support for immersive and VR workflows. If you're doing spatial video for Apple Vision Pro or similar, Resolve 21 has you covered. The VR tools include support for stereoscopic 3D and 360-degree footage.

The Pricing Model Is Still the Best in the Industry

Let's talk about money. DaVinci Resolve has a free version that's genuinely useful. Not a trial, not a limited demo — a full-featured editor that professional colorists actually use.

The Studio version costs $295. One time. No subscription. And that license works on two computers simultaneously, even across different operating systems. Buy it once, use it forever, including all future major version upgrades.

One HN commenter put it well: "I spent less than $300 on it a decade ago and my licence works fine on new v21 released this week. My least-regretted software purchase in 3 decades."

Compare that to Adobe Premiere at $22.99/month ($689.73 over three years) or Final Cut Pro at $299.99 (Mac only). Resolve's pricing is hard to beat.

The AI features and 4K+ editing are locked to Studio, but the free version still gives you professional editing, color grading, Fusion VFX, and Fairlight audio. For most individual creators, that's more than enough. The free version doesn't even add watermarks — it's the full software with some features disabled.

What I Think About the AI Direction

I have mixed feelings about AI in creative tools. On one hand, tools like CineFocus and Slate ID solve real problems. They save time on tedious tasks so you can focus on the creative work.

On the other hand, the Face Age Transformer and Face Reshaper make me uneasy. We're getting better at manipulating faces in video, and the ethical implications aren't great. Deepfakes are already a problem. Tools like these make them easier to create.

Blackmagic seems aware of this. The tools are positioned as professional utilities, not consumer playthings. But once software is out there, people will use it however they want.

The AI Speech Generator is another one. It's impressive technically, but voice cloning raises serious questions about consent and authenticity. If someone can clone your voice from 10 seconds of audio, what does that mean for trust in media?

I don't have answers. But I think it's worth thinking about. The technology isn't going away — the question is how we use it and what guardrails we put in place.

Should You Upgrade?

If you're already using Resolve, absolutely. The free version alone is worth downloading. The Photo page and Fusion improvements are reason enough.

If you're on Premiere or Final Cut, this is a good time to try Resolve. The learning curve is real — especially for the color page — but the payoff is worth it. And you can't beat the price. There are tons of free tutorials on YouTube, and Blackmagic's own training resources are excellent.

If you're a photographer who also shoots video, the Photo page might be the thing that finally convinces you to switch. One app for both workflows, with Hollywood-grade color science.

The Studio license is worth it if you need 4K+, the AI features, or multi-user collaboration. At $295 one time, it pays for itself quickly if you're doing client work.

The Bottom Line

DaVinci Resolve 21 is the biggest release Blackmagic has done in years. The AI tools are genuinely useful (if a bit ethically complicated). The Photo page fills a major gap. And the free version keeps getting more powerful.

In a world where every creative tool is moving to subscriptions, Blackmagic's one-time purchase model feels almost rebellious. I hope they keep it up.

Version 21 is available now for download from Blackmagic's website. The free version and Studio ($295) are both available immediately.

What do you think about AI tools in creative software? Are they helping or hurting? I'd genuinely like to know.

DEV Community: Md Jamilur Rahman

Blinkist Just Admitted AI Narration Failed. That Should Worry Every AI Optimist.

What Blinkist Actually Said

Why This Matters Beyond Blinkist

The "Good Enough" Trap

The Broader Pattern: AI as Tool, Not Replacement

What This Means for Developers and Product Builders

The Real AI Divide

Jetpack Compose Just Got Styles, Grid, and CSS-Like Media Queries

Compose Is Now the Standard

The Big Three: Styles, Grid, MediaQuery

Styles API

Grid — A 2D Layout System

MediaQuery — Declarative Environment Queries

FlexBox

Performance Improvements

TikTok's Case Study: 58% Less Code

Testing v2: The Breaking Change Nobody's Talking About

Adaptive Layouts and TV Support

What's Next

Open Source Maintainers Are Quitting Because of AI

The "Reverse Centaur" Problem

The Scale of the Problem

Why This Matters Beyond Open Source

The Economics of AI-Assisted Contributions

What Maintainers Are Doing About It

The Bigger Question

Uber's $1,500/Month AI Limit Tells You Everything About Where Coding Tools Are Headed

Uber's $1,500/Month AI Limit Tells You Everything About Where Coding Tools Are Headed

What happened

The math

Why $1,500 is the number that matters

The bigger picture

What this means for you

My take

Google Just Released a Multimodal AI That Runs on Your Laptop — And It's Free

Google Just Released a Multimodal AI That Runs on Your Laptop — And It's Free

What Is Gemma 4 12B?

The Big Innovation: No Encoders

Why 16GB RAM Changes Everything

The Numbers Behind the Claims

What This Means for the AI Industry

How to Get Started

Real-World Use Cases

The Catch (There's Always One)

My Take

Elixir v1.20 Just Dropped — And It Changed Everything

Elixir v1.20 Just Dropped — And It Changed Everything

The Backstory

What v1.20 Actually Does

How It Passes the "If T" Benchmark

A Real Code Example

Why dynamic() Is the Secret Weapon

1. Compatibility

2. Narrowing

Binary Decision Diagrams Under the Hood

Why Not Just Use a Type Annotation System?

What Makes It Different from Other Typed Languages

Who's Paying for This?

The Journey: 4 Years from Idea to Release

What Other Languages Can Learn

What This Means for Elixir Developers

For existing codebases

For new projects

For the ecosystem

The Bigger Picture

The HN Reaction

My Take

What Comes Next

DaVinci Resolve 21 Just Dropped — And the Free Version Is Absurd

DaVinci Resolve 21 Just Dropped — And the Free Version Is Absurd

What's Actually New

The AI Tools Are Genuinely Useful

The Non-AI Stuff Is Just as Important

The Pricing Model Is Still the Best in the Industry

What I Think About the AI Direction

Should You Upgrade?

The Bottom Line

Why `dynamic()` Is the Secret Weapon