Difficult tasks that are now easy – with Charles Delfs from Klai Studio

Charles and Matt discuss a working list of engineering problems that used to be hard in FileMaker and are now easy, plus the vocabulary you need to ask an agent for them.

Idempotency. Mutex. Message queues. Race conditions. Rich error objects. Test-driven development. None of it is new to computer science, and all of it is stuff FileMaker developers have been hand-solving for years without the words. Learn the words and you can prompt for the solution instead of letting the agent lead you.

Also: the difference between vibe coding and agentic engineering, why rage coding works (all caps included), and Matt's first public walkthrough of Pythia, his new amazing reporting tool.

⏱ CHAPTERS 0:00 What got easy, and Charles has not written code since November 2:15 Vibe coding vs agentic engineering, two competing definitions 5:40 The thing that used to be hard was research 6:40 Rage coding, FFS in all caps, and why it sometimes works 9:15 Build a v minus one. Refactoring is cheap now 12:20 Plan mode, and coding like jazz 13:30 Conditionals and feature gates as a JSON object 15:00 Defensive coding, and LLMs that guard too much 16:30 The senior engineer who asked for the temperature coefficient 17:30 Race conditions, defined for the rest of us 20:00 Test-driven development, and why FileMaker test suites were brutal 22:30 A free project idea: an OData-driven test suite for your scripts 24:45 Rich error objects, and the five word prompt that gets you one 27:45 Message queues, pipelines, throttling and debouncing 32:20 Idempotency: the blue button that sends two emails 39:03 Mutex, and how it differs from a transaction 42:35 The Dell sync bug that broke something every three days 47:12 Put an agent in your admin panel 52:22 What Klai is researching next: seeing into a huge codebase 53:30 Matt's adversarial agent loop: Claude Code, Hermes, and a message table 54:55 The API key vibe coded into the front end, and where governance fits 58:29 Pythia: reports that go past what FileMaker can do 60:02 22 apps on Fly.io for $13 a month 63:04 Function as a service, and keeping a light footprint

🎙 IN THIS EPISODE • Charles: vibe coding is building in a technology you cannot read or understand • Why FileMaker developers were never really vibe coding, and where that breaks down • The sunk cost fallacy is a human trait, not an AI one. Rip it out and start fresh • Feature flags as plain JSON keys, so accounting never clicks your reset button • Why the LLM's first version is probably better than your first version, and the second version is much better than your second • Rich errors carry a request ID, a suggestion, and a doc link, so an agent can debug them • Idempotency in FileMaker terms: that timestamp field you already add after the client complains • A sync bug at Dell that surfaced once every 20,000 transactions, and the week it took to find • Pythia syncs your data to DuckDB so a million records slice instantly, then writes the report code and hands you a PDF

🔗 LINKS Klai Studio: https://klai.studio Navarre.ai: https://navarre.ai Free weekly FileMaker AI classes: https://navarre.ai/#/classes Fly.io: https://fly.io

Coming in future episodes: code introspection research from Klai, and an episode on Genie with Bruno.

#FileMaker #Claris #AI #ClarisTalkAI #AgenticEngineering #VibeCoding

Transcript

SPEAKER_00 0:01

A lot of programming tasks that used to be hard are now easy, thanks to AI. So today I'm here to talk to my friend Charles Delps with Calais Studio about this topic. Welcome, sir.

SPEAKER_01 0:12

Hey man, welcome. Thanks for having me back. Looking forward to today. All right. Yeah. So there's like yeah. I know you've been probably building a ton of stuff. I think everybody, I think everybody has.

SPEAKER_00 0:25

Would you say that you're having the most fun you've ever had in your career? No. I am. No.

SPEAKER_01 0:32

Well, you know, here's the thing. Well, like, I think it's what drives us, right? Yeah. Is it the is it the final outcome of something? Or is it the challenge? Like, where are you? Sort of goal-oriented, problem-solving-oriented, task-oriented. Um, and for me, it's always engineering problems. I love that concept. Let me try to solve some problem. Solving out the problem got slightly easier um because I can do the research through with AI and I can get to that end goal quicker. The building thing is was was okay, right? But I was I dabbled in lots of different technologies and did quite a bit of you know, relatively advanced coding over my my years. So that that yeah, I'm kind of I don't want to say missing that, but I haven't written a line of code since November of last year. And um the other day I was doing a demo actually. I was doing a demo for Clay Studio with a client, and in my demos, I have to actually type some file makers, this is weird. I yeah, I've actually forgotten little tiny bits. Yep. And that's something I don't know if you've if you've found that, but I I never had that problem before of like remembering how to do stuff.

SPEAKER_00 1:46

So I I was actually doing some coding with a client earlier today, and there was a specific setting embedded deep within the panel, uh, you know, design panel for a layout tool for something. And I had to think about like where where is that? And you know, exactly how far down is the tool for transparency of text, you know, which I which used to be muscle memory, and it's not anymore. But I still am in FileMaker a lot, lot, lot. All right, like you, most of my time now is uh agentic engineering uh slash vibe coding.

SPEAKER_01 2:20

Um can we do a quick aside, Matt, and just talk about maybe what what you feel a different definition there. And you know, I think everybody realizes what vibe coding is. You know, it's just I'm gonna fly by the seat of my pants and I'm gonna whip something out.

SPEAKER_00 2:34

I'd put it a little differently. I would say vibe coding is building an application in a in a um using a code technology that you can't read or understand. And I'm not sure that that's fair, but I think you know, your other your other definition is a pretty solid tool. Just throw something together and not really understand what you're making.

SPEAKER_01 2:51

So 20 years ago, that what when we were coding in FileMaker, or say 30 years ago, even, that wasn't vibe coding, you would say. That was what would you call that?

SPEAKER_00 3:00

Well, everything we've just been in our vibe coding, or everything in FileMaker from the beginning has been, if it's if you could call it coding, it was coding because we understood every bit of it. Obviously, we had no idea what was going on under the scenes. So I also see this as a parallel, right? Like when we did something in FileMaker and we made a relationship or something, um, all kinds of things were going on that Clay Mackel understands, right? But none of the rest of us do. But we were able to use it at that high level. Well, now we have Claude code, and I can use clod code, and I can put things in there and I can see it, and I can see the result I get, and I don't know what's happening under the surface, and I don't think it's fundamentally different.

SPEAKER_01 3:46

Okay. So I I I envision, I guess, you know, when the I think it's Kirk Karpathy who who originally coined that that phrase, and that doesn't mean his definition was accurate either or great or well matched, but I kind of feel like it's kind of uh I got a vibe. I'm just kind of gonna kind of wing it. I don't have a clear roadmap, right? I don't have a full PRD, maybe. And I do feel that's how we uh a lot of file maker systems are are still, you know, uh uh built that way. We just oh, I need a button, I need a layout.

SPEAKER_00 4:19

Yeah, yeah, yeah, yeah. I guess it's a different spin on it, right? It's basically like how clear do you know what you're trying to build and how well understood are the tools and the uh business needs of what you're making. Um from that perspective, you're you're definitely right on. A lot of file maker systems didn't know that. Didn't um um what I love about it is even not knowing, they could still make a company really successful with the databases we built.

SPEAKER_01 4:46

