A Tale of Talos: Part 3

In the third part of this article series, The Director’s Cut isn’t an extended version of a movie. It’s my actual experience working with AI agents on a personal project — still under development — called Radiofonic. If you haven’t come across it, Radiofonic is a radio platform with over 40,000 world radio stations, soon to include podcasts. It’s the kind of project that doesn’t fit neatly into a timeline — it progressed unevenly through the years, went commercial at one point, got put on hiatus, and is now slowly coming back with a different mission and a renewed sense of purpose.

The current edition has been in development since late 2024. AI entered the mix in mid-2025 — not as a grand strategy, but out of necessity. The math was simple and brutal: ship a mediocre product in a year, or spend a decade building a good one that would be obsolete by the time it shipped. Neither option was acceptable. So I did what every developer does when cornered — I found a third way.

The work spans two platforms — iOS and Android — with a Parse Server backend powering cloud functions in JavaScript and a REST API layer sitting in front of it. Not a greenfield experiment or a weekend hackathon project. Real production work, with real users, real constraints, and the kind of architecture decisions that keep you up at night. The scope was broad by necessity: app development on both platforms, REST API design and implementation, app architecture from the ground up, and framework and library creation. When you’re building for iOS and Android simultaneously, you either embrace reusability or embrace burnout. I chose the former.

The Automatons in the Room

Before we talk about what I built, let me introduce you to the cast — because this wasn’t one model doing everything. It was different tools, slowly progressing from continuous chat to agentic workflows over the course of nearly two years. Each one gave different suggestions, provided alternate implementations, and taught me which one to reach for and when. Learning that was half the battle.

ChatGPT was the onboarding stage. Architecture brainstorming, code modernization, “here’s what I’m thinking, how do I do this?” conversations — the kind of back-and-forth you’d do on every revision or new feature. It wasn’t only about code. It was also thinking, getting suggestions, planning, moving along. A simple exchange: get ideas, implement them, move forward.

Around that time came Ollama (Mark I). The promise was there: local models running on my own hardware. The reality was less kind. The models that fit in my 16GB of VRAM were either too small in parameter size or suffered from quantization artifacts, limited context windows, and other issues that made the output unreliable. Add to the mix the fact that there was no workable UI to help me (I found Open WebUI‘s early version inefficient too), and Ollama went on the shelf. But something was telling me this wouldn’t be for long.

Then came Perplexity, mostly running Claude Sonnet under the hood — the researcher. When I needed to dig into framework documentation, compare approaches, or understand how a specific feature behaved under certain conditions, this was the tool. Less conversational, more “go find me the answer and show your work.” The citations mattered — I wasn’t looking for confident-sounding guesses, I was looking for verifiable facts.

