AI and Boilerplate: When the Code Writes Itself (And When You Regret It) Series: AI in the Work of a Programmer and Electronics Engineer (Article 2 of 3)

Every mobile project has its own rhythm. New screens, new data models, new services—and along with them, tons of repetitive code: constructors, conversion methods, configurations. I used to write it all by hand. Now, more and more often, I delegate it to AI. And I have developed a fairly firm opinion on the matter.

In the previous article, I described how artificial intelligence helps plan the architecture and directory structure of a new application. Today, we’re going a level deeper—to the daily grind of coding, where a large portion of tasks involves writing repetitive, schematic fragments known as “boilerplate.”

What exactly is “boilerplate”?

For someone who doesn’t code every day, programming might be associated with inventing complex algorithms. In reality, a big part of the job is building solid “data plumbing.”
Imagine our app needs to fetch information from a database about a doctor’s appointment or a shift schedule. Before that data reaches the phone screen, it must be parsed, checked for errors, and properly formatted. This is boilerplate—repetitive, technical code that doesn’t add new business logic but is essential for the app to function. It is necessary for the system to remain stable and predictable.
The problem is that writing it manually can be tedious, and that is precisely where it’s easiest to make a mistake born of fatigue. This is where the AI assistant steps in.

When AI really helps

Recently, I was working on the ScheduleEntry class—a data model representing a schedule entry. I wrote the basic structure, defining what information we want to store (employee ID, start and end times, a note):

code

To make this class useful in a professional project, it needs a set of standard methods (so-called “extensions”) that allow for comparing two entries or sending them to a database. I pasted this base into the AI and asked: “Extend this class with fromMap, toMap, copyWith, and an Equatable implementation.” In a few seconds, I got the ready-made code:

I copied it, reviewed it, and… left it almost unchanged. The code was good. Clear, complete, and functional. What’s more—the AI independently added null-handling in toMap (if (note != null)), something I might have overlooked while writing from memory after eight hours of work. This is the moment when AI truly earns its place in a developer’s toolkit.

When AI overdoes it

It’s not always so rosy. Once, I needed a simple helper function to format the duration of a shift—something like “3 hrs 45 min.” Simple enough; I would have written it in two lines. Instead, I received a complex object with formatter caching, support for multiple output formats, and full localization.

What I expected (2 lines of code):


What the AI generated (40+ lines):

Technically, it was flawless. But in a small mobile app where this function is called in only one place, it’s a complete case of over-engineering. Such code is harder to read, harder to maintain, and feels like someone trying to impress with the size of the project rather than solving the actual problem.

I copied my two lines, closed the chat, and moved on.

Summary

AI is a huge time-saver when generating boilerplate, but it requires the programmer to act as a critical editor. You have to read the code with understanding—both to catch potential bugs and to judge whether the proposed solution isn’t simply too bloated for the actual needs of the project.

In the next post, we will look at GitHub Copilot and “on-the-fly” code completion. I’ll explain why this tool requires special attention when the AI loses the broader context of the project.

#Flutter #Dart #ArtificialIntelligence #AIinIT #MobileAppDevelopment #CleanCode #Boilerplate #Programming #SoftwareHouse #Indoornavi #ITEfficiency