Yeah. It's funny, just you you just mentioned something about not seeing or not knowing what you're building. Um the technology stacks that we agentic engineer, and we'll talk about that in a second, and the that we vibe code, you know, I we were and our team was coding. That was our that's our our first language, and and FileMaker being a close second as far as what we do. Yeah, maybe even a second, arguably. Um but that whole concept of code introspection is something that we're doing actually, uh, and we maybe we'll talk about this on a different show, but we're doing a lot of RD on and you know what what what's involved in that. But what I wanted to talk about today is a couple of things that are easy. Yeah, things that are easy. And the first one is true engineering, because now, like what used to be hard is research, figuring out, hey, what module do I want to use? What what concept do I want to use? Maybe I don't even know those concepts. Um, you know, we'll uh a company will release something like um like a message queue, and everybody goes, oh wow, this is revolutionary when we've had that for you know decades. But in our in our ecosystem, the file maker ecosystem, we we we don't use that kind of stuff very often. And I want to talk about some of those concepts that we can start to, but just by having a um um a little bit of awareness about them, we can actually build significantly better code. And it's not so much um not so much about the the the little pieces of of how things work, but the high-level concepts because we again, as you mentioned, we don't really need to know those little pieces anymore. We need to know conceptually, hey, this is how I'm gonna tackle this problem. Right. And just going back to your vibe coding, have you found uh when when when your LLM gets um well when you start to rage code a rage vibe and and you start to sit back a second? I've never heard this term and I love it. So I yeah, I I've done that sometimes, but I do it intentionally, and there is some there is some uh rage like anger, like you're like you're yelling at the uh LLM because it's not yeah, like I'll use acronyms like FFS and WTF and things like that.

SPEAKER_00 7:06

All caps, lots of all caps.

SPEAKER_01 7:09

Yeah, and they actually do have, and there's some studies that show that does have some effect because it it increases the sort of the weight or the the importance of that that that term or whatever you're talking about. But going back, what do you find that you like what what puts you into that? I'm getting into that rage mode now. Because what did NLM do? What didn't it understand from your or infer from your intent?

SPEAKER_00 7:34

Um gosh, I'm been I've been doing so much with it even in the last days. Um missing a direction, missing something that we already had working. So, like just now uh I was showing you something and it was a really cool little animation thing that it that it did before and then all of a sudden stopped. I'm like, why? Um or after a lot of conversation about some particular topic and making sure that we actually really are on the same page that it doesn't do it. So it's basically like repetition, repetition of something. Um but then I get the other side too, like delight, you know, all these things that you know I can say what I want and have a conversation. Plan mode is huge. It's huge, huge, huge um uh going in and out of plan mode all the time. Um yeah, but I I guess you're talking about the negative part, I'm thinking about the positive stuff.

SPEAKER_01 8:23

Um rage coding that's well that's that's what I'm getting at though. Like the engine, the fact that you can actually truly engineer, you can think about a problem, we can do some research, we can come up with some potential solutions. Yep. Um the promise is that we would try a whole bunch of different things, and because it was very inexpensive to try these these crazy options, yeah. I don't, from my experience of watching people, I don't see people trying a lot of things. I feel like there's a a lot, what are they sunk cost fallacy, lost what what is that?

SPEAKER_00 8:53

Lost costs, lost cost, sunk cost fallacy.

SPEAKER_01 8:56

Sunk cost fallacy, that one. Yeah, I still feel that that's a human trait, not an AI trait. And I don't think everybody when they're coding is is putting the time to say, you know what, let's rip this all out. And instead they're trying to recrit re-retact the boat and get it back on track again. That makes that's when you get a lot of slop, a lot of mess.

SPEAKER_00 9:16

And do you do you periodically do that on your projects? Because I do. Like after a whole bunch of little small changes, I'll say, okay, start fresh, refactor, think about the whole thing, what you know, talk about all these things that are a mess. And then how would how would we do this now if you if we knew everything that we know now at the beginning?

SPEAKER_01 9:35

And that's one of my first points here is one of the first thing we can do now is we can not try to build a V1, not try to build a proof of concept or a V0, but what about building a V minus one, V minus two? So instead of going and saying, hey, I'm gonna build something and I'm gonna put all my research, and this is really a hard one for me to get my head to, you know, make my natural tendencies to want to do a ton of research, but just go for it. And this is where the quote vibe coders have a significant advantage over developers, over programmers, because they just go for it. Just start and yeah, and at the end of the day, even if they've built a a big dog pile of stuff, code in there because it's been ripped out, it's been new pieces put in, and they have no introspection of what's going on under the hood, you can point that whole thing at another LLM and say, hey, rewrite this, clean it up. Yeah, yeah, yeah.

SPEAKER_00 10:29

I don't know, I'm gonna push back. I I you know, my whole entire Filmaker career, I have started a project by diving in. Because I I firmly believe that you can't, it's not possible to know at the beginning of a project the the the actual build. And so by uh by starting and having a thing, a bunch of things that you can easily kill, um create a table, create a relationship, do it as you're talking through it. It's like, what about if this do you need you know this joint table here? No, okay, we don't really need that, so we just rip that out. It's like, oh, you know, you know, here we do need that joint table. It wasn't there, so you just create it, populate it, kind of go on. Um like what kind of a script thing here? You know, basically the the conversation with a client and live development, which is how I've always loved to work. Um very much is that kind of that vibe-coding kind of thing, right? You're throwing yourself right into it. Do you is that not the way you've usually worked? Do you plan things more and think about things more?

SPEAKER_01 11:28

Well, no, I want to plan things out more. What I'm saying is that that may not be better. And this is a hard one for me to swallow, but you know, it's uh I think it's a somewhat of a fact. Is there is some benefits to just going for it and and creating or building by the seat of your pants. We did that in FileMaker for decades, and we people still do. Um and I think we're gonna do that even more once we have our agentic tools. Yep. And I don't think we'll plan things out. I think we'll just, hey, I need this, and who cares what joint tables, what tables it makes.

SPEAKER_00 12:03

And well, before it was really expensive to clean up after you delete something.

SPEAKER_01 12:08

Correct. It's not refactoring is cheap.

SPEAKER_00 12:10

And so this is one of the things that should be on your list, right?

SPEAKER_01 12:13

It is on my list, yeah. So the ability to refactor. So the ability to plan is the first one, right? To to engineer the plan that way. Yeah, we got the little our little yeah, you might have to.

SPEAKER_00 12:23

I think I might have to mind turned off.

SPEAKER_01 12:25

Um other. Yeah, go to the plan.

SPEAKER_00 12:27

And it's kind of funny as you say that because like I said a minute ago, I really do go into plan mode a lot, which then forces me to not just be Did you do that from the beginning?

SPEAKER_01 12:35

Or did you start into that after you made all the mistakes? Oh, uh mistakes. They didn't have plan mode, you know, six months ago.

SPEAKER_00 12:43

So I I I um I code like I would play jazz. There's no such thing as a mistake. If you play a wrong note, play it again and call it jazz. Yeah, that's right.

SPEAKER_01 12:51

Repeat it, yeah. Um that's it, yeah. Bend it up a bit or something, yeah.

SPEAKER_00 12:55

