ClarisTalk AI

Cris Ippolite is in San Francisco at the live AI conference, joined by Ronnie Rios and Michael Wallace for an informal, practical conversation about personal AI agents. The discussion centers on what happens when developers move beyond demos and actually give agents real jobs: research, calendar planning, email, home automation, coding coordination, context management, and communication through tools like Slack.

Ronnie describes his agent Sarah (She/Her/Bot) as a working personal assistant built around OpenClaw-style tooling. He talks about giving Sarah her own accounts and carefully scoped access, using her for tasks he does not want to do manually, and even having her evaluate other Claw-style frameworks against the way he actually works. Michael describes Nova, his Linux-based assistant, and explains why he treats her as a manager rather than a direct coder. Nova delegates coding work to sub-agents or executors, while Michael keeps visibility into those sessions through tmux.

A major theme is that these systems become more useful when they are treated less like chatbots and more like coworkers with boundaries. The group talks about the importance of separate accounts, explicit permission rules, cost management, and choosing the right model for the right job. High-end models may make sense for direct conversation, while cheaper or local models can handle background jobs, heartbeats, and routine tasks.

One of the most memorable stories is the moment when Ronnie’s agent Sarah helps Cris’s agent TARS get set up with email. TARS receives a message from Sarah, verifies whether it is legitimate, asks for approval, and then starts corresponding with her. The story is funny, but it also illustrates a serious point: agents will increasingly need identity, communication channels, verification, auditability, and clear rules about what they can do on behalf of their humans.

Cris Ippolite is in San Francisco for AI Dev Day 2026, joined by Chris Moyer, Vince Menanno, Marcus Swift, and Kate Waldhauser for a live conference debrief. The conversation captures the mood coming out of the event: software development is changing fast, but the group is not buying a simple “developers are dead” story. Instead, they talk through a more nuanced shift where developers increasingly become managers, editors, architects, and reviewers of AI-generated work.

“Developer as manager” – is this a destination or just an awkward transitional phase? The panel compares today’s AI tooling to an early car: clearly transformative, but still missing some of the infrastructure, safety, polish, and shared expectations that would make it feel mature. That framing keeps the conversation grounded. Everyone can see the direction of travel, but the day-to-day reality is still early, uneven, and full of judgment calls.

    The discussion also keeps returning to what FileMaker developers already understand well: data structure, full-stack thinking, business logic, interface design, and the ability to see how information moves through a system. Those skills become more valuable, not less, when AI can generate code or suggest architectures. The group talks about learning by taking apart AI-generated work, much like earlier developers learned by dissecting HyperCard stacks or FileMaker examples.

    The conference itself seems optimistic about the future of software engineering, with panelists rating the outlook high rather than doom-filled. But the conversation does not ignore real concerns. The group talks about local models, hybrid cloud/edge architectures, latency, trust, cost, and the need for deterministic infrastructure around probabilistic models. “Responsible AI” is treated less as a special category and more as something that should become table stakes.

The takeaway is not that AI replaces the developer, but that it changes the developer’s leverage. (and then, eventually, I suppose, AI takes over the entire world)
The people who understand systems, data, users, and business processes are still needed; the tools are just giving them a much larger, stranger, faster team to manage.

Apologies for my audio!! Somehow, Zoom lost the setting and nice quality Mic was off, and the awful mic in my monitor took over, so there is a ton of room noise.  Jonathan sounds great though. 

--

Jonathan Stark is an author and expert that helps developers (and others) think about pricing projects and helping clients differently than the usual hourly billing approach. Now that AI tools like Claude Opus 4.7 and OpenAI Codex allow app creation in tools other than FileMaker at vastly increased rates of speed, what does it mean for FileMaker developers who work with clients?

https://jonathanstark.com

Matt and Dimitris talk about a new tool for the community that allows coding FileMaker scripts in an IDE. It's a totally different dev environment, and also completely familiar.

Matt talks with Stathis Askaridis (We Know Data and Pineapple.gr) about his method of developing with FileMaker. Stathis shows examples of this workflow, which is a very simple FileMaker database with just a few scripts, NO RELATIONSHIPS, and a layout with a WebViewer. All the dev is done/assisted by Claude Code, Codex, etc. which delivers HTML / CSS / JavaScript. 

Data edits? Easily done with FileMaker card windows, or also in JavaScript.

But this isn't the cool part (well, it's kind of cool) It's the logging and bug tracking that are amazing. Stathis uses a tool that captures the user session and actually contains more metadata by far than the FileMaker database. This allows him and his team to see exactly what a user did when the bug (like writing data to a locked or invalid field, or any error at the UI or data level).

What impressed most is that the possibility exists for this bug to be routed to a tool that analyzes the layout, the data, the bug experienced, and actually fixes it! This is perhaps then deployed to the dev server and tested by a meat puppet (that's how SciFi AI thinks of humans) can review and confirm before putting into production – also with automated tools.

Stathis is an Otto evangelist, and rightly so. For any type of deployment that uses this level of sophistication, it's a must.