This is Part 15, the final article of a 15-part Apache Iceberg Masterclass. Part 14 covered hands-on Dremio Cloud. This article covers the three migration strategies and how to execute a zero-downtime migration using the view swap pattern.

Most organizations do not start with Iceberg. They have years of data in Hive tables, data warehouses, CSV files, databases, and Parquet directories. Moving this data to Iceberg is not an all-or-nothing project. The best migrations happen incrementally, one dataset at a time, with no disruption to existing consumers.

Table of Contents

1. What Are Table Formats and Why Were They Needed?
2. The Metadata Structure of Current Table Formats
3. Performance and Apache Iceberg’s Metadata
4. Technical Deep Dive on Partition Evolution
5. Technical Deep Dive on Hidden Partitioning
6. Writing to an Apache Iceberg Table
7. What Are Lakehouse Catalogs?
8. Embedded Catalogs: S3 Tables and MinIO AI Stor
9. How Iceberg Table Storage Degrades Over Time
10. Maintaining Apache Iceberg Tables
11. Apache Iceberg Metadata Tables
12. Using Iceberg with Python and MPP Engines
13. Streaming Data into Apache Iceberg Tables
14. Hands-On with Iceberg Using Dremio Cloud
15. Migrating to Apache Iceberg

Three Migration Strategies

1. In-Place Migration (Metadata Only)

In-place migration creates Iceberg metadata over existing Parquet or ORC files without copying or moving them. The data files stay exactly where they are; only new Iceberg metadata is created to track them.

Spark example:

CALL system.migrate('db.existing_hive_table')

This converts a Hive table to Iceberg by scanning its files and creating the Iceberg metadata tree (metadata.json, manifest list, manifest files) that references them. The Parquet files are untouched.

Pros: Fast. No data movement. The table becomes queryable as Iceberg immediately.

Cons: The existing file layout (sizes, partitioning, sort order) is inherited. If the original files are poorly organized, you inherit those problems. Requires the original files to be in Parquet or ORC format.

2. Full Rewrite (CTAS)

A full rewrite reads data from any source and writes it as a new Iceberg table with optimal partitioning and file sizes:

-- Spark
CREATE TABLE iceberg_catalog.analytics.orders
USING iceberg
PARTITIONED BY (day(order_date))
AS SELECT * FROM hive_catalog.legacy.orders

-- Dremio
CREATE TABLE analytics.orders
PARTITION BY (day(order_date))
AS SELECT * FROM legacy_source.public.orders

Pros: Best result. Optimal file sizes, correct sort order, proper partitioning. The table is perfectly organized from day one.

Cons: Requires reading and writing all data, which takes time and compute resources. The source system must be available during the migration.

3. Shadow Migration (Build and Swap)

Shadow migration builds the Iceberg table alongside the existing source, then swaps consumers from old to new when ready:

1. Create a new Iceberg table with the desired schema and partitioning
2. Backfill historical data from the legacy source
3. Set up incremental sync to keep the Iceberg table current
4. Validate data quality between old and new
5. Swap consumer views from legacy to Iceberg

Pros: Zero downtime. Consumers never see a disruption. You can validate the migration before committing to it.

Cons: Temporarily doubles storage costs. Requires maintaining two copies during the transition.

Choosing the Right Strategy

The View Swap Pattern

The view swap pattern is the recommended approach for production migrations. It uses Dremio’s semantic layer to create an abstraction between consumers and the underlying data:

Phase 1: Federation

Create views in Dremio that point to the legacy data source:

CREATE VIEW analytics.orders AS
SELECT order_id, customer_id, order_date, amount, status, region
FROM postgres_source.public.orders

All consumers (dashboards, reports, notebooks) query through these views. They do not know or care where the data physically lives.

Phase 2: Build Iceberg

Create and populate the Iceberg table:

-- Create the Iceberg table
CREATE TABLE iceberg_data.analytics.orders (
    order_id BIGINT, customer_id BIGINT,
    order_date DATE, amount DECIMAL(10,2),
    status VARCHAR, region VARCHAR
) PARTITION BY (day(order_date))

-- Backfill from the legacy source
INSERT INTO iceberg_data.analytics.orders
SELECT * FROM postgres_source.public.orders

Phase 3: Validate

Compare the two datasets to confirm data integrity:

SELECT
  (SELECT COUNT(*) FROM postgres_source.public.orders) AS legacy_count,
  (SELECT COUNT(*) FROM iceberg_data.analytics.orders) AS iceberg_count

Beyond row counts, validate aggregates (total amounts, distinct customer counts) and spot-check individual records. A comprehensive validation script should compare:

• Total row count
• Column-level checksums or hash aggregates
• Distinct value counts for key columns
• Boundary values (MIN/MAX) for numeric and date columns
• Sample of specific records matched by primary key

Only proceed to the swap after all validation checks pass.

Phase 4: Swap

Update the view to point to the Iceberg table:

CREATE OR REPLACE VIEW analytics.orders AS
SELECT order_id, customer_id, order_date, amount, status, region
FROM iceberg_data.analytics.orders

Consumers notice nothing. The view name is the same. The query interface is the same. But now the data is served from Iceberg with all of its advantages: time travel, hidden partitioning, metadata-driven pruning, and automatic optimization.

Migrating One Table at a Time

The view swap pattern enables incremental migration. You do not need to migrate everything at once:

1. Week 1: Migrate the highest-value table (e.g., orders)
2. Week 2: Migrate the next table (e.g., customers)
3. Continue until all critical tables are on Iceberg

During the transition, Dremio’s federation queries legacy and Iceberg tables together. A join between a PostgreSQL table and an Iceberg table works the same as a join between two Iceberg tables. The migration is invisible to consumers.

Post-Migration Checklist

After migrating each table:

• Run OPTIMIZE TABLE to ensure optimal file sizes
• Set up automatic optimization through Dremio Open Catalog
• Add wikis and tags for the AI agent
• Verify metadata table health checks
• Decommission the legacy source after the retention period

Common Migration Pitfalls

Migrating without testing query performance: Always benchmark critical queries against the new Iceberg table before switching production traffic. Iceberg’s partition layout and file organization affect performance, and a migration can make some queries faster but others slower if the partition strategy is wrong.

Skipping the validation phase: Data discrepancies between the old and new systems are more common than expected. Schema differences, timezone handling, null semantics, and data type precision can all cause subtle mismatches. Validate thoroughly.

Migrating everything at once: Large “big bang” migrations carry high risk. If something goes wrong, rolling back is complex and time-consuming. Migrate one table at a time, validate each one, and build confidence incrementally.

This completes the Apache Iceberg Masterclass. The series covered table formats, metadata, performance, partitioning, writes, catalogs, maintenance, tooling, and migration. For hands-on practice, start a Dremio Cloud trial and follow the workflow in Part 14.

Books to Go Deeper

• Architecting the Apache Iceberg Lakehouse by Alex Merced (Manning)
• Lakehouses with Apache Iceberg: Agentic Hands-on by Alex Merced
• Constructing Context: Semantics, Agents, and Embeddings by Alex Merced
• Apache Iceberg & Agentic AI: Connecting Structured Data by Alex Merced
• Open Source Lakehouse: Architecting Analytical Systems by Alex Merced

Free Resources

• FREE – Apache Iceberg: The Definitive Guide
• FREE – Apache Polaris: The Definitive Guide
• FREE – Agentic AI for Dummies
• FREE – Leverage Federation, The Semantic Layer and the Lakehouse for Agentic AI
• FREE with Survey – Understanding and Getting Hands-on with Apache Iceberg in 100 Pages

Hi everyone! Today I want to share practical experience in integrating machine learning models into mobile ecosystems. I recently completed the research and development of two MVP applications (on Native Android and Flutter), defended this project at an international conference and now I want to share my integration experience with you.

In this article, we will analyze in detail the difference between local and server AI computing, compare the implementation features of the native layer on Kotlin and the cross-platform layer on Dart, and also analyze non-obvious bugs that you may encounter when working with the camera and file system.

If you are interested in a specific platform, you can skip directly to the relevant section in the navigation below. The source code of both projects is open under the MIT license, links to repositories (GitHub/GitLab) can be found below.

Navigation:

• Analysis of approaches (On-Device / On-Server)
• Implementation on Native Android (Kotlin)
• Implementation in Flutter (Dart)
• Conclusions and links to projects

Part 1. On-Device vs On-Server: Architectural Choice

Выбор места деплоя мобильной модели — это всегда компромисс между ресурсами устройства, точностью вычислений и требованиями к безопасности.

Local approach (On-Device)

The model is deployed directly in the application sandbox and carries out inference (inference) locally, using the computing power of the CPU, GPU or specialized neural processors (NPU/TPU) of the smartphone. As an On-Device solution, I used Google ML Kit (Image Labeling SDK).

Pros:

• Minimum ping (Latency): There are no network delays for the transmission of heavy media data.
• Autonomy: Complete independence from the availability and quality of the Internet connection.
• Confidentiality (Data Privacy): User data does not leave the device and is not transferred to third parties.

Cons:

• Resource limitation: To prevent the application from burning out the battery and taking up gigabytes of memory, models are heavily quantized and cut down.
• Reduced accuracy: Due to compression, the accuracy of lightweight models decreases (on average, the upper threshold of accuracy in basic classification tasks is about 61-65%)

Server approach (On-Server)

The model lives on a remote server and is accessible via the API. In my research, I used the Hugging Face Inference API (model google/vit-base-patch16-224).

Pros:

• High accuracy: You can deploy heavy State-of-the-Art (SOTA) models, LLMs, or huge ensembles of neural networks with a colossal class base on the server.
• Client unloading: The smartphone only fulfills the network request, does not heat up and does not waste power on complex mathematical calculations.

Cons:

• Network dependence: No Internet – no AI.
• Infrastructure and security costs: It is necessary to provide encryption of communication channels (TLS/SSL), protect API keys from reverse engineering and pay for server capacity

Part 2. Native implementation: Android

In a native application, the key task is to isolate heavy operations from the main interface thread (Main Thread) to avoid UI friezes and Application Not Responding (ANR) errors.

Working with API (On-Server)

To send POST requests (transmitting an image byte array), a combination of OkHTTP and Retrofit was used. Conversion of the server’s JSON response into strictly typed Kotlin data classes occurs automatically thanks to converters. The network call is encapsulated in a suspend function, which allows declarative control of asynchrony.

private const val TOKEN = "..."

data class PredictionResponse(val label: String, val score: Float)

interface HuggingFaceApi {