Well, I don't think I would say it's for mistakes. I think I would say I've I've real recognized that I get much better results if I go into plan mode at various stages. Gotcha. So it's a little bit more. It forces me out, and then it I get a bunch of little questions like, Do you want this? Here's four choices. Which one of these do you want? I recommend this one. And I'll have to stop and think about it. It's like, I guess that does make more sense than what I was thinking, or you know, types and response. I'm in there up many, many times, I think, uh in a session. Yeah. So do you have a list of things uh that I want to look at of things that are that are easy now that used to be hard?

SPEAKER_01 13:35

Because I have maybe so I mean those are those are sort of high-level organizational things, right? Um, one end is the planning and the other end is the refactoring. Those are those bookmark or or uh bookend the the the all the other stuff. The next one is is the concept of conditionals. Um you know, we can throw a conditional path into something and say, you know, if the user is, if we're on dev our dev server, if we're um if it's uh if it's me, the developer, or if it's on the north location instead of the south location. We could do that before, but it was a bit of a pain. Um now what we can do is we can take an organizational structure like a JSON object and throw a bunch of flags as keys, like can access page X, can do uh thing Y, right? True false, number of total number of sessions per day, five. And we can take that concept and throw it, throw it at our agent, and it will now be able to create some code that we can release so we can ship more faster now because we don't have to worry about, oh, I have this thing that's I've half taken apart and accounting is gonna see it, and they're gonna click on that button. It's gonna I wrote our script that you know erases all the thing, all the data, so I can reset it each time while I'm testing it, and they'll accidentally click it. I don't have to worry about that stuff anymore. So we can we can add a lot of those flags or gates um into our code and effectively even leave them there. Um we years ago we made a module called ham, which is a headless authorization. It's uh I remember it. It's a concept. Yeah, it's a concept of basically a JSON object. And it works so fabulously with with LLMs because it's like, oh yeah, I totally understand this, because it's just a a bunch of key values, right? So that's one of the that's another thing there. The next one is defensive coding. The LLMs tend to overly do this a lot of times, and you know, you've probably found this yourself. You're you're developing something, and then you change, and you know this is this is like version 0.00001, like you know, 10 minutes into a project. And the LLM doesn't realize necessarily 10 minutes into the project, and it says, Oh, I see you've changed your mind on this. You wanted this to support um the colors, like uh the the noun of the color, the the name of the color, like the red, green, blue, and now you want to turn it to a hex value. Oh, I'll just add support for both of those now, right? And the LLM throws up throws up this support and it's like overly, overly guarded, just in case you go back and change your mind, which you're never gonna do because you're in development mode. And you can kind of tune a little bit out of that out with some skills, but it's still tensor.

SPEAKER_00 16:17

Okay, like overly defensive, would you say overly defensive coding?

SPEAKER_01 16:21

It's overly defensive, but having said that, you can also take your regular file maker code, which probably isn't the best. Like I worked with a developer years ago, and he was very meticulous, right? I worked with a number of different people, and you know, uh in our careers we we pick up these different things. I um I used to be an electrical engineer, and and uh my first four years working in the lab, the senior engineer we did RF engineering, and I say, Okay, I built this thing, I built my project. And he would look at it and said, What's the value of this capacitor? And I say, uh, you know, uh 20 uh picofarats, 20 puff. And he goes, I want temperature. I said, temperature, it's working totally fine. Well, temperature coefficients are a really important thing, right?

SPEAKER_02 17:07

Yeah, just it's gonna be in outer space.

SPEAKER_01 17:09

Yeah, exactly, right? And he would rip me, and then have you checked the price of that? And all of that's really taught me the fundamentals of of engineering and speculating. And I hated him for it, but I've since made up and I every couple of years on LinkedIn, I go and send him a thank you. Um, but nonetheless, um what we can do now is we can we can say to our code, you know, look for errors or look for ways of making this more robust. Or every time we have a failure in something, we can point it, we can throw it at our whole code base, walks through. Oh, I see you're running perform script on server without wait, and you're also doing this. It's possible that this thing here can, if it gets slow or it's if it slows down, you have a race condition. All right. And suddenly the our LLMs are gonna be able to see that, or or our agents that can see that that race condition way better than we ever could. Because we have to understand that concept of a race condition, right?

SPEAKER_00 18:08

And if you've never made multiple thread type applications, briefly defined that for those for those uh out there, including me, who maybe not don't know that term or don't know by that name. Race condition.

SPEAKER_01 18:20

Yeah, so so a race condition is like a running race, uh a speed thing. And basically, when you have two things that can happen at the same time and one thing finishes first before the other one, that may cause some type of adverse uh um reaction, like it could lock a record or it could uh grab a value before it's incremented, for example. You have something that adds a number onto the invoice, right? So they they happen at different times.

SPEAKER_00 18:44

Yeah, so like LMs are the if the output of the thing that's slower is required for the input of the thing that's faster or something like that.

SPEAKER_01 18:51

That's right, they're coding, they're they're they're dependent. And because of that, or or one thing locks up the other thing as well. And I'll I'll talk about that one in a second. So that kind of stuff for that type of defensive coding, we can do really easy now. We never could before, but you have to be thinking about it. And fortunately, the LLMs for a lot of these items, the LLMs will start to um they'll they'll mention, hey, you have a looks like you have a race condition. It's like, oh, it's teaching me, right? About about these things. Um, so you you suddenly don't have to be the senior engineer anymore, which is pretty cool. Um, another big one as well, and you mentioned something just um at the at the beginning of the uh of the of the podcast. You you mentioned that you built something and then you changed something, and then something else broke. Right? And that happens in a ton of ton of um AI code. Sure.

SPEAKER_00 19:41

Regular code.

SPEAKER_01 19:42

Yeah, and and um it used to happen more when we reproduced, like going back, say uh late 2024, early 2025, most of the strategy was you would reproduce the entire piece of code, almost uh like you go into Chat GPD, redraw all of that code. Right. And depending on the type of harness that you have, um, the um the agent can will will either target a specific line, less likely to change other stuff, better option. And that's what they all do now, like a diff patch, or they rewrite that entire piece of code. Whenever you're rewriting the code, there's a higher probability that it's gonna rewrite that. So, how do you how do you prevent that? And this is something we don't do with most vibe coded things, but we do with ingenic engineered things is write tests, right? So TDD or test-driven development is a concept where um you're basically true. TDD, you're writing a test and you're saying, I need this invoice uh counter to increment by one every time I create a new VAT record. Okay. So the test will be check the initial number and then check the number and did it increment. Do the thing and did it increment. And you didn't you haven't written the code for that yet, so it's gonna fail. The test fails, so it's red. Then you write the code. This is how this would would work. You'd write the code, and then you would run it again, and then suddenly the test passed. And then you would say, Yeah, but the number can't be negative, like the number can't be um, it can't exceed uh six digits, it should wrap around at this point. So you'd write tests for all of these little weird edge cases. You can do the same TDD with virtually any piece of code now. So you can do that with even um like HTML and and um any code that you got you're gonna render in the browser. Uh, you can you can have there's test suites for that. There is unit testing, uh, which is which is the running of all of these little mini tests put together. There's integration testing, which is how this thing works as a system. There's UI testing, which is let me actually run the thing, click on the parts. Is it loading? Is it working?

SPEAKER_00 21:49

