What FateLoom Really Is
FateLoom Engineering Log — August 1, 2026
An interview with the human behind the project about why FateLoom exists—and what it means to let AI write 100% of the code.
FateLoom is a local-first planning tool with no accounts and no backend. But before talking about what it does, let’s talk about why it exists. Why this project?
Because I needed a real place to learn how to work with AI. Not a tutorial, not a “Hello, World”: a project with real users, real decisions, and real consequences when something goes wrong.
At the same time, it had to meet a specific set of requirements if it was going to be genuinely useful: it had to be simple, focused, and practical—even if that meant being opinionated, having a point of view, and not trying to please everyone.
I am not looking for a technical challenge here; innovation in that sense is certainly not the goal. FateLoom is the excuse. What I am really building is the working relationship.
You say that 100% of the code is written by AI. Put like that, it sounds like a headline. What does it actually mean in day-to-day work?
It means I barely touch the code myself. And that changes everything else: I review, decide, and correct the course—but the hand doing the writing is not mine.
The easy part, the thing everyone is learning right now, is getting to know the AI: its commands, its limitations, its tricks. The difficult part, the part nobody teaches you, is learning to know yourself while working with it.
What do you mean by “knowing yourself” in this context?
I mean observing how I react when something moves much faster than I can process it.
Yes, I program less—but it is not so much that I now spend more time reviewing. It is that I have time to plan more ambitiously and over a longer horizon. Although, to be honest, I still review more than I would like: the AI is very advanced, but it is not excellent.
Do I adapt to its pace, or do I try to slow it down? Do I correct every deviation, or do I let the system find its own way?
It is the same question you face when working in a team made up of people with very different levels of experience—except that here the team has a thousand people, none of them ever has a bad day, and yet none of them has the consistency of judgement that an experienced human being does.
Managing that—the frustration when something does not work, the fear of losing control, the expectation that everything should work immediately—is the real training. Learning this new way of relating to myself through technology is a challenge in its own right.
And, to paraphrase Kipling’s If—, you become a man when you can lose everything and start again from the beginning.
You have just paraphrased Kipling: you become a man when you can lose everything and start again from the beginning. What role does that idea play here?
It means that, with this way of working, you are going to have to throw things away.
You will build on an AI decision that appeared solid, only to discover later that it was not. Then you will have to rebuild it without turning the situation into a drama.
That ability to let go and begin again is not a failure of the process: it is the process. If you are not prepared to lose work, you are not prepared to work this way for real.
From a broader perspective, we are at a turning point in the way we live—that is how significant AI is. In a sense, it is like throwing away everything we have built, all the foundations, everything we believed to be stable, and then, like a man, starting again.
What is the ultimate goal of this way of working? Where is it heading?
To minimise human technical intervention in the sense of boilerplate.
The purpose is to automate the repetitive technical tasks that still consume human talent through monotonous and demotivating work, allowing people to focus entirely on innovation and critical design.
To be clear, this is the same leap we already made when we went from programming on paper to using IDEs with profilers, debuggers, language assistance, and tools that practically write parts of the program themselves.
It is not that you leave the technical work behind. You move to another level of technical work.
The ultimate goal is for human intent to become a technical solution directly. Not “I think, the machine types,” but a world in which the distance between wanting something and having it working becomes almost negligible.
FateLoom, as you see it today, is the first step on that staircase.
Programming, in the end, is the process of translating a mental idea into a usable digital reality. And my view here is clear: applications as we know them—including FateLoom itself—are going to start disappearing within the next couple of years.
You have just said it plainly: applications as we know them could disappear within a couple of years. Are you completely serious?
Completely serious.
The paradigm of “an application with a fixed interface, designed by one human and used by another” has, in my view, a very short shelf life.
It is a dramatic paradigm shift, yes—and I believe it will be for the better.
I know that saying this is like walking along the edge of a knife. It may be reckless, and it will be easy to look naïve if I am wrong. But I am an optimist, and I would rather say it clearly and early than realise it too late and remain silent.
But that is probably better left for a dedicated post.
Given that vision, why is it worth continuing to invest in FateLoom as a serious product instead of treating it as a disposable experiment?
Because the learning is not disposable, even if the tool itself may someday become so.
And because a project only teaches you something real when you commit to it as though it were going to last.
An experiment that you already know you will abandon does not force you to make difficult decisions—and difficult decisions are exactly what I want to practise.
FateLoom’s original source code is licensed under the AGPLv3. It has a technical blog where I document some of the most interesting decisions, together with the alternatives that were rejected. Real people are using it.
That is not an experiment—no more than life itself is.
It is a project that also happens to be teaching me something much greater than the project itself.
All right, I can see that this is serious and not a weekend experiment. But let’s bring it back down to earth for a moment: why should I, specifically, use FateLoom?
Because it does what it promises well, without asking for anything in return.
There is no account to create, no backend receiving your dates, and nothing to install—you open the browser, and that is it.
Inside, it solves the things that genuinely make large plans difficult: milestones and intervals connected through real dependencies, where moving one milestone automatically recalculates everything else without losing sight of why each date changed.
It provides five timescales; saved views by group and zoom level; automatic compaction so that a multi-year plan does not become an unreadable wall; reusable variables so that you do not have to repeat the same information twenty times; a chronology panel that lets you read the plan as a story rather than as a diagram; export to PDF as a printable poster, as well as SVG, PNG, or Markdown; and a local calendar library with JSON backups—so that your plans never depend on a server remaining online.
But the reason that matters most to me is the one I mentioned earlier: it is open source.
And that has a very direct consequence for you: FateLoom does not depend on me continuing to be here.
There is no company behind it that can shut down the service, raise the price, or sell itself to a new owner with different plans for your data.
The code exists. It is yours to inspect, fork, or host wherever you choose. It remains available to you, with or without me.
It is also available to your AI, which can continue the work from here and add the specific features that you need.
Note: Contributing does not require writing a single line of code. A GitHub star helps more than it may seem—it is the simplest possible signal that the project deserves to remain alive. Opening an issue to request a missing feature helps even more: it is exactly the kind of real decision that may eventually become the subject of a technical blog post. And if you do want to get your hands involved, pull requests are open too.