GitHub Copilot has been my constant companion for over a year now. During this time, I’ve managed to love it, curse it, and develop a very specific opinion about it. So far in this series, we’ve covered AI’s role in architectural planning and looked at how it efficiently handles generating repetitive blocks of code (boilerplate).

Today, we move to the most granular level – daily “on-the-fly” coding. Autocomplete is no longer just about suggesting variable names; it’s an attempt to predict a developer’s intent in real-time. In this post, I summarize my experiences with Copilot and close the series on AI in mobile programming by answering the key question: in 2026, is it still worth writing code from scratch?

When Copilot Surprises You (In a Good Way)

I was recently working on a widget for a schedule entry list in Flutter. I wrote the class name, declared the data list field, and… Copilot completed the entire build method on its own. No questions, no prompts—just “Enter”:

class ScheduleListView extends StatelessWidget {
  final List<ScheduleEntry> entries;
  const ScheduleListView({super.key, required this.entries});

  // Copilot completed from this point:
  @override
  Widget build(BuildContext context) {
    if (entries.isEmpty) {
      return const Center(
        child: Text('Brak wpisów w harmonogramie'),
      );
    }
    return ListView.builder(
      itemCount: entries.length,
      itemBuilder: (context, index) =>
        ScheduleEntryCard(entry: entries[index]),
    );
  }
}

I accepted the suggestion, reviewed it, and kept it. It was correct—it accounted for the empty list state and used a high-performance ListView.builder. These are the details that matter, and Copilot “sensed” them. For typical Flutter patterns, the tool speeds up my work by about a dozen percent. It’s not a revolution, but it’s a noticeable difference in comfort.

When Copilot Fails

The problem arises with the broader context of the project. Copilot, despite getting smarter, still has a limited field of vision – it focuses primarily on the currently open file and a few neighboring tabs. It doesn’t always know that I already have a ready-made method or widget in a completely different part of the project that I could reuse.

The result? I once noticed that three very similar functions for date parsing appeared in my project – each in a different file, each written slightly differently. I had accepted Copilot’s suggestions in three different work sessions, not noticing that I was creating the same mechanism for the third time.

This is a real danger: having several similar functions in different places isn’t just messy; it’s a potential source of inconsistency. Each might behave slightly differently in edge cases (e.g., with an incorrect date format), and finding the resulting bug can take hours. Copilot does not replace project orientation – it simply doesn’t have it.

To Prompt or Not to Prompt: My Summary

We’ve gone through planning structures and generating data blocks to writing individual lines of code with assistance. After these many months, my answer to the question in the title is: Prompt, but with limited trust.

What AI does well:

• Generates project structures – quickly and cleanly (with a good prompt).
• Handles boilerplate – serialization and constructors without tedious clicking.
• Completes typical patterns – it does this faster than I can think about the syntax.
• Helps understand unknown libraries or legacy code – great as a quick “logic translator.”

Where AI struggles:

• Lack of broad project context – it only sees what is “right in front of it,” ignoring the rest of the app.
• Risk of duplication – it doesn’t know that an identical or similar method might already exist in another file.
• Scaling issues – it doesn’t always match the complexity of the solution to the actual needs of the project.
• Lack of architectural verification – it doesn’t check if the proposed code fits established standards and patterns.
• Lack of a “project map” – it won’t replace a developer’s knowledge of which modules have been built and where they are located.

Final Thoughts

The three stages I’ve described in this series – from planning architecture to generating data structures to daily support in writing code – lead to a consistent conclusion. In 2026, AI is no longer a technological curiosity but a standard element of a professional toolkit that significantly boosts efficiency.

However, my experience shows that this technology works best as an advanced assistant that can rapidly prepare repetitive foundations and templates. The engineer still bears the ultimate responsibility for ensuring the entire construction is consistent, efficient, and tailored to specific hardware requirements. The greatest benefit of implementing AI into our daily workflow is offloading repetitive tasks, allowing us to focus more on system logic and solving the actual business problems of our clients.

Regardless of the pace of development in language models, the key to success remains conscious code management. AI can give a project momentum and simplify routine tasks, but deep knowledge of the architecture and the interconnections within the project remains the only guarantee of delivering solid, secure software.

#GitHubCopilot #AIProgramming #FlutterDev #Automation #CodeReview #CleanCode #Indoornavi #SoftwareDevelopment #Programming2026