Every single thing you're talking about has been like not possible in FileMaker, pretty much. Yeah. Yeah. Um But it's been possible from a display.

SPEAKER_02 21:58

Or not easy, yeah.

SPEAKER_01 22:00

Some of them have been just straight up not possible, but um like we um there's been there's been people who've made attempts at test suites for FileMaker, and we have an internal one that we use, and it was never getting maintained because it's brutal. I for every script I write, yeah, that's 20 lines long, I'm writing 60 plus lines of test. And it's like, wow, because I have to write test all of these edge cases, right? Like over, under this, that. Yeah, and that's it's really, really brutal. Well, our LLMs, our agents love doing that. That's not a problem at all, right? So we can say, hey, I I don't have any test suites for this. You don't even have to know anything about the framework. Yeah, and it and if it's well, I don't know how to test do a test suite with that. Well, I won't actually say that, I'll come up with something. But you can just say that to your agents and it'll create that set of tests. And you can do this with file maker scripts, and you can have it write file maker scripts, you can have it. Yep, you can you can if you really want a great uh vibe, this is an awesome project for anybody, is go to your LLM and say, connect through the O data. Um, first of all, here's a copy of all my scripts, right? If you don't have a Gentec framework that can see the scripts, give it a copy.

SPEAKER_00 23:15

Or save as XML.

SPEAKER_01 23:16

Here's my yeah, something like that, right? And say, I want you to test the SNOT out of this thing. And here's how I want you to build the framework. I don't want to build all these ugly tests inside FileMaker. I can maybe put it in a second file. Why even bother doing it there? Right, quite honestly. Let's put it in some standalone file. I don't even care about the language or whether what it does. Hit hit the OData API, run the script, give it the parameters, and say any scripts that are not easily testable, I want you to add some extra arguments. I want you to either exit with the script with the the result or some some uh error trapping um and so on. And then suddenly you have all of FileMaker, and somebody will at some point um create an entire uh test suite. Um that's that's more or less AI generated. That's a a great opportunity or an idea there.

SPEAKER_00 24:15

I lost you for a little bit there. All right. Um I have a call and I didn't think that blowing my nose on camera was uh was befit of a person of your stature. Yeah, that's it. Um I'll try to keep my fingers out of my ears and those, so well I mean I got a mute button. So um can you show me the list that we started with? Or just before we started? Because I got a lot of things.

SPEAKER_01 24:45

Let me let me I'll just let me just condition it off here. Just a sec. All right, so here's a few other here's a few other little things here. So we're on defensive coding and test-driven development. Error handling. Error handling is a kind of an interesting one, and let me show you what I mean by that. Um, we can just say to our AI uh uh trap for some errors, but we can do something a little bit different. I'm just gonna pull up a slide here quick for a second. And let me just see if I can find the proper one. And um one of the things we can do now that we couldn't do easily before is create really, really rich, rich errors. And I'll show you what I mean by that. All right. So here is a simple result for an error. Right? And you know, if you're doing this in your system today, that's awesome. Like you're actually creating real error objects that have some type of a code, typically number uh code, or could be text code in this case, inventory insufficient, a message that's human readable, and a Boolean that that indicates that did this thing work. Sometimes you combine that with the code. Right? So that's something you can you we can we can do. But the beauty of this is now we can create an error that looks like this. And for those people who are just listening, the the first error was a JSON object, and it was failed. Three lines, yeah, three keys, a success, error, code, and message. Yeah, the second one is a rich message, so it has it's a bigger object. Let me just go back. There we go. It has a subobject. It has the rich yeah, it has all the same keys. Yeah, so it's backwards compatible, but it has a ton, a ton of other stuff. Now, why do we want to throw all this extra stuff in? The request ID, the suggestion, the documentation, right? All of these things that that the LLM can fire into your code easily is because now when we're debugging this, we can throw an agent at our debugging process and it can see this and it can zero right in really quick. So that rich error suddenly becomes exceptionally useful in your system rather than a simpler error.

SPEAKER_00 27:08

Yeah, in other podcast episodes, um, we've talked about a system like this um that can actually read all of these error codes and then go back and figure out where where in your code that error was caused for that user. And then maybe even fix it, which is some serious next level stuff. Um, but really cool. Um but anyway, yeah, that's that's definitely in line with that.

SPEAKER_01 27:34

And if somebody wants to get started with that, just literally say create a rich error code. That's gonna be your your sort of your buzz buzz line there, right? Create a rich error code with lots of information so I can use five-word prompt. And even if you're not having the alum do it, the human can see it. Oh, it's this particular invoice. Oh, it's it's it's uh Jennifer's machine. There must be oh, she's on version 17, or you know, whatever that is. Right, right, right, right. I mentioned earlier message cues. This is something that um that is is uh it's a really big thing in in uh applications that have to scale, right? We're building a new product, uh, another product, it's a companion product or uh Clay Studio. And we'll talk about that at a different time. But it has um message queues that are designed to support you know 100,000 per second type events, right? So that's a crazy number of business. The system is designed to scale, right? And it's a whole different, we have to sort of think about that from ahead of time and say, okay, this is where the the pinch points are rather than running into them. Right. Um, so a message queue for everybody is basically it's a simple table that if I have a bunch of stuff to do and I only want to maybe run one thing at a time in those things. For example, I have to uh do an API call to uh a mail uh server and that has a rate limiting on that. I can't send too many emails at a time. So that means I have to queue up all of those messages if I happen to do a batch of 10,000 found set. Right. I can't fire that off to my uh um transactional email provider because they'll they'll they'll maybe lock me out, depending on how how the data is structured. Uh simple example. So the message queue basically takes, and by the way, the email is not just the message, the message can be anything. It can be create a record, delete a record, it can be any any kind of process. It doesn't matter.

SPEAKER_00 29:32

The stuff I've done is actually just communication between different agents, even.

SPEAKER_01 29:38

Absolutely. Um, so the idea is you have a simple table, and you don't you you don't have to even really understand it, but just so you so for so people can can sort of wrap their head around it. Then you have a message to is you have a table, and then you have a um a workflow or a thing that has to happen. Uh send email, delete invoice, uh run run report generation. Uh and then you usually sometimes those message messages can have a schedule. So I want to do this every day, and that does message usually doesn't delete from the table. Or if it's a one-time thing, I put it into the table. And if if it tries to send the email and the email fails, it might even have a retry field. I can retry this up to five times before I fail, before I error. So you can create these. It sounds like you have a rule system in there. It is, it is. And you can also you can build this into an even more complex thing is um to say, after I send the email, I want to log. So I want to call my logging routine, my logging script, with the results. Yeah. So that now you say, what do I run next after a given a given state? What do I run next? And after that, you send email state, I run something else. When you start building it out like that, it becomes what's called a pipeline. So there's a little difference between a message queue and a pipeline. A pipeline is a bunch of messages in a queue. The pipeline is a little bit different. So that's something that's that's really, really cool. Say, okay, well, how can I use that in my, you know, we build uh we build coffee tables and we use FileMaker to run our system, right? Anytime that you have a system that's running and it starts to fail for some reason, and you have to go either in and retry it, or too many things happen at a time. Like running reports can be pretty uh computationally expensive on a machine. So maybe I don't want to run that report every every time somebody clicks a button. I want to throttle it, right? So there's concepts called like debouncing or or throttling, and that'll maybe rate limit those types of things. So these are all sort of sort of buzzwords, if you will, that you can start to incorporate into your system. But if you know that there's a way of solving this problem, you'll be able to prompt your agent into solving the problem rather than letting the agent lead you, if we think of it that way.