    @POST
    suspend fun postImage(
        @Url url: String,
        @Header("Authorization") token: String,
        @Body body: RequestBody
    ): List<PredictionResponse>
}
class ApiModel(){
    private val retrofit = Retrofit.Builder()
        .baseUrl("https://router.huggingface.co/hf-inference/")
        .addConverterFactory(GsonConverterFactory.create())
        .build()

    val service: HuggingFaceApi = retrofit.create(HuggingFaceApi::class.java)

     suspend fun classifyImage(imageBitmap: Bitmap): Pair<String, Float>{
        return try {
            val imageToButeArray = compressBitmap((imageBitmap))
            val requestBody = imageToButeArray.toRequestBody("image/jpeg".toMediaTypeOrNull())

            val result = service.postImage(
                "models/google/vit-base-patch16-224",
                "Bearer $token",
                requestBody
            )
            val firstLabel = result.firstOrNull()
                ?: return "Не распознано" to 0f

            firstLabel.label to firstLabel.score



        }catch (e: Exception){
            Log.e("network", "Request failed", e)
            "Oшибка сервера" to 0f

        }
    }

}

Please note that before sending the image to the server we compress it and that we do not send too many bytes over the network

suspend fun compressBitmap(bitmap: Bitmap): ByteArray = withContext(Dispatchers.IO) {

    val stream = ByteArrayOutputStream()

    bitmap.compress(
        Bitmap.CompressFormat.JPEG,
        80,
        stream
    )

     stream.toByteArray()
}

Local inference (On-Device via ML Kit)

To work with the local ML Kit model, the library is configured via ImageLabelerOptions. We explicitly set setConfidenceThreshold(0.4f) – the model’s confidence threshold. By increasing this threshold, we cut off false positives, but force the algorithm to work more intensively.

To ensure stability and save RAM, the labeler object is initialized through the Kotlin delegate mechanism (by lazy):

private val labeler by lazy {
    val options = ImageLabelerOptions.Builder()
        .setConfidenceThreshold(0.4f)
        .build()
    ImageLabeling.getClient(options)
}

Why is by lazy here?

1. Saving resources: An instance of the heavy ML Kit client is created not when the Activity is launched, but strictly at the time of the first request (when the user takes a photo).
2. Context safety: Initialization is guaranteed to occur when the applicationContext is already fully formed by the operating system, which prevents NullPointerException from occurring.

The call to labeler.process(image) is asynchronous in nature (runs on Google’s Task API). To make it linear and MVVM-friendly, we wrap it with coroutines and wait for the execution result.

Architectural layer and flow control

In MainViewModel, all calls are wrapped in viewModelScope.launch. Depending on the position of the state switch (On-Device / On-Server), the required method is launched:

private fun classifyImage(bitmap: Bitmap?) {
        if (bitmap == null) return
        _uiState.update {
            it.copy(isLoading = true)
        }
        viewModelScope.launch {
            val startTime = System.currentTimeMillis()

            try {
                val (label, confidence) = if (_uiState.value.isOnDevice) {
                    mlKit.analyze(bitmap!!)
                } else {
                    apiModel.classifyImage(bitmap!!)
                }

                val duration = System.currentTimeMillis() - startTime

                _uiState.update {
                    it.copy(
                        classificationText = label,
                        confidenceValue = confidence,
                        timeTakenDuration = duration,
                        isLoading = false
                    )
                }
            } catch (e: Exception) {
                _uiState.update {
                    it.copy(
                        classificationText = "Ошибка",
                        confidenceValue = 0f,
                        timeTakenDuration = 0L
                    )
                }
            }
        }

Working with the camera on Native Android

On the Native Android side, working with the camera looks concise thanks to the modern SDK CameraX. This is a Lifecycle-aware library: it knows when an Activity is minimized (onPause) or destroyed (onDestroy), and automatically releases camera resources and closes streams (ImageAnalysis / ImageCapture). We do not need to manually write the onDispose logic, and the result of a successful snapshot in the code can be a ready-made Bitmap object held in RAM, which eliminates unnecessary disk read-write operations.

Part 3. Cross-platform implementation: Flutter (Dart, Dio, Method Channels)

The Flutter application conceptually solves the same problems, but faces the specifics of Dart’s single-threaded architecture (Event Loop).

Network Inference (Dio + Futures)

To communicate with Hugging Face on Flutter, we used the Dio package. To prevent a heavy request and network packet processing from blocking the rendering of UI frames (after all, Dart runs on a single thread), we package the call into an asynchronous Future/Await model. While the network is chasing bytes, Event Loop calmly continues to render the interface.

final dio = Dio();

Future<List<dynamic>?> apiModel(String path) async {
  final Uint8List? imageBytes = await compressImage(path);

  if (imageBytes == null) {
    return null;
  }

  try {
    final response = await dio.post(
      "https://router.huggingface.co/hf-inference/models/google/vit-base-patch16-224",
      data: imageBytes,
      options: Options(
        headers: {
          "Authorization": "Bearer 'your_token'", // put your token from hugging face here
          "Content-Type": "image/jpeg",
        },
      ),
    );
    return response.data;


  } on DioException catch (e) {
    debugPrint("Error: $e");

  }
  return null;
}

Please note that before sending the image to the server we compress it and that we do not send too many bytes over the network

Future<Uint8List?> compressImage(String path) async {
  final Uint8List? result = await FlutterImageCompress.compressWithFile(
    path,
    quality: 80,
    format: CompressFormat.jpeg,
  );

  return result;
}

Native bridge: MethodChannel for ML Kit

Since there is no full-fledged direct SDK for ML Kit Image Labeling on Dart that provides the required level of customization, a Production approach is used: creating a MethodChannel (native bridge).

The Dart code acts as a client: it generates the predictOnDevice event and passes the path to the saved photo through the channel.

class NativeMlService {
  static const MethodChannel _channel = MethodChannel("mlkit_photo_analyze");

  static Future<Map> onDeviceMethod(String imagePath) async {
    final result = await _channel.invokeMethod(
      'imageLabeling',
      {'imagePath': imagePath},
    );
    return Map.from(result);
  }
}

On the Android side (MainActivity.kt) we catch this call through setMethodCallHandler. The same rules apply here: we deploy the coroutine on a background thread, process the image via ML Kit, but we transmit the response to result.success() strictly returning to the Main Thread, since the Flutter engine will not be able to accept data from the Android side thread.

 override fun configureFlutterEngine(flutterEngine: FlutterEngine) {
        super.configureFlutterEngine(flutterEngine)

        MethodChannel(flutterEngine.dartExecutor.binaryMessenger, CHANNEL).setMethodCallHandler { call, result ->
            if(call.method == "imageLabeling"){
                val imagePath = call.argument<String>("imagePath")
                if (imagePath == null) {
                    result.error("ArgError", "Image path is null", null)
                    return@setMethodCallHandler
                }
                // Run ML inference on background thread to avoid blocking UI
                CoroutineScope(Dispatchers.IO).launch {
                    try {
                          // image processing and model calling....

                        // Return result on main thread
                        withContext(Dispatchers.Main){
                            result.success(response)
                        }
                    }....
//rest of the code on GitHub/ GitLab....

Camera in Flutter and Data Race (Race Condition)

The most difficult and interesting stage of developing the Flutter version was the integration of the camera plugin and debugging the interaction of file systems. Here two important differences from the native were revealed:

Manual Lifecycle Management: In Flutter, the developer must manually initialize the CameraController, catch available lenses (by selecting CameraLensDirection.back) and, most importantly, be sure to call _controller?.dispose() in the dispose() method of the widget.

If you forget, the camera will remain locked in the operating system, and other applications will not be able to open it.

Ghost File Problem (Race Condition):
The _controller?.takePicture() method in Flutter returns an XFile object that physically stores the snapshot in the device cache directory (image.path). This is where the classic data engineering race comes into play.

When Flutter happily reports that the photo has been taken and passes the path to the native code via MethodChannel, the native part (Kotlin) instantly tries to execute BitmapFactory.decodeFile(imagePath). But at the level of the Android operating system, the file in the cache may still be blocked – the stream of data writing from the camera buffer to the disk has not yet had time to physically close.

This was reflected in the logs as a hard crash:
E/ple.flutter_mvp: FrameInsert open fail: No such file or directory
The native code crashed, Bitmap returned null, and Flutter received an empty null reference instead of a data structure.

We get a similar error when we send a picture to the server because we are practically sending an empty picture

Solution to the problem:
To eliminate this data race, two-way protection was applied:

On the Dart (Provider) side: Before calling the native method/sending to the server, we artificially let the system “breathe out” by adding a micro-delay:

await Future.delayed(const Duration(milliseconds: 200));

This time is enough for the OS to complete disk operations.

Conclusion and conclusions

The conducted MVP study clearly proves: On-Device and On-Server approaches do not compete, but complement each other.

• On-Server is indispensable for heavy computing (LLM, GPT, high-definition video processing).
• On-Device is ideal for utilitarian tasks (scanning documents, recognizing simple objects, working in strict offline conditions).

In modern Production applications, the best practice is a hybrid approach**: fast primary output is done locally, and deep data validation is sent to the backend server.

Regarding the choice of platform: Native Android gives absolute control over resources, hardware and threads out of the box. Flutter, despite the limitations of single-threading Dart, with proper use of MethodChannel, compliance with the rules for dispatching coroutines in the native layer and taking into account file system timings, allows you to create responsive and productive AI applications.

GitHub

GitLab

RatRatatyu / mobile-ai-mvp · GitLab

Two MVP applications demonstrating on-device and on-server AI model integration in Jetpack Compose (Android) and Flutter.

gitlab.com

I would like to note that I am just developing and learning in this direction, so perhaps my conclusions may be inaccurate, or the descriptions may not be entirely correct, so I will be grateful if you point out my mistakes in the comments, and I will also be glad if you put stars in GitHub and GitLab if the projects are useful to you

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

Disclaimer: This is an individual submission for Francis Tran (@francistrdev). Everyone involved has their own accounts of using Gemma 4 and has been paraphrased in this post. See below for the list of people involved.

Author: Francis Tran (@francistrdev)
Featuring: Elmar Chavez (@codingwithjiro), Konark Sharma (@konark_13), and Julien Avezou (@javz)

The cover image uses characters from various Anime chosen by the people who are featured in this post, put together in using Pixlr, and using AI to enhance the quality of the image. Some contents started off using AI and has been paraphrased by the author’s own words.

Table of Contents

• Introduction

• Setting up Gemma 4 using Ollama

  • Installing Ollama and Gemma 4
  • Trying out Gemma 4
  • Running Gemma 4 Offline
  • Elmar’s Verdict on Gemma 4

• Using Gemma 4 as a Confused Developer

  • The Strawberry Test
  • The Tic Tac Toe Rotation Test
  • The Broken Cup Test
  • Konark’s Verdict on Gemma 4

• Building a Prototype using Gemma 4

  • Results of Gemma 4 Vs. GPT 5.4
    • Technical Depth
    • Architecture & System Thinking
  • Julien’s Verdict on Gemma 4

• Using Gemma 4 as an AI-Agent

  • Gemma 4 is Strict
  • Please Google I need this. Gemma 4 is kind of Looping Itself
  • Francis’ Verdict on Gemma 4

• Summary

Thank you for Reading!

Introduction

In the age of AI, many developers are using AI in their workflows. This can range from AI assistants cleaning up a large code-base to developers vibe coding a prototype to showcase to others.

Regardless of your use of AI in your development, it is important to choose the model you want to work with. There are a lot of choices to choose from such as ChatGPT, Gemini, Copilot, etc. The one we are talking about today is Google’s latest model: Gemma 4!

The goal of this article is to share our experiences using Gemma 4 in 4 different perspectives of Development starting from setting up Gemma 4 using Ollama, testing the hallucination of Gemma 4, how Gemma 4 outputs, and using Gemma 4 as an AI-Agent. Additionally, I will share our discoveries and whether we recommend using Gemma 4 based on our experiences! We hope that our experience of using Gemma 4 will help you to decide if Gemma 4 is right for you in any skill level of your developer career!

With that said, we will now talk about the setup process. In any development, we all experience setting up our environment whether it is OpenClaw or a simple NPM package! Having a local LLM is one of them. Here is Elmar’s experience of setting up Gemma 4 using Ollama!

Setting up Gemma 4 using Ollama

Elmar ChavezFollow

Licensed civil engineer turned full stack developer building accessible, responsive web applications. I also review code in Frontend Mentor and participate in collaborative projects.

Elmar has been using ChatGPT for the past year where he mainly uses it as a mentor when doing projects. He was interested having a LLM locally. He believes that having an LLM locally is convenient for his case, due to power outages he has to faced in the Philippines. Having Gemma 4 locally will allow him to be productive when coding without the need to worry about connecting to the internet. With that said, he started to research about setting up Gemma 4 using Ollama.

Installing Ollama and Gemma 4

Elmar started to search on the internet, looking for tutorials on getting started on Gemma 4.

One of the ways to get started is installing Ollama, which Elmar thought was a weird name until he realized the logo was an actual llama.

When downloading Ollama, the main issue is the storage, which was nearing 100% capacity and Ollama installer defaults to the C: drive.

After searching more about installing Ollama without installing on the C: drive, which led to this command he had to run on the terminal:

C:UsersELMAR>cd Downloads
C:UsersELMARDownloads>OllamaSetup.exe /DIR="D:Ollama"

Ultimately, it worked well. He had done other configurations such as redirecting the AI model installation in the same drive under D:OllamaModels. He then downloaded the gemma4:e4b.

Trying out Gemma 4

The first thing Elmar tried was “hi gemma4”. Although the expected outcome is Gemma 4 saying hello back, it gave him this error:

Error
500 Internal Server Error: model requires more system memory (9.8 GiB) than is available (4.9 GiB)

For context, this is his device specifications:

His laptop is great for programming and other developments. The issue is that his laptop is only suitable for “lightweight models” when it comes to downloading LLMs locally.

Elmar discovered that local AI depends heavily on your own hardware, unlike browser-based AI tools like ChatGPT.

One of the things Elmar did was to run a smaller version of Gemma 4:

ollama run gemma4:e2b

It gave him a similar error as before:

Error
500 Internal Server Error: model requires more system memory (7.2 GiB) than is available (5.7 GiB)

After investigating a bit more, he closed other applications that were running on his computer and taking up space and it outputted!

The big thing about running it for the first time is that it took longer than he expected, but he mentioned that he had VSCode, Notepad, and 4 tabs currently opened in his Chrome Browser.

Running Gemma 4 Offline

Elmar was curious about the result of using Gemma 4 without connecting to the internet.

It ran slower than usual, but it is still under a minute.

Elmar then tried to ask questions to Gemma 4 that he would normally ask to ChatGPT as part of his Development workflow.

In this case, he is currently building his website portfolio. Elmar asked a question along with attaching a screenshot to Gemma 4 and here is what it output:

Surprisingly, it took less time considering the fact that he inserted an image for this use case.

The wait time for the LLM to respond, which is around a minute, is reasonable for Elmar since he has a decent laptop. It is quite useful especially for countries that commonly have power outages or that have unreliable internet.

Elmar’s Verdict on Gemma 4

This is Elmar’s Verdict of Gemma 4 in terms of setting up via Ollama and using it for the first time:

Web-based LLMs are great for convenience and device flexibility. While local LLMs are great for offline reliability and privacy, I’d say the experience of experimenting with Ollama + Gemma 4 only made my perspective with AI clearer.

It is not magic, it’s just data combined with probability and rendering models that require large amounts of RAM for compute power.

This begs the question, if I have a higher end device, would I invest fully into local LLM’s?

I would not sacrifice my own hardware for running AI computations just to get responses faster.

There are data centers that have the hardware especially built for AI. I would rather give the job to them.

Overall, ChatGPT is still far more practical for my current workflow so I will be sticking to it as my default. However, I would definitely use Ollama + Gemma 4 as a reliable alternative.

That is Elmar’s Verdict on Gemma 4! In the early stage, it is fast to setup, but difficult to use when it comes to response time and the hardware needed, especially considering most users do not have a powerful laptop.

Now you know about the setup with Gemma 4! Starting off with Gemma 4 and seeing its outputs is a good sign that everything works! However, although Gemma 4 is a small and powerful model, how good is it at not being confused? We now transition to Konark where he tested Gemma 4 to the limit!

Using Gemma 4 as a Confused Developer

Konark SharmaFollow

I am software engineer who finds fun and creativity in Frontend. I would love to be a part of a team to help, develop and learn from new people and add my knowledge to the project.

Konark has been using Gemma 4 for some time and the one thing he wanted to know is to see if he can abuse Gemma 4 to its confusion.

We all have that one moment where we randomly test an AI just to see “How smart are you actually?” with questions like “How many r’s are there in strawberry?”. Konark did three tests such as the Strawberry test, the Tic Tac Toe Rotation test, and the Broken Cup Test.

The Strawberry Test

Konark asked Gemma 4: “How many r’s are there in strawberry?” (There are three). Initially, this type of question was commonly used to confuse many AI models.

Gemma 4 thought for a while and gave Konark three different interpretations regarding the number of “r’s” in strawberry.

Konark realized that sometimes AI over complicates simple questions and he would rather prefer simple answers. For example, if there are 10 apples in a basket and you asked Gemma 4: “How many apples are there?”.

Would you prefer this answer:

“This is my first time counting. Do you mean apples inside the basket or around the basket?”

Or would you simply perfer:

“There are 10 apples.”

Konark would prefer the second answer.

With these results, he was curious about how Gemini would answer to the strawberry test. As such, he asked Gemini and it simply replied:

3 r’s.

It is straightforward and it is always good to have a simple, non-complex answer.

The Tic Tac Toe Rotation Test

Another fun question Konark asked Gemma 4 was: “How would rotating a tic tac toe board by 90 degrees change the rules of the game and its strategy?”

The whole goal is to see if Gemma 4 thinks it’s still the same, expect the board is rotated.

However, Gemma 4 took quite some time to conclude this. It explained things properly and even walked through a rotated example.

Although it is a helpful response, it would be nice to get a more straightforward answer similarly to the Strawberry Test.

The Broken Cup Test

This is Konark’s favorite test, in which he asked Gemma 4: “I have a metal cup with the bottom missing and the top sealed. How can I use this cup?”

The simple answer would be “Rotate the cup. And suddenly, it becomes usable again.”.

However, Gemma 4 did not really understand the trick. Instead, it started suggesting alternative ways to use the object.

Although it is creative, it is not entirely correct.

On the other hand, Gemini understood the trick faster and then even expanded on practical uses.

Overall, Gemma 4 still struggles with certain trick questions and edge-case reasoning.

Konark’s Verdict on Gemma 4

This is Konark’s verdict of using Gemma 4.

After playing around with both models, I reached a simple conclusion.

Gemma 4 feels good for:

• learning
• content generation
• straightforward explanations
• slower, detailed responses

Gemini feels better for:

• trick questions
• quick reasoning
• direct answers
• faster conclusions

And honestly, both have their place.

Sometimes I want a detailed explanation.

Sometimes I just want: “Bro, just give me the answer.”

And that matters.

Because developers don’t always want essays. Sometimes we just want the bug fixed.

This is important to consider when you want to use Gemma 4. Sometimes, we just want a simple answer to the issue we are trying to solve. Of course, prompting varies and this is Konark’s experience using Gemma 4 so it can be different from others.

Speaking of prompting, AI is used to prototype projects in development! We now transition to Julien’s experience on using Gemma 4 when it comes to prototyping a project and how it compares to what he usually uses, which is Codex!

Building a Prototype using Gemma 4

Julien AvezouFollow

Builder | Software Engineer | Author of The Thinking Engineer Toolkit

Julien planned on using AI to create a fast prototype.

He was curious about how Gemma 4 performs compared to his usual setup, Codex (GPT 5.4).

For context, the project is a Chrome extension to help develop better use of LLMs. He will share more on his blog page in the future!

His goal is to compare Gemma 4 Vs. GPT 5.4 when it comes to prototyping. For this comparison, he will run tests across the following 2 categories using the same prompt as input and comparing the quality of the outputs:

1. Technical Depth: The factual accuracy, understanding of deep system mechanics and ability to compare non-trivial trade-offs.

2. Architecture & System Thinking: The ability to think at the macro level, identifying bottlenecks, scaling issues, and making justifiable “when/why” decisions.

Results of Gemma 4 Vs. GPT 5.4

Here are the results for the cases of Technical Depth and Architecture & System Thinking!

Technical Depth

This is the prompt given to both LLMs:

I am building a Chrome extension which detects when a developer is using ChatGPT, Claude, or Gemini, shows a floating button, opens a side panel, lets the user describe their task, recommends one of five AI thinking modes, generates a better prompt, and lets the user copy it manually.

Modes:
1. Explore — when I don’t fully understand the problem yet
2. Challenge — when I have a plan, but it might be wrong
3. Decide — when I need to choose between options
4. Audit — when I need to verify quality or correctness
5. Reflect — when I want to actually learn from what I did

MVP constraints:

• Chrome extension only
• no login
• no dashboard
• no automatic prompt insertion
• no usage tracking yet

Task:
Give me a technically detailed implementation plan for the MVP.

Here is the results:

Overall, GPT 5.4 gives the stronger Technical Depth output since it is more accurate, more build-ready, and more specific.

Architecture & System Thinking

This is the prompt given to both LLMs:

I am building a Chrome extension that helps developers use AI more intentionally.

It sits on top of ChatGPT, Claude, and Gemini. The user describes their task, then it recommends one of five thinking modes and generates a better prompt to copy.

Modes:
1. Explore — when I don’t fully understand the problem yet
2. Challenge — when I have a plan, but it might be wrong
3. Decide — when I need to choose between options
4. Audit — when I need to verify quality or correctness
5. Reflect — when I want to actually learn from what I did

MVP:

• detect supported AI chat pages
• show floating ModeCheck button
• open side panel
• recommend mode
• generate better prompt
• copy manually
• soft CTA to the Thinking Engineer Toolkit

Future:
A SaaS dashboard may later track AI usage modes, cognitive cost, dependency patterns, and optional hard blocks.

Task:
Think at the system architecture level.

Cover:

• best one-week MVP architecture
• what to build now vs postpone
• key system boundaries
• privacy/trust risks
• maintenance risks for a solo builder
• how to preserve future optionality for analytics/dashboard
• strongest argument for and against the browser extension approach
• recommended roadmap: week 1, month 1, month 3

Be concise but thoughtful. Focus on trade-offs and “when/why” decisions.

Here is the results:

Overall, GPT 5.4 wins on Architecture & System Thinking. Gemma 4 provides a solid, restrained MVP strategy, but GPT 5.4 gives a more complete architectural view: system boundaries, trust, local-first design, future analytics optionality, solo-builder maintenance risk, and roadmap discipline.

Julien’s Verdict on Gemma 4

This is Julien’s verdict on the use of Gemma 4:

GPT 5.4 seems to be the strongest at high-level reasoning and synthesis as you would expect from a recent frontier model.

However a good use case for Gemma 4 in terms of prototyping work would be for codebase analysis, running experiments through constraints and for privacy-sensitive workflows.

Being an open model which can be run locally has great specific and complementary use cases when prototyping developer tools.

I will consider this going forward.

Even though GPT is preferred when it comes to high-level reasoning and synthesis, there are other cases where Gemma 4 is useful for prototyping.

Speaking of prototyping, now we transition over to using Gemma 4 as an AI-Agent!

Using Gemma 4 as an AI-Agent

FrancisTRᴅᴇᴠ (っ◔◡◔)っFollow

📚 Full-Stack Developer 📚
“A Smooth Sea never made a Skilled Sailor” – Franklin D. Roosevelt

Whenever I am contributing to Open Source, it is quite useful to have an AI-Agent to work with you. My preference is to use an agent living in an application like Visual Studio Code.

I have been using GitHub Copilot when it comes to contributing to Forem and it has been useful when it comes to navigating code bases, problem solving issues, etc.

When I heard about Gemma 4, I thought it would be a good idea to try out when using Gemma 4 as an AI-Agent. I specifically used the cloud version using Ollama since the hardware I have cannot handle LLM locally, even though I tried the smaller version of the model.

Setting up wasn’t too difficult on my part. Since I tried Ollama to begin with before the release of Gemma 4, it was as easy as pulling the model using this command:

ollama run gemma4:31b-cloud

After installing, I selected the model and was ready to go!

When using the model, I noticed there wasn’t much of a big change compared to my initial workflow of using Copilot as my agent.

Both models asked me for permission when running commands, able to problem solve the issue I requested, etc. To be fair, I wasn’t using “Continue” Visual Studio code extension since it is quite popular when using local LLMs. Also, Visual Studio code is flexible when it comes to adding your own model in addition to using Copilot, which I wasn’t surprised that it behaves similarly when using Copilot.

However, there are a couple of things I noticed when using Gemma 4 that I believe are important to address based on my experience using Gemma 4.

Gemma 4 is Strict

The main difference between Gemma 4 and Copilot was that it is quite firm on the tasks it is given to them. I notice that whenever I request a plan on tackling an issue, it provides a To-do list of the steps Gemma 4 is planning on doing to fix the issue.

For example, this is the prompt I gave to Gemma 4:

I have this issue. How do I approach this?

https://github.com/forem/forem/issues/23277

It will output their findings like any other LLM. However, it would not act right away and instead, listed out the next steps:

In cases like these, I just follow up the Agent “Go for it” or “Proceed”. Sometimes it does everything in the to-do list in one go and in other cases it goes one by one where I have to tell the Agent to “Do all the tasks”. Do note that I did not change any settings as I was setting up Gemma 4 since it was just pulling the model and selecting it in Visual Studio Code.

Compare that to Copilot, where regardless of the prompt, it would take action right away. There were cases where I forgot to change the mode from “Agent” to “Chat” and I was specifically asking the AI about the plan to tackle the issue. Instead of listing out the steps, it did it right away which I did not want it to do.

In all fairness, Gemma 4 and Copilot are from different companies (Google and Microsoft) and since Copilot is built into Visual Studio Code, it is fair to assume that its actions strictly follows based on the settings you have in Visual Studio Code for Copilot.

However, it is always nice to see Gemma 4 listing out the To-do list and asking the user to proceed. I believe it is good practice by default if you are a type of user that wants to get an AI’s advice on what to do and doing it yourself from there.

Please Google I need this. Gemma 4 is kind of Looping Itself

It is exactly what you are thinking. This is a common occurrence where Gemma 4 will read a file from top to bottom and reread it again. Here is an example that I encountered when using Gemma 4:

I am not sure what is causing this issue since this happens randomly.

The solution is stopping the Agent and sending the same prompt. This fixes the issue really well, though this bug remains a mystery to why it occurs in the first place.

Francis’ Verdict on Gemma 4

This is my verdict on the use of Gemma 4 as an AI-Agent:

I believe Gemma 4 works really well when being an open source developer. It can navigate large code-bases and being able to solve complex problems well for a model that is quite small.

Although there isn’t a big difference between Gemma 4 and other models I have used, it is good to consider token usage. I would recommend Ollama when using Gemma 4. It is free to use the cloud version and the tokens reset weekly whereas Copilot resets monthly. If you are heavily relying on AI-Agents, I would recommend the Ollama solution since it is more flexible. Even if you reach the daily limit of tokens, it resets every few hours.

I would highly recommend Gemma 4 as a great starting point when it comes to using it as an Agent when you want to contribute to open source. Just remember to monitor the response time since there is a very good chance where it loops itself in which it would burn tokens in the process.

Summary

Gemma 4 has been used in some aspects when it comes to setting up Ollama to use Gemma 4, testing out the response of the model, prototyping using Gemma 4, and the role as an Agent. Here are the main things to consider based on what I have shared above.

1. Convenience

Like any other local models, you have to consider not only if you are conformable downloading a model locally, but ensuring you have enough compute power to run an LLM. Although there are options to use LLM on the cloud (for Ollama at least), having a local LLM is very convenient for developers who want to run the model locally and not worry about:

• Use of Tokens limits and payed services.
• The environment when it comes to data centers in the age of AI.

2. Performance

Speaking of compute power, having a local LLM, even with smaller models of Gemma 4, still needs a lot of power. We saw that in Elmar’s experience, it took a while for Gemma 4 to produce an output comparable to using any cloud model. If you are comfortable with the wait time of the model, then it shouldn’t be a problem!

3. Context Output

Every model behaves differently whether cloud or local models. This is no different to Gemma 4. If you are using Gemma 4, you have to make sure the prompt is specific to your needs. This is best practice in prompts in general when it comes to requesting your needs and being as specific as possible.

4. Role as an AI-Agent

It is common for developers nowadays to use a local model to run as an Agent. Using Gemma 4 via Ollama has been a great experience for me. Do note that you may encounter issues when using Gemma 4. I would recommend monitoring Gemma 4’s token usage in the event of Gemma 4 looping itself and burning unnecessary tokens.

Verdict: Overall, if you have enough power to run a local LLM and would like to have a model that is smaller but more powerful than other Flagship models to use in your development knowing the limitations of local LLMs in general, then I believe Gemma 4 is right for you!

I hope that this Multiversal Analysis has helped you to determine if Gemma 4 is right for you! If you like to learn more about Gemma 4 in detail, you can read here: https://deepmind.google/models/gemma/gemma-4/

Thank you for Reading!

If you have made it this far, thank you for taking the time to read this article! I hope you have learned something based on our experiences using Gemma 4 in different areas of development.

I would like to give credit to the Virtual Coffee Group where I used their “#co-working” room to meet with Elmar Chavez (@codingwithjiro), Konark Sharma (@konark_13), and Julien Avezou (@javz) for the first time outside of DEV and would love to work with them again in the future!

Feel free to send us love by following us individually and our DEVenger org!

The DEVengers
Follow

This is an organization where we assemble the greatest minds the community has ever known! The question isn’t “How fast can I code?”. The question is “What will I learn from the farthest below?”.

FrancisTRᴅᴇᴠ (っ◔◡◔)っFollow

📚 Full-Stack Developer 📚
“A Smooth Sea never made a Skilled Sailor” – Franklin D. Roosevelt

Julien AvezouFollow

Builder | Software Engineer | Author of The Thinking Engineer Toolkit

Konark SharmaFollow

I am software engineer who finds fun and creativity in Frontend. I would love to be a part of a team to help, develop and learn from new people and add my knowledge to the project.

Elmar ChavezFollow

Licensed civil engineer turned full stack developer building accessible, responsive web applications. I also review code in Frontend Mentor and participate in collaborative projects.

Challenge #1: Did you find 4 hidden random videos in this article?

Challenge #2: How many “r’s” are there in this post in total?

Challenge #3: Who are the anime characters in this article’s cover image?

Challenge #4: Based on Challenge 3, who decide to choose those anime characters in this article respectfully?

Any questions/comments? Love to hear your thoughts on Gemma 4! What’s your experience on using Gemma 4 and do you recommend it?

Last night the build was clean. This morning, five red errors before the coffee was even warm.

git log shows the only commit in the last 11 hours is yours. "Refactor player movement".

You hold the cold coffee. You stare at the screen.

If you’ve shipped any game ever, you’ve been here. Welcome to Dev Comics #1.

This is a new weekly-ish series from a small Korean indie game studio — short comics about the unglamorous moments of making games. New comics most Tuesdays and Saturdays.

Coming up:

• #2 Shader Compile Coffee — when your Unreal shader compile outlives your coffee
• #3 Cat.exe Has Stopped Responding — the cat owns the keyboard now

If this hit close to home, drop a 🦖 reaction or share the worst “11 hours ago, by me” commit you’ve ever seen.