As a FileMaker Developer, I often find myself onboarding onto new, and sometimes challenging, projects. As a famous character once said, “Life is like a box of chocolates…” and I find myself thinking about that every time I join a new project.
Recently, I found myself signing onto a new, and yes, challenging project, complete with all the formidable quirks one could reasonably expect.
Challenge Accepted
At this point, I think it’s helpful to provide a little context. Time context, that is.
We were just entering the early stages of agentic development. Not quite where we are today, on the eve of a brand-new day with the advent of the ADK tool. Armed with Claude Code, we now had a partner-in-crime, able to reason alongside us as we navigated an unfamiliar FileMaker database. We were also deep into exploring ways to export XML and bring it into our agentic sandbox.
Not Quite Master Control
I giggle every time someone mentions “Model Context Protocol.”
Poor sense of humor? Maybe. More likely a child of the 80s, who inevitably mumbles under his breath, “…you mean Master Control Program?”
During these early days, I felt a bit like Flynn from the movie Tron, setting his program (or in my case, agent) loose to work on his behalf. And while I wasn’t trying to uncover evidence of intellectual property theft, I was trying to solve a mystery of my own with this new project.
So, with some initial thoughts in mind and an onboarding meeting on the horizon, I set out to ask Claude to help me better understand the project ahead.
Wow
Four prompts, an XML copy of the files (Save as XML), and about 30 minutes later, I was staring at four PDFs. Three provided summaries of the individual files, while the fourth offered something of an executive summary.
And these reports had depth. Each was between 8 and 10 pages, covering what the files did, who helped develop them, how they connected to one another, naming conventions, relationship graph descriptions (think “Spider vs. Anchor Buoy”), and so much more.
Okay, I don’t want to be overly hyperbolic and claim some sort of Eureka moment here. But I did immediately share the results with my tech lead, and we were both taken aback by just how much information Claude had gleaned. More importantly, how much of it was accurate.
Armed with an ever-growing arsenal of new tools, I confidently set out to tackle my first task on this new project.
It Was Colonel Mustard, in the… No, Wait!
The task before me:
- Emails were being sent from FileMaker using HTML, and the way things were currently designed was very, very complex. And broken.
I looked at this task with a little excitement. Finally, something for my new friend Claude to dig into.
What I discovered was an issue involving multiple scripts, calling multiple groups of subscripts, referencing custom functions galore.
And so, with a little XML export here, some thoughtful prompting there, and within moments Claude provided me with a solution.
In fact, I was presented with a detailed breakdown of what was happening. Claude pointed me to a handful of scripts, explained how the emails were compiled, and identified the various substitution and placeholder strategies used to build the final HTML.
But here, as Claude pointed out, was the culprit. This section, in this script. Simply swap out this “Set Variable” step for another one, one that would overwrite the offending bug with the desired text.
And boom…Bob’s your uncle.
I couldn’t wait to tell my tech lead about this solution, almost as if I were revealing the answer to the board game Clue.
Like the movie, however, I would soon discover that there might be more than one ending. Or, in this case, more than one solution.
To Err…
Did Claude know that this file was designed to build HTML emails using tables to store records? That, depending on the type and content of the email, those records would help populate the final result? And that, as Claude did see, various scripts would compile everything into an elegant, finished product?
Tough to say for certain.
My tech lead knew…and very quickly, the better solution presented itself.
Instead of swapping out a single line of code, as Claude suggested, we used the process already built into the file. Rather than hard-coding a solution that would only address one of many possible results, we updated the record data in the existing email template tables (along with a few other nuanced adjustments).
Same problem. Better solution. And one that respected the architecture already in place.
What Did I Learn?
The 80s and 90s sometimes, but not always, make for the best metaphors. I’ll leave it up to you to decide if I’m right about that one.
Seriously speaking, even in those early days of agentic adventures, it became clear how important it was to caution your agent against falling in love with the first possible solution.
More importantly, it reinforced something I’d been told early on: the human/agentic partnership is what will make this future successful.
For all the speed, all the reasoning, all the research and insight, we still have a very important role to play.
To reason ourselves. To understand. To recognize context. To draw upon experience and institutional knowledge to help us choose the best solution for the next problem.
And sometimes, to remind our agent that the first answer isn’t always the right one.
Carpe Diem.