SPEAKER_00 31:57

Yeah, I like that. Now we get to two really interesting things, a couple of things that I feel sure a lot of people don't know.

SPEAKER_01 32:07

You know, they're not hard to build, but it's so much easier now. Yeah, I know.

SPEAKER_00 32:12

I was just looking at the next two things on your list, is what I'm talking about.

SPEAKER_01 32:14

Yeah, I'm gonna get I'm gonna let me just pull up pull up one of those here. And the next one. Mutex. Uh actually, I'm gonna go idempotency first. Oh, okay.

SPEAKER_00 32:25

All right, yeah, I've been seeing that term lately.

SPEAKER_01 32:28

Yeah, and you'll see the ale llms throw it out. And and I swear, you know, all these LLMs are everybody's, you know, they're all they're all first of all, they're all measured by benchmarks, right? As we know. Yeah. How would you pronounce this? This is in uh idempotency. Idempancy. Not impotency. Yeah, well, it's different.

SPEAKER_00 32:45

Yeah, it definitely comes up in a lot of spell checkers.

SPEAKER_01 32:49

Yeah. Here's the concept is when you have a system and you run a process, you run some kind of you have a script, and the script has 10 steps. First step is it creates an invoice, second step is it uh um calls another subroutine that takes items out of the inventory, the next one is it uh charges a credit card, and the last one is it logs it and sends an email, maybe the other way around. Right? So you have that workflow. Well, what happens when and uh it's taking something out of inventory and the record's locked? Oh, yeah, yeah. We have uh record locking and uh and um management that way, but it still fails, right? If somebody else is using the record, if some other system is doing that, so we need a way of of fixing that. Um so we want to rerun, we want to rerun that workflow and not have it take the inventory out twice, not have it send the user if the email failed, but it uh and we click it a couple more times, the button, we don't want that to send the invoice out too many times or charge to a credit card a whole bunch of times. Right. So the idea here, and this is just a graphic on the screen for people who are listening, is you have a button that says send a welcome email. It runs to the server, and then when every time a user clicks a button, it sends it, sends the email. And everybody has one of these in almost every file maker system. They got some simple workflow that, oh, you just click the button on this screen. It's a big blue one here. I made it bigger. Yeah. Right? And it does some communication or whatever.

SPEAKER_00 34:22

Yeah, yeah, yeah.

SPEAKER_01 34:23

Yeah. So by adding idempotency, you basically can click the button a whole bunch of times, but somehow the system has remembered that a successful email was sent to the client. And suddenly you have this way better experience for the uh for the end user, like the client uh on that side or the person who's receiving it.

SPEAKER_00 34:43

I mean, in Final Maker, we would have solved this by like having a date, having a timestamp field in the customer record that says date, you know, timestamp welcome message sent.

SPEAKER_01 34:53

Or maybe some error traffic. Yeah.

SPEAKER_00 34:56

Yeah, some error or is sent, right? So I would always say that. Yeah, and that's exactly what this is. But you can now. It feels like it's more than that because you've actually got you've actually got a um I looking at the chart, you've got something in the middle, right? A server that's tracking a key store that's actually tracking a well, this key store here. Yeah, yeah, yeah.

SPEAKER_01 35:14

Your timestamp. That that is your timestamp. So you basically you're remembering the state of this thing that's happened. So you have another table though, yeah? Maybe? Well, it's it can be a key. It's a field, it's a field in somewhere. So in this example here, this image is uh a user on the left clicking a button and the user on the right receiving two emails. Right. And then when you fix this problem, the user on the left clicks the button twice. We remember in the server, we have some state there, whether it's a timestamp, a Boolean, uh a separate table of what got sent, somehow there's a piece of information that's in the in the server that indicates I shouldn't send this a second time. And that's the uh that's the main that's the main concept there. Okay. So if you even if you can't remember the word, if you can remember the concept, I I don't want this to happen. I want to make this this system idempotent, then Yeah.

SPEAKER_00 36:10

I I really think that this is something file maker developers have been doing all along and didn't maybe know Oh, they can, absolutely.

SPEAKER_01 36:17

But do they have been?

SPEAKER_00 36:18

I have been.

SPEAKER_01 36:20

They have been after some complaints, absolutely. Right? But I can guarantee that blue button didn't just naturally remember all of this stuff. Somebody clicked it twice, probably. Right. And I'm I I'm sure that I've listeners, there's some people gonna say, yeah, yeah, I got it. I got a few of them.

SPEAKER_00 36:34

I guess I'm I guess I'm just thinking about like what I would do. I mean, I've got 40 years of development experience, Charles. Uh yeah, there's certain mistakes I stopped making a long time ago. Um and there's certain other ones that I continually make.

SPEAKER_01 36:50

Whatever. And and hopefully that's one of the benefits of what we one of those things that we can do today is not make so many of those same mistakes.

SPEAKER_00 36:59

Yeah, but it seems like in that particular example, you'd actually probably want to make sure your testing and your prompting specifically builds the system with that in mind. Because it may or may not automatically do that.

SPEAKER_01 37:13

Correct. Generally most things don't, right? It doesn't always do that. If you're planning it out, you can review your plan and and you know, beat up your plan a little bit with with various sources or agents, and then you know, you might discover that. And this is one of the things that makes an agentic engineer versus a vibe coder.

SPEAKER_00 37:36

Yeah, right?

SPEAKER_01 37:37

This is a very subtle difference.

SPEAKER_00 37:38

That's a good, yeah, that's a really good, like uh, I wouldn't say dividing line, but a trait.

SPEAKER_01 37:46

It's the knowledge, right? It's the knowledge of the system. And I think that was, I mean, everybody can, I think everybody, even if you're not technically minded, you can probably figure out how to change the oil in your car. Like, okay, there's a nut at the bottom, I pour the oil in at the top, I don't do them at the same time, right? That's fundamentally an oil change.

SPEAKER_00 38:03

Yeah, make sure you put the make sure you put the uh you know, the container at the bottom to catch all the oil.

SPEAKER_01 38:09

Yeah, yeah. But I mean, that doesn't that's not even needed for an oil change, but that's an experience thing, right? How do I undo the nut without getting oil all over my hand? That's something that's a trait that a mechanic knows and somebody who's a little bit more skilled, right? But they've probably undone that nut the first time. It's like, oh frigate's running all down my arm and my elbow, and you know, I smell like that for the rest of the day.

SPEAKER_00 38:30

So you change the oil in your own car? Do you?

SPEAKER_01 38:33

Hell no, no. I don't even get out of my car when I change the oil.

SPEAKER_00 38:38

I pull up to the they come up to the door and that's it. Yeah, I'm hyper lazy. My brother was an auto mechanic, but I think I I'm trying to remember if and how long I've changed the oil in my own car. It's a long time. Anyway.

SPEAKER_01 38:51

You know, I have a I have a full set of suite of tools and a great garage for doing that. My son does that stuff, but I don't I don't bother. I I ain't got no time for that.