This went on for several months until the agent boom emerged. In a short time, enter GitHub Copilot (sponsored by PeopleCert, (the company I’m currently working for) with a suite of models spearheaded by Claude Opus, integrated directly into Visual Studio Code. Copilot allows you to add custom and third-party models — and just like that, Ollama (Mark II with cloud models) was back. Oh, and Xcode can connect to Ollama now — good stuff. Android Studio can hit Ollama too, even if Gemini is masterclass in Android Kotlin development. And Open WebUI? Now much, much friendlier — not only for chat via Ollama, but also for creating knowledge stacks I can reference (I finally built my Tolkien Legendarium stack and now have models answering all my Silmarillion questions in detail). Very honorable mention to Msty, a powerful desktop application that combines local and remote models, persona prompts, knowledge stacks, and web search into a single hub. It seems the progress in the last 6–7 months was greater than in the previous 2 years combined.

Minimax-m3 and Claude Opus are the heavy lifters. When it was time to actually generate code — full implementations, complex refactoring, multi-file changes — this is where I turned. Having two high-performance models wasn’t about redundancy; it was about range. Different models have different strengths, different blind spots, different ways of approaching a problem. Sometimes you want a second opinion that doesn’t share the same architecture. And Copilot in agentic mode isn’t just a chatbot that happens to write code. It operates with a level of context and continuity that makes it feel less like a tool and more like a pair programmer who actually remembers what you discussed ten messages ago.

Here’s the thing though: none of these were operating in isolation. The real shift wasn’t adding AI to my workflow — it was realizing that I’d gone from asking a tool a question to directing a team of them toward a goal. Today, Claude helps me decide what to build and how the pieces fit. Ollama and Minimax actually build the pieces under Copilot’s coordination. I wasn’t a developer using AI anymore. I was a director with a cast — and the cast was getting better every month.

App Development — The Director in Action

Radiofonic runs on iOS — already released and live on the App Store — with an Android version, at the time of writing, under development. The experience of working with AI agents on each platform couldn’t have been more different. Not because the tools were different, but because the platforms weren’t.

Let’s focus on iOS, because that’s the platform that’s been through the full cycle — from legacy modernization to release. The codebase had been patched, extended, and partially modernized over the years — layers of history baked into every file. Swift had evolved, new architectural patterns had emerged, and old assumptions no longer held. The first thing I learned about working with agents on a mature codebase is that context is everything. Hand an agent a single file and ask it to refactor, and you’ll get something that compiles. Hand it the file, the models it references, the view hierarchy it sits in, and the API contract it consumes — and you’ll get something that actually works. The more context you provide — through a step-by-step process of describing intent and performing checks — the better the result.

That’s where Copilot’s agentic mode with Opus’s or Minimax’s context window earned their keep. I could describe a feature — say, a new Podcasts section that starts from a REST API where the data resides and feeds into a whole new functionality combining podcasts with radio in the app — and the agent would generate the implementation across multiple files, respecting the existing architecture, referencing the right models, and wiring up the dependencies correctly. Not always perfectly, but close enough that my job shifted from writing and wiring to directing, reviewing, and correcting. The pair programming concept from Part 2? This was it — except my pair partner didn’t get tired, didn’t need coffee (contrary to myself), and could hold the entire project structure in its head while I focused on the why and what.

Android was a different animal entirely. Not because the AI was worse at Kotlin — Gemini in Android Studio is genuinely impressive at it — but because I was starting closer to scratch. The iOS codebase had years of context I already held in my own head. Android was newer ground, which meant fewer assumptions and fewer legacy traps. I started building bottom-up, wiring APIs, DTOs and DAOs into use-cases streamlining to the UI. The interesting part? This is where the agent actually helped me learn the platform. When you’re directing an agent to build something in a framework you’re still getting comfortable with, every generated file becomes a lesson. The code it produces teaches you the patterns, the conventions, the idioms. You’re not just shipping faster — you’re absorbing the platform’s DNA through the output.

But Android is still under development — nowhere near the maturity of the iOS version — so the story here is thinner by necessity, not by omission. What I can tell you is this: letting Copilot/Opus generate the project structure for Android Studio led to a series of issues (dependencies, versioning, linking) that I spent unnecessary time fixing before I ultimately invoked the Gemini powers to repair all the broken parts. Had I taken the different path of selecting a standard project template and deploying Gemini from the start, I would have saved a couple of hours of problem-solving. As for Xcode? Copilot’s Xcode integration is still in its early days — the context handling and project awareness aren’t quite there yet. I’ll wait for the next iteration to try again.

Where did agents struggle? Platform-specific gotchas — the kind of thing no amount of context prevents. Agents can get you most of the way there on both platforms. But that last stretch — the project setup, the part where the documentation is wrong, the framework is behaving irrationally, and the only solution is to experiment — that’s still very much yours.

The test-fix loop from Part 2 played out here in the most mundane, practical way possible. Write code → run → fail → paste the error → agent diagnoses → agent suggests fix → run again → maybe pass, maybe fail again. But here’s the thing — when the agent is running that loop with you, not for you, the cycle compresses dramatically. What used to be a 45-minute debugging session becomes a 5-minute conversation. Not because the agent is smarter than you, but because it never loses context, never repeats a failed attempt an hour later. It remembers what you tried, what failed, and what the error looked like — and it doesn’t need you to re-explain the problem every time you come back from a failed build.

That’s the real shift. Not speed — continuity. The agent doesn’t forget. And when your project spans months and you’re juggling it alongside everything else in your life, having a collaborator who remembers everything you discussed last Tuesday is worth more than any single feature it can generate.

Talking to Machines About Machines

There’s a particular irony in using AI agents to write backend code that exists solely to let apps talk to other apps. You’re directing a machine to write code that helps machines communicate with machines — a layer of abstraction so meta it would make the Architect from Part 2 raise an eyebrow. But that’s exactly what happened when backend development became a necessity mid-flight.

Radiofonic’s backend runs on Parse Server, with JavaScript cloud functions handling the logic and a REST API layer sitting in front of it. This wasn’t part of the plan in the early days — the project had evolved to a point where backend functionality wasn’t optional anymore. Station and track metadata, generic data (localized countries, languages), configuration parameters, shared business rules, platform-independent functions — all of it needed a server. And I needed to build one without becoming a backend engineer overnight.

This is where the reusability theme from Part 2 stopped being a historical observation and became a daily practice. The REST API layer needed to be consistent, well-structured, and — crucially — reusable across both the iOS and Android clients. That meant designing endpoints that served both platforms without favoring either, writing cloud functions that handled business logic in one place rather than duplicating it across two apps, and creating a shared contract that both clients could rely on. In other words: frameworks and libraries. The same pattern that moved software engineering from “writing everything from scratch” to “composing existing pieces” — except now, I wasn’t just consuming existing libraries. I was building new ones, with an agent as my pair.

Claude Opus and Minimax-m3 were instrumental here, and for a specific reason: JavaScript backend code is where the context window matters most. When you’re writing a cloud function, you’re not just writing a function — you’re writing something that interacts with a database schema, follows routing conventions, and returns responses in a format the clients expect. An agent that can hold all of that in context at once doesn’t just write better code — it writes coherent code. Code that fits the system instead of code that just happens to run.

But there’s a confession I need to make about how that code was actually written. During this process, I gave the agent freedom to write code without restrictions or architectural patterns — testing what Part 2 called Vibe Coding in a real codebase. I stated my intent, let the agent pull the strings, and tested the output. The result? Code that executes cleanly, performs the tasks I asked for, and returns results ready to be consumed by the mobile clients. But here’s the catch: navigating through the functions, dependencies, and files — aside from the base structure — is difficult without sitting down and analyzing what the agent actually wrote. The code works. I know the intent behind it, and I still need to study the output to understand what it actually does. Any other programmer coming in would need to understand both the intent and the code — and the code isn’t giving up its secrets easily.

This is exactly what Part 2 described. And if I’m honest, it wouldn’t have mattered much whether the agent handed me JavaScript or binary — my intent was served either way. The source, in either form, would be equally opaque to anyone without the original intent. What we call Vibe Coding today — AI generating code from human intent, in a language humans can nominally read — will perhaps be called Binary Coding: the same intent-driven process, but the output is pure machine. No intermediate language. No JavaScript, no Swift, no Kotlin. Just intent in, binary out. The source will matter as a point of reference, in whatever form it may take in the future — blueprint, outline, or full code — documenting the intent for other programmers to follow. Without that, the intent fades when the original author steps out of the picture. And as long as the intent is served, that’s enough.

The creation of platform-agnostic cloud functions deserves special mention because it’s where the director role really crystallizes. When you tell an agent “create a reusable cloud function that handles communication with other online services, parse the response and send the results across iOS and Android,” you’re not writing code — you’re setting intent. The agent generates the implementation, but the architecture is yours. You decide what gets abstracted, what gets exposed, what stays internal. The agent fills in the scaffolding. This is the boilerplate-automation benefit from Part 2 made real — except it’s not just boilerplate. It’s foundational code that an entire project feature may rest upon.

And then there’s the data. The schema design, the indexing strategy, the query optimization — the parts of backend development where a wrong decision in month one becomes a performance nightmare in month twelve. This is where I was most cautious about delegation. Agents can suggest schemas. They can write queries. They can even explain why a particular index strategy makes sense. But the judgment of what to optimize for — read-heavy vs write-heavy, denormalization tradeoffs, when to accept a slow query because the alternative is a complex migration on a live system — that’s the director’s call. The agent can draft the blueprint. The director decides what gets built.

The Director’s Call

If there’s a thread running through all of this, it’s the boundary between what agents do well and what still remains human. Agents write code. They don’t design systems. Architecture decisions — what patterns to use, how layers communicate, where to draw abstraction boundaries — are still the director’s job. An agent can propose a structure, but it can’t judge whether that structure fits the project’s future, the team’s capabilities, or the constraints you haven’t written down yet. And judgment is what architecture is.

What surprised me most wasn’t speed or quality — it was memory. The agent remembering a conversation from weeks ago and applying it to a new problem without being prompted. When your project spans months and you’re juggling it alongside everything else, that kind of persistence is worth more than any single feature.

The New Workflow — and a Closing Thought

The process shift is real, but it’s not what you’d expect. Code review becomes intent review — you’re not checking syntax, you’re checking direction. QA becomes “does the output serve the intent?” not “does the code look right?” The director doesn’t debug the implementation. They debug the instruction. And when the instruction is clear, the implementation follows.

The programmer won’t disappear. They will become directors. This article isn’t a proof of concept — it’s a log from the field. The director’s cut. And if there’s one thing the Talos myth teaches us, it’s this: Talos didn’t need Daedalus to tell him how to throw a stone. Just when, and at whom. The automata are here. The question isn’t whether they’ll work — they do. The question is what we’ll direct them to build, and whether we’ll know the difference.

PS: Along with the models mentioned, glm-5.2 of Z.ai is tested now… and looks good! Waiting also for Kimi 3 in the coming weeks.