Do You Need to Know the Language for It to Be the Best Tool for the Job?

Mi Pueblo is a family location-sharing app. It's in production, used by my family, and built with Flutter and Elixir. I knew neither language when I started.

Why These Tools

I wanted to test Flutter for cross-platform mobile. One codebase for iOS and Android, with hot reload and a widget-based UI that doesn't require the build-test cycle that React Native's Expo workflow essentially demands. For the backend, Elixir and Phoenix have first-class real-time support—Phoenix Channels and Presence tracking are built into the framework, not bolted on. For an app whose core feature is live location sharing, that matters.

Both were worth trying on technical merits. The catch was I didn't know either of them.

What the App Does

The short version: real-time location sharing for a family group. The longer version is that building a "simple" location app turns out to require a surprising amount of infrastructure.

• Real-time location — live position updates via Phoenix Channels, with Presence tracking for who's online
• Geofences — define areas (home, school, work) and get push notifications on enter/exit events
• Group management — invite codes, family groups, per-member permissions
• Spatial queries — PostGIS for geofence containment checks and distance calculations
• Background tracking — platform-specific background location services on both iOS and Android
• Push notifications — Firebase Cloud Messaging for geofence alerts
• Subscription tiers — RevenueCat integration for premium features

Around 127 commits, deployed and actively used by the family.

AI as Language Expert

Here's what changed with AI in the loop: the language stopped being the bottleneck. The AI knows Flutter widget composition and Riverpod state management patterns. It knows Elixir's pipe operator, Phoenix context conventions, and Ecto changeset validation. It knows how to structure a GenServer for background geofence processing and how to set up a Phoenix Channel for bidirectional real-time communication.

I don't know any of that. Or rather—I didn't when I started, and I still don't know it the way I know Python or C++. But it turns out that doesn't matter as much as I would have expected.

My job shifted from writing code to making product and architecture decisions. What should the data model look like? How should real-time updates flow from device to server to other devices? What's the right UX for geofence notifications—instant push, or batched with a dwell time to avoid false positives? How should background location tracking balance battery life against position accuracy?

These are the decisions that actually determine whether the app is good. The AI handles the syntax and idioms. I handle the design.

Two Modes of AI-Assisted Development

This is a different relationship with AI than what I described in the Haskell post. With Splendor, I knew the language deeply. I used Haskell's strict type system as a guardrail—the compiler caught the AI's mistakes before they could propagate. I was the language expert; the AI was the fast-but-fallible coder.

With Mi Pueblo, the roles are inverted. I don't know Flutter or Elixir well enough to catch idiomatic mistakes by reading the code. Instead, I'm relying on the AI for language expertise while I provide the product direction. The AI is the one who knows that a Riverpod AsyncNotifier is the right pattern for managing location state, or that an Elixir GenServer should handle geofence evaluation on the server side rather than the client.

Two different modes. In one, I'm the expert and the AI is the coder. In the other, the AI is the expert and I'm the product owner. Both work.

The Takeaway

For most of my career, tool selection has been filtered through "what do I already know?" You pick React because you know React, even when a different framework might fit the problem better. You reach for Python because it's comfortable, even when the runtime characteristics don't match what you need. The switching cost of learning a new language or framework is high enough that you default to the familiar.

AI changes that calculus. The switching cost drops dramatically when you have an AI that already knows the target language's patterns, idioms, and ecosystem. You can actually try the tool that fits the problem—Flutter for cross-platform mobile, Elixir for real-time systems—instead of defaulting to whatever you already know.

That doesn't mean language choice is irrelevant. It means the relevant criteria shift. Instead of "what do I know?" the question becomes "what fits the problem?" And that's how it probably should have been all along.