SPEAKER_00 39:01

So all right. Next. Yeah, I like this one. And here's another great term. Here's another great term, mutex. Or my mutex too.

SPEAKER_01 39:10

So this is kind of a this is one that's super file makery. Like the other one was super file maker-y as well, right? Yeah, um, because they almost all relate to workflows and systems. And um, so the concept of of uh mutex is that when we're running some kind of thing, something that, for example, takes the inventory out of a system, we generally want to run one thread for that thing. So if I have something that has high volume and we got six locations, and uh, probably everybody who's built really big file maker systems has run into this kind of a thing. Yep, and people are pulling stuff out of inventory. How do we truly accurately control that inventory and know so many uh uh items have been taken out? Or banking is another common one of this. Anytime we're where multiple sources can be potentially uh manipulating the data, or um, we can potentially get multiple threads, and this is the same thing but in a different spin. Uh the same multiple threads of manipulating that data. So what the mutex does is it it's mutually exclusive. Um mutex. Yeah, I think that's what it is. Gotta be. Uh I I think so. Yeah. Um, and basically the the gist here is that you allow only one thing to do the thing that you're supposed to do.

SPEAKER_00 40:36

This looks like just straight up transactional processing.

SPEAKER_01 40:39

Very similar, yeah. But it's workflows as well. Like transactions, we think we still transactions we associate with a record, usually, but a workflow is the same concept. I don't know.

SPEAKER_00 40:50

I wish I was associated to me, I always thought of a transaction as kind of like a bank transaction or something. It's a whole set of things. It's not it's not just a record um that you're making sure that that record gets edited. But like in your example here, at least in my mind, I've always thought um you know, you click a button to create invoices, to create an invoice, it you know, looks up a bunch of products, checks the SKU of those, checks the qual the quantity in stock. Um uh yeah, available, then uh you know, creates the line items, rechecks the quantity in stock to make sure that someone else didn't check it out and make sure that they're correct, and then commits a transaction. Otherwise, it undoes the whole thing.

SPEAKER_01 41:34

Right.

SPEAKER_00 41:34

Yeah, it looks like your chart here.

SPEAKER_01 41:38

Yeah, it's it's the same same concept. We do this all the time. It's super file maker-like. Yeah, yeah. But it is uh that concept as a as a programming primitive, if you will, is is has a name to it.

SPEAKER_02 41:53

Yeah, okay.

SPEAKER_01 41:53

And by understanding what that thing is, we can describe it better. You know, it's just like having a better vocabulary of uh uh um of terms there.

SPEAKER_00 42:01

Yeah, I think all of these things are going to be filing under all these things we've been doing along as FileMaker developers now. We can have fancy terms for them. Use them with our clients to make sure we're we seem smarter. We should come up with a list of those, Charles. Except when the clients get confused, like the whole benefit of filing. That's what we're here for. The benefit is we can put things in plain English, you know. Anyway, yeah, I like this. It makes it definitely, definitely makes uh a big difference. Um, where does this come in with AI? Is this also one of those things that you want to like make sure is testing or make sure you're yeah?

SPEAKER_01 42:33

Well, it's something that we can say to our system, hey, I'm having this problem. It only happens once every 10,000 runs. Uh a number of years ago, I was doing a consulting gig for Dell software, and there was a company that Dell had bought and uh the software division, and um, they ran their own um file maker systems, and they had four, I think, uh four file maker servers. And at the time, WebDirect only scaled up to I think 50 uh users, and they had about a thousand user sales agents. Um 50 concurrent users, yeah. Yeah, yeah, concurrent. So I built a server synchronization system that syncs synchronizes these servers, and they had a lot of traffic, right? Because it's they literally have an average of 100, 150 people on it online at any time. They're all hitting all of these similar accounts and things and and whatever. And every three days, uh piece of information got screwed up. Yep. And like, holy cow, how do you find that?

SPEAKER_02 43:40

Right?

SPEAKER_01 43:41

I like that's a hard thing. You know, that took me a week to to track down. I knew what it was. It was a hole in the and um I visualize it like a like a deck or something that has a little slot, and you have you know, synchronizations, you know, the expression is two hard things, naming in programming is naming things, and and cache invalidation. Which is effectively sync. Sync is can be really, really tricky. Yeah. For sure. And you have these demarcation times, right? But even when you set the demarcation time to the next f f physical script step, there might be some time that's elapsed. There might be a tick or two that's happened in there. A microsecond, 20 microseconds, or you know, millisecond even. Right?

SPEAKER_00 44:25

So you have to your audio just cut out. Test one to you. I still don't hear you. I am training.

SPEAKER_01 44:39

All right. So all right, I'll just just go back here. So you have these these days demarcation times using an example of a sync. And maybe people at home can sort of uh um wrap their head around something similar, um, similar concepts, where there's suddenly there's this little tiny, tiny millisecond or less space in your function that's something else probabilistically at you know 20,000 transactions a day over three days, you know, or uh something like that, or over a week, you have a hundred thousand transactions that it just you know one one shows up. Yep. All right. How do you find that? Right? Like how do you go and and find that little thing? You really need to start to understand some of these concepts. But if you can say to your to your agent, hey, this is the problem, I think it's a race condition. I think it's it's um it's uh a dependency problem where something else is writing there, or maybe it's one of these things, or maybe it's something like that. I use a lot of vague terms with my with my LLMs a lot. Like I'll I don't usually say a statement, I put a question mark like and that and that way it doesn't bias it. I find anyway. It doesn't bias as much into coming up with an answer.

SPEAKER_00 45:56

I try to put a question mark, but it almost always ends as a slash because my typing has gotten really bad. Uh yeah, well, mine's already read through it can already read through so many errors, I just like let it go. Who cares if I misspell something? Not good, but anyway. So I get I get this, right? This was hard and it's now easy.

SPEAKER_01 46:16

Yeah, putting like building higher quality code is now significantly easier. And it's not that the first iteration of the code is maybe super high quality, it will be probably better. I'm gonna go on a limb and say that it will be better than what you usually write um the first time, like the first round, unless you're really, really strict. But the iteration now, when we find the error when we're looking for the mistake, and we're we're we're creating a version 1.1, or we're doing that little edit from a bug report, is gonna be significantly better now, right? Because we're not gonna be guessing as much, right? We significantly reduce the the amount of guessing that we do there. Yeah, like yep, true. The last one is something that I think some people in the FileMaker land are doing already.

SPEAKER_00 47:10

And um more genuinely new. So this is add an agent to your domain.

SPEAKER_01 47:15

Yeah, so that is the next one, and it's to I'm just gonna get rid of this here, and it's to um to add an agent into your administration workflow. So every time you have to do something like, oh, I gotta call Chad, he's the IT guy who's runs the system, and he goes in and he fixes it for me. Right? That's probably a bug in the software that he had to go fix. Right? And he usually goes into his admin workflows to do that. But now you can create an agent and it can connect to FileMaker various ways, MCP, O data, whatever. That's that's almost trivial now. But the agent can go in and it can it can do those workflows. And I wanted to show you. Let me just see if I I'll show you another agent. Let me just see if I have this running here. Just give me a sec there. And it is a um does or pardon me?

SPEAKER_00 48:24

