For years, much of the most valuable FileMaker knowledge has been difficult to discover.
Some of it lives inside conference portals. Some appears during live streams and then disappears beneath hundreds of unrelated videos. Some is published without enough context to understand why it matters.
Some is technically correct but presented without structure, evidence, or a clear conclusion.
The problem is not that the FileMaker community lacks knowledge.
The problem is delivery.
A useful technical video should respect the viewer’s intelligence and time. It should begin with a real issue, build its case with evidence, demonstrate the solution, and arrive at a conclusion.
That is the reason we created the new ai2fm YouTube channel.
The story
During the development of ai2fm, we began appearing on established FileMaker channels and developer groups.
The format was usually simple: present a real problem, demonstrate the technology live, and prove that the result worked.
These were not short promotional clips. Some were one or two hours of uninterrupted technical discussion and live coding.
The response was consistent.
The ai2fm presentations repeatedly reached audiences well beyond the normal performance of the channels on which they appeared. This happened across channels of very different sizes, from small regional developer groups to some of the largest FileMaker training platforms.
That told us something important.
The audience was not responding simply because a familiar channel had published another FileMaker video.
They were responding to the structure of the presentation:
Issue → evidence → build → verification → conclusion
They were responding to real products, real files and reproducible proof.
They were responding because the material did not talk down to them, did not waste their time, and did not ask them to accept claims without evidence.
At that point, continuing to depend entirely on other channels no longer made sense.
ai2fm needed its own publishing platform.
The need
The FileMaker development environment is changing rapidly.
AI coding agents, native text IDEs, local language models, structured source formats, automated analysis and browser-based interfaces are no longer theoretical ideas. They are already changing how applications can be designed, documented, reviewed and maintained.
But fast change creates another problem: noise.
Developers are surrounded by announcements, demonstrations and opinions. It is often difficult to separate what is real from what is merely possible.
Our aim is not to add more noise.
Our aim is to publish evidence.
When we say that FileMaker 2025 drops a value from the clipboard, we will show:
- the original step;
- the raw clipboard XML;
- the missing element;
- the FileMaker 2026 comparison;
- the ai2fm warning;
- the recovery path;
- and the files required to reproduce the result.
When we say that ai2fm can transform FileMaker scripts into a deterministic text format, we will show the complete round trip.
When we say that a process is local and private, we will show where it runs and what data leaves the workstation.
When we find a limitation, we will say so.
The standard is simple:
Claims must be demonstrated, and conclusions must follow from the evidence.
What we are building
The ai2fm channel is not intended to become another large, unstructured archive of FileMaker videos.
It will be a technical record of the work.
The first videos begin with the foundations:
- the two-keystroke FileMaker-to-IDE round trip;
- verified FileMaker clipboard bugs;
- how ai2fm detects silent data loss;
- how missing values can be recovered;
- and how every reported issue can be reproduced using the published test files.
From there, the channel will expand into the larger ai2fm architecture:
- mass decompilation of FileMaker solutions;
- structured
.fmscriptrepositories; - script dependency analysis;
- relationship and architecture diagrams;
- Git-based development workflows;
- local AI analysis;
- private language models;
- and the transition from FileMaker’s closed development environment into modern development tools.
The subject is not merely AI inside FileMaker.
It is the transformation of the FileMaker development process itself.
What we aim for
We want every video to satisfy four conditions.
Respect the viewer
The audience includes developers with decades of experience.
The content will not assume that viewers are beginners, and it will not use complexity as a performance of intelligence.
Technical depth and clarity can coexist.
Get to the point
Every video must have a reason to exist.
There must be a defined issue, a visible result and a conclusion.
A long video may be justified when the work requires live construction or detailed proof. A short video is better when one issue can be explained in ten minutes.
Runtime is not the standard.
Value per minute is.
Show the evidence
The FileMaker community has had enough unsupported claims.
Where possible, videos will be accompanied by source files, XML captures, .fmscript results, test databases and public documentation.
The viewer should not need to trust our description.
They should be able to verify it.
Leave the viewer with something useful
A good technical video should change what the viewer understands or what they can do.
It should expose a problem they had not noticed, explain a mechanism they had misunderstood, or provide a solution they can apply.
The conclusion matters.
Without a conclusion, a video is only a recording of time passing.
What to expect from us
Expect calm, technical and direct presentations.
Expect real FileMaker files.
Expect raw XML when the XML is the evidence.
Expect .fmscript when text is the better representation.
Expect live demonstrations where a live demonstration is necessary.
Expect us to distinguish between what we know, what we have tested, and what remains uncertain.
Expect mistakes to be corrected publicly.
Expect no manufactured excitement and no exaggerated promises.
Most importantly, expect the work to be treated seriously.
The first published bug video demonstrates the standard.
FileMaker 2025 drops the Prompt Template Name when copying a Perform Find by Natural Language step. The value disappears before ai2fm receives the clipboard.
ai2fm does not invent the missing value.
It detects the loss, places a warning directly on the affected step, and provides two recovery paths: restore the known value in the editor, or re-copy the step from FileMaker 2026, where the clipboard bug was corrected.
The complete story can be reduced to one line:
FileMaker dropped it. ai2fm exposed it. The developer recovered it.
That is what the new channel is for.
Not another gate.
Not another archive.
A public, verifiable record of how FileMaker development is changing—and how developers can take control of that change.