Chrome agents or cron? Did you say sorry? Cron, cron jobs. Like oh, oh, um no.

SPEAKER_01 48:31

No, these are these are just uh a chat widget that's talking to my data, but from an administrative perspective, I'm looking at it at fixing issues, diagnosing things. And unfortunately, I wanted to show you one more, but I don't have it up and running here. It's probably gonna take a while. Um, so one of the things we're doing is we are we are building um in our administrative in our products that we're building, we have, you know, there's usually an admin or something. I I need to to do this thing, a special request support thing that I don't have built into the main software. So what we do now is we're putting an agent, a chat agent built into the software and the admin panel. This is another step up from this this one here. And the idea there is it has access to all of the data, all the tables. Um it has uh it understands understands the layouts and the things that are on the administrative layout that I'm looking at. And by doing that, let me just see, I'm just trying to see if I can get mine up and running here on the side here. By doing that, when I have a support issue, or I need to make a change to some fundamental data that's in the system. For example, we have an email template, and the email template's stored in a record, and I don't have maybe a necessarily a great UI for that, or I just sure I just need to change the language a little bit so it's a little friendlier, or it includes a disclaimer at the bottom. I can now go into that that admin agent that I've built and prompt that to make that um make that change. And that's kind of the idea. This is a little, this one's a little bit harder, or sorry, a little bit more advanced, I guess you could say, um, than these other concepts.

SPEAKER_00 50:26

Well, it's it's of a different color, right? Because what you're talking about here is is uh an agent that actually actively manages data in the database rather than like uh you put it really well. You don't have a good UI screen for it. And it can it can use AI to determine if a thing is right. So if you go into a letter template and you can make a mistake and whoops, take out a couple of merge fields, uh an AI agent is less likely to make that error.

SPEAKER_01 50:55

Correct.

SPEAKER_00 50:56

Um so that would be a really good use case in like in in your example anyway.

SPEAKER_01 51:01

And if you have a log, if you've been doing the error trapping and and you say to your agent, create an error trapping log, you know, come up with your own system if you want, if you don't, if I don't have anything in my system, or you might know of uh a framework for error trapping or something like that. That's in framework that somebody's created. But if not, don't worry about it. It'll create a pretty decent one. And create this error trapping log. And now to my agent, and they again we build the agents and new stuff we build the agents right in. Older stuff, it's it's external and it talks through uh some type of an API. But you say to the agent, go check out the log and summarize, summarize these these uh problems. Uh or sorry, these problems. I'm thinking of uh uh support log. Um, summarize these issues, look for it, look for problems in my support log or my my log in general, and give me ideas on how I can fix it. And if that agent can see your code now, that's a massive loop closure.

SPEAKER_00 52:00

Yeah. Yeah, yeah, yeah, definitely. So that's uh testing, implementing.

SPEAKER_01 52:13

How how are we doing for time? That's the whole big dive.

SPEAKER_00 52:16

Yeah, yeah, yeah. We're close to the end because we're I think we have to do that. Let me tell you, I'll tell you what. Several topics to start in future episodes.

SPEAKER_01 52:23

Uh yeah, let's let's uh let's come back and I'll tell you about some of the research we're doing. I'll tell you the topic though. Um we're doing a lot of RD on on um ways of introspecting data. So what we're finding is um using code as a as a first uh first example. You you mentioned that you're vibe coding a bunch of stuff, but and I see this all the time, and and nobody looks, I don't look at my code, my vibe code anymore. I used to look at the inspect stuff line by line, but I find that's almost impossible with the amount that we're generating. Right. And you know, we when we when we wrote the stuff and typed it by hand, I already knew it, it was sitting up in my head. Now I I have to zoom out a couple uh orders of magnitude there. So how do you the the gist is how do you go about taking a massive code base and understanding what the heck is going on in there, aside from just asking the agent. You can do that, you can ask the agent. But I need to testing, but the testing doesn't tell you there's cruft in there.

SPEAKER_00 53:26

Yeah, an adverse agent.

SPEAKER_01 53:28

Yeah, you can do that. So you can ask an agent to say go through there, right?

SPEAKER_00 53:32

No, no, it's an adverse agent. Like uh Adverse. Yeah, yeah, yeah. So like what I do on some other projects like that is I'll have my I'll do all my development in Cloud Code. And then I'll have, and it all gets to a Git repo. I've been using GitHub for everything, basically, and then deploying everything on Fly.io. Man, we'll talk about that. Um I've I've discovered Nirvana. Um in terms of like so many different things coming together. We'll end with that actually. Um uh but then uh I'll have a my OpenClaw machine, right? My Hermes machine, which is which is running um codecs, will take a look at the repo and specifically say, find flaws with this. What's broken here? And very frequently it'll find things that um uh are broken. And so it'll make it'll make a record in the communication table, um, the message queue, whatever you call it, send it back to Cloud Code. Cloud code will do a check and say, oh, you have a message from your adverse agent to fix something, go fix it, report back, okay, it's fixed, and then uh and then Hermes checks it again, confirms that it's right. So that's kind of my cue. That's only really for the larger projects, but I have definitely used that. And it's caught some really important things.

SPEAKER_01 54:50

Well, that's a that's a whole other whole other topic as well. Um I was just on a call with somebody, and they have their system API key vibe coded into the front end of their application. And I can't like I think not in an EMV file. Pardon me? Not in an ENV file, but like actually. No, because that requires middleware, right? Um, so that I mean that's one of the things why why you know people say, well, now you can vibe code an entire app. Where does Clay Studio fit into that? And it's well, first of all, we we have infrastructure, right? So there's zero deployment, there's there's version control, there's uh environments, um, there's security, there is known um design code patterns so that you're not vibe coding, you're not exposing a whole bunch of things. And if we if something does get found, we can pit patch it, patch it really quick because we're you know, we have a community to to to uh help us out there. And that's one of the things we're we're that we're we're shifting to. We're really providing governance, we're providing infrastructure, very similar to FileMaker in that sense, but for front ends. And now we're finding like our team is not even using our our editor for we're using mostly MCP because now we can point the MCP to other sources of data like Notion for our research and things like that. And by doing that, we take advantage of the best things of our platform, and the fact that I can go boom, boom, boom, and I have a system up and running connected to FileMaker hosted, and then I uh use a plugin like Genie to connect to the uh to the back end, and I've generated the entire system in relatively short time.

SPEAKER_00 56:35

Genie is a whole other topic too. You and I and Bruno will talk about that in an upcoming episode.

SPEAKER_01 56:44

So, yeah, so that's um that's those are um that's sort of like the the the the the gist there is how do you see all of that information? And yes, you can use your your LLM, another agent, to look at that, but how do I peruse it? How do I understand the flow chart of something? Because it's not generating that, it's not looking for the flow chart, it's not generally unless you explicitly prompt it, it's not necessarily looking for the optimum stuff. And I find it's not a great way of seeing into code. So what we're doing is we're researching on um ways of taking that large corpus of data, um, we distill it, and then we project it into various views for various users. So these are concepts of dynamic interface. Um, you know, in FileMaker, we have a few uh um uh Tony White generates uh some pretty cool uh um infographics, and he takes this big body of information, and an infographic is one of them. Take a big body of information and it's distilled down into the stuff that I personally want to look at. The infographic for me might be different than the one for you. So that's the fundamental concept, right? The information that somebody in HR sees from this application might be totally different than somebody from IT. They want to know the you know what API is it connecting to and so on. HR says, well, what documentation gets filed along that workflow? Totally different perspective of the same piece of software. Yeah. So that's something that we can uh come back and definitely talk to because there's some really super cool stuff in there.

SPEAKER_00 58:15

Yeah, cool. All right, I'll I'm gonna end with one little thing about my my workflow now, and I'd love to get your feedback on it. So um there's a ton of stuff that FileMaker can't do with AI integration. So I've been teaching classes for a long time on how much you can do by adding a page of code and into a file maker system and then have an API call, like one API call. So where's a zero shot, right? But there's a huge amount you can do with that. Um, you know, uh read a PDF, you know, chunk it out, chunk it, um, embed it, put it into a table and allow, you know, um search on it, create a photo, interpret a photo, um, check a record for compl um for completeness. There's a lot of these things like that. But if you want to do something like create a report uh that has uh circles and arrows and charts, uh whatever, and have it reference data that's not in your database, and or download data that's not in your database by going out and finding it. Create a relationship of tables that don't have a relationship in your database. That's not something that's possible to do in FileMaker, anyway that I can think of. So I've been building these apps. You're smiling like you think maybe there's a way. Anyway, so I've been building these apps that I deploy on fly, fly.io, which is amazing. Um, really inexpensive. It's uh you build a container, you're basically deploying a little Linux machine that either is continuously running or runs when you call it, uh, and then pauses. And it's it can be free. For a small service that doesn't do a lot of money, it actually is free. Um I have 20 different apps running in it right now, 22, I think. And my bill last month was $13. Right. And they're in production some of them. Um so inexpensive. So but what it can do is you you'd have a chat, a regular old chat, and um uh conversation with your data. So you say, you know, give me a, you know, look at all my invoices for 2025 and summarize it um by the top sales rep, but only show me for these particular product lines. Right? That would be hard to do in FinalMaker. Um so what this process does is it actually has all of the data synced to a local SQL database, in this case DuckDB. So we're talking about this, it's not necessarily new. Some other people are doing this. Um, like Marcel Moray, he's cut, he's been advanced on this. Um so it syncs all the data there, it keeps a cube, which is like a uh on there, which is like a data cube of a bunch of that same data in the invoice table and all the other tables cross-reference so they can easily do it. The the report runs on the duckdb data. So if it's a million records, it can slice and dice it instantly, which it's impossible to do if you do an MCP call. It doesn't matter how much you know it'll it'll process whatever, 100 records or a million, kind of the same, you know, time almost. Um and then create the report and show it to you. Uh and then say, oh, this is great, but I want to add this other thing and this other thing, and then I want to say, okay, great, make a PDF of the whole thing. Right? So now we're way beyond what you can do at FileMaker. And pretty simple. So this is this is a thing that I've built that's in production, it's called Pythia, P-Y-T-H-I-A. Um really easy to deploy. Um, but I wish it was easier to deploy because um it requires a fly account, and it requires um uh some way, and it requires you do it, you're you're doing your development, you're maintaining the source code actually in cloud code. So the point of this application is not that you can do all this stuff, it's that you have access to the source code. And if you wanted to do something else, like, oh, I want 3D charts, oh, I want multiple databases, oh, I want whatever. Um you just you just code it in and it gets added to the code and you can do whatever you want to do. Um this is the this is the thing I'm most excited about for in years that I've done because it's such a good little companion. And then it just keeps the data tables in sync, one-way sync, right? They're not the hard kind. Um through a couple of different message message uh methods for that. Uh and then it doesn't have any limits. Like one of the other things you could do is you could say, you know, download NASA weather data and cross-reference it with these reviews. Um, you know, cross-reference this with national holidays in Canada and US. Um and it just goes, oh, okay, I'll get that.

SPEAKER_01 1:02:46

And it goes to the agent on the well, that's the nature of that's the nature of vibe coding, right?

SPEAKER_00 1:02:51

Yeah, well, it's more than that. Well, I mean, it is that, but those are things that you can't do with FileMaker, right? FileMaker can't go out to NASA, download data, store millions of records, and cross-reference it on the fly, right? But this is something totally possible with this method.

SPEAKER_01 1:03:05

So it's interesting because what you've done is is the the first part of it is uh called a fast function as a service. You've created function as a service as a system that I can call and it does some function and comes back, or maybe not. No, I have an A for it. Yeah, and um but but by having it be a little bit more agentic, and now you can that workflow. I think you're gonna like our next product that we're we're coming up with. I can't talk about it too much, but I'll tell you after the call exactly what we're doing.

SPEAKER_00 1:03:40

Well, I'm doing a um class today, um, and I'm doing like a uh uh landscape of all the different file maker things out there. And there's like 30, 40 developers who have published tools for different aspects of AI. And these are just this, these are three more tools I'm introducing. That one is called Pythia, and I have two others in different areas. Um and they're all gonna be open source, uh free. And then what I'm hoping to do, you know, my my angle of my business, is to help people integrate them, teach people how to use these these agents. It's I don't think it's actually for for a regular file maker developer to really properly do this, you would need a um a GitHub account, and you'd need to set it up to automatically sync to fly. And just doing that in um cloud code is gonna cost it's gonna come with a lot of mechanics and a lot of stupid questions and a lot of how do I do this and whatever, because your machine might not have certain things installed in terminal, the process in Windows is totally different. And so in a half an hour, we go through all that crap. Um, and then it's working. And then once it's working, it's just working, you know? And then if you want to unplug it, there's nothing in FileMaker. There's nothing to delete. It's just uh this app is kind of like anymore, PoofCon.

SPEAKER_01 1:04:57

And I've always liked that concept of having the light footprint. I do certain things are good in certain places, meaning business logic, if then that if most of your business logic is in FileMaker, which virtually every uh FM system is, I think it's it's good to keep it there, unless that business logic is a totally separate standalone system. For example, if I have um if I have a system that can purchase online and then it takes care of uh uh payments and everything like that, then Shopify is great. Integrate that to FileMaker. So the business doesn't fully sit, all that business like doesn't fully sit in FileMaker, then it's fine. But when you start having process or workflows that are distributed all over the place, then you start to have all of these other potential problems, I think, as well, to keep your your head clear. So your system sounds really good because you've separated that. This takes care of this, this says this is what I want, it makes the call, that thing does it. And then on the on the um the code generation side, you already have your workflow, your your uh uh deployment pipeline built.

SPEAKER_00 1:06:10

And it's determinative, right? So it's not using AI to uh um to you know actually look and interpret the data, it's using AI to create a little Python program or whatever it needs to do to slice and dice it, and then using a graphic tool to show it to you. Um yeah, and it's a penny per prompt or whatever, so it's not not a big overhead thing. Um yeah, anyway, I'm excited about it.

SPEAKER_01 1:06:35

Yeah, that sounds really cool. Well, it's been great, man. I'm looking forward to our next episodes. Yeah, yeah. Let's uh I'll I'll uh let's let's plan something and we'll talk about that that data introspection because that's some really neat stuff. It's a we we um are really excited about that aspect alone, even so. All right, Charles, it's always a pleasure. Likewise.