Foreword
What follows is an attempt to outline what I’m currently building in the domain of artificial intelligence and why. I refer to it as “Alt-AI”.
There will likely be a little technical detail, though I do not wish to leave non-technical readers behind. It is a very personal work. I hope there will be something for everybody.
When I was young (in my 20s), it would be fair to say that I was a “technology accelerationist”. Today, I would be inclined to see this as arrogance, and it would be fair to say that I am now more of a tech-traditionalist. Perhaps this is a natural progression.
I am not an AI accelerationist in any case.
Where I choose to engage with AI, it must be on my own terms with a view to exploring alternative approaches for its use by human beings. This is what my Alt-AI project, called Marklet, represents.
I suspect that local AI is about to become very important. The GPU and RAM drought will necessarily come to an end. The business models of the large vendors are bleeding cash at an astronomical rate, yet AI is failing to deliver meaningful returns.
However, if left entirely to the large players, local AI will largely be on their terms. You will pay for the hardware and you will pay for the electricity, while they retain significant control and access to your data.
This is one reason why open source projects such as Marklet are important.
If you’re cautiously interested in AI, but wish for a different mindset other than the one set on pushing the pedal to the floor, then that’s me.
You can follow me on Substack, or kuiperzone on X. You can “Watch” Marklet on Github if you have an account. My thinking does not come from an AI prompt or from memes on LinkedIn. I have been making these arguments since 2022.
What is Meant by Alt-AI?
Marklet is not intended to be used in the automation of people nor for the automation of things human beings should do for themselves.
AI has been presented as something that will achieve great things instead of ourselves, such as solving climate and curing cancer, with the role of human beings reduced to that of atomised mechanical tasks, including the checking of AI output.
There is something wrong with this. I think things should be the other way around.
AI may check our work. We should not be checking its work.
The intended use case for Marklet is that of research, analysis and the checking of human work, rather than content generation. It is a tool to be used to extend competent reach, not replace it.
This is the only way I wish to use it. These are my terms.
It may be argued by others that there are legitimate uses for, say image and video generation, but dedicated tools are likely to be more appropriate for this anyway.
Marklet is not designed to scale beyond individual use. It is not designed for multi-user or enterprise environments. It is not designed to be a component that can readily be integrated into some larger system, although I’ve no doubt the code base will be strip-mined by automated means.
If AI is to be of long term positive benefit, it must be used on a smaller scale, rather than the larger one.
Fundamental Limit
A particular characteristic of digital technology is that it scales, seemingly without limit due to a strong correlation to fixed cost rather than unit cost. This has benefited economies of scale rather than individuals. I have reason to suspect, however, that AI represents the limit of this approach.
This limit is fundamental and not easily grasped by those with a purely engineering mindset.
The dream of AI was always one of a perpetual motion machine, which I mean literally and not as an analogy.
Automation cannot, on its own, be used to decrease entropy. It can only increase it, or at best, keep it the same. This is the fundamental flaw of the schemes of those sought to benefit from it. I find it hard to believe no one seems to have realised this. I have to accept now that they did not.
The side-effects of AI are being noticed in the domain of software engineering, which was the natural target for its early adoption. What is being noticed — and what should have been obvious — is that AI generated code is brittle and brings compounding defects.
Moreover, open source projects and Github* itself have been subject to tremendous strain as a result of the flood of AI content. I cannot comprehend how this was not anticipated.
A number of open source projects are now banning AI contributions altogether or beginning to restrict their submissions, including: flathub, NetBSD, QEMU, Zig and OBS. I see this as a start of a trend, although others are attempting leverage AI.
The Tower of Babel occurs when human beings build faster than we can manage the entropy generated. It is when we build in arrogance rather than care. Care is that which aims to minimise or reduce entropy (disorder). Arrogance is that which increases it.
(*) Github serves as an online repository owned by Microsoft for source code. Many software development projects use it.
About Marklet
Marklet is a local AI client under development. It represents the visual front-end to AI running on your own computer under your own control, rather than somewhere else under someone else’s control.
Marklet is a native desktop application, rather than an Electron or web app. Its focus is the individual. It is stand-alone. It is personal in the same way that a PC was once personal. It aims to excel at core chat facilities, and to do this independently of external services as far as possible.
On its own, there is nothing particularly novel about an AI client in and of itself. There are a number of these in existence with one of the better ones being LM Studio. However, Marklet takes a different approach to things which I hope will make it interesting in the future.
Marklet is a work in progress. It is not ready for use, but nevertheless currently looks like this:
Marklet is fully open source, being Affero GPL licensed. There is no business model behind the scenes.
It has zero telemetry. It is a thing I am building upside down and in reverse to how things are often done these days. I am making it for my own reasons. I am a “bottom up” thinker.
Crafted not Generated
The code base is not AI generated and has taken me a little longer than a few minutes in a chat prompt to create. The rendering engine is custom designed from scratch, with minimal dependencies on third party libraries, rather than being a cobble together of pre-existing stuff.
My focus so far has been on the UI and user work-flow, rather than early integration with AI. I have put effort into the rendering performance and internal database implementation so that it can comfortably handle lengthy sessions.
The UI is very polished for what is a “preview release”, with the AI bit (the interesting bit) in the pipeline. You can download and try it, and I will explain below.
Development Approach
I began with Ollama running at the command line. I realised early that I could connect it to the Brave Browser for use as a local client. It was a simple solution, which I liked, but also quite limited.
I tried several existing desktop AI clients. Without naming them, most crashed repeatedly during normal use. I thought, naively perhaps, that I could make a better one.
Rather than studying the designs of existing software in detail, I made a deliberate choice not to examine them further. I wanted the struggle of figuring things out for myself.
This is how I have always done things and I can assure that this is the hard way. However, it perhaps an approach that may become increasingly important in the future as the weakness of herd thinking are exposed by AI.
I knew that if I absorbed the approaches of others too early, it would be harder to create something even slightly different. There is little point in merely replicating what already exists precisely.
I am constrained already by the expectation for a conventional chat interface. I knew LLMs typically output Markdown. Building a coherent context window remains the next challenge, and this excites me. I do not wish for a ready-made solution of this.
This might seem arrogant to some, but I would disagree. This is my desire to think for myself.
Imperative Declaration
I still think of myself as a “programmer” in the old sense — someone who builds things using imperative logic, such as “PRINT X”, or “MOVE 5”.
This mindset has become somewhat unfashionable, however. Modern development is more declarative now: assembling large pre-existing components with configuration (declarative) and smaller glue code to stitch things together.
I come from the former camp.
My former business partner was the opposite — a master of configuring complex systems, particularly databases. He could set up a Cassandra database cluster from memory and understood every nuance, but became lost in a bash script longer than a page or so. We made a good team actually*.
AI lends itself to the manipulation of that which already exists. It lends itself, therefore, to the declarative paradigm more successfully than the imperative one.
(*) My friend and business partner was the first in the UK to receive the SCO ACE certification. We shared the same perspective on how things had changed. Sadly, he died unexpectedly last year.
Markdown
When I decided to build Marklet, it never occurred to me to convert the AI’s markdown output into HTML and then render it in a browser engine or existing HTML component. This would have been the convenient and orthodox approach, but I had not been looking at these.
Instead, my thought was simple:
Markdown? How hard can that be?
Well OK, I am naive. The thought was simple, but the reality not. I spent three months writing a markdown parser. It worked, more or less, but markdown is far harder to parse than it looks with its endless and difficult to handle edge cases.
There is nothing wrong with re-inventing wheels, but to write a worthwhile markdown parser was going take me a whole lot longer — a year or more even. There is a limit to my desire to build everything from scratch, and I switched to a third-party library called Markdig.
I wish to mention this for a reason.
Having tried to build a markdown parser myself, I have the utmost respect for those who wrote Markdig for C#. One of the reasons I did not adopt it immediately was that Markdig’s output seems somewhat complex, but now I understand why.
Doing things for myself is good way to learn hard lessons.
I swapped out my own parser for Markdig early on. I had called my parser Marklet, and re-purposed the name for the application itself.
So Marklet parses markdown and renders it directly. This means that it fast, and does not suffer the same UI lag typical of other AI clients.
I am thinking very hard about how people will use it, and what the workflow will be. The ability to support long chat histories will be important, and I’ve been testing it with simulated chats comprising over 10,000 complex messages. Currently, I’ve limited it to around a thousand, but may extend this in the future using a technique called “virtualisation”.
Independence with Respect
In IT, we all rest on a deep technological stack written by others developed over decades. You could not imagine what is involved in making a “simple” HTTPS request.
I sense that many have lost sight of this. Sometimes, I feel the respect is lacking for those who laid the foundations on which others stand.
While I may prefer to build things from a slightly lower level than many do, I will use existing components where I feel this makes sense. Where I do re-use, I want to know that it’s good and that it wasn’t something I could have written myself.
For me, resilience is not just about security and redundancy, it’s also about independence.
Sometimes, you might have a shot at writing something, but have to back track as I did. Sometimes you get things wrong, but this how you learn.
AI fosters the expectation of ready-made easy answers. If this is all you get, there is no need to learn — not even learn by rote — as more ready-made answers are always available for you on tap.
There are in fact no ready-made easy answers. The pain is just pushed further down the chain.
The Look
Marklet runs on Windows and Linux, but MacOS should be possible also. I wish it to be used by those who either create or do, not consume.
It will probably remain niche. That is OK.
I currently use Gnome on Linux as my daily driver and don’t wish Marklet to look out of place (janky) on different systems. At the same time, I ponder how user interface design has been driven by the mobile paradigm and how everything looks the same these days.
Nevertheless, I made it look as expected, even though this took longer to do. I wish for the user interface to be one of the best things about Marklet.
But I also wanted to offer a little customisation so that the application can be your own.
Like this perhaps:
Or perhaps:
It has a fully featured search capability designed to work with as content grows large. It also has a built-in note taking feature which is completely separate to any AI use. I specifically wanted this for myself because I’ve never found a note taking app that fulfils my needs, even though my needs aren’t particularly demanding.
I am already using this feature myself. It is as an area to be expanded on in the future.
A Tale of Two Rockets
I used to work at a telecoms provider in Ireland. One of the senior managers was somebody I respected. One day, he looked out of the window during a meeting and said, “You know, we could be building a space shuttle just there in the car park, and the only thing anyone would care about are progress updates.”
So, here is a progress update concerning two rockets:
Both have demonstrated that they can work, so far at least.
One of these, however, employs safe proven technology, re-using existing components from the Shuttle to save on development costs and time. The other is more radical by any standard.
Development of one of these began some 16 years ago and has cost approximately $93B to date. The other started life some 8 years ago, and is reported to have cost ~$15B so far. One costs $4B per launch, and the other somewhere around $90M. (I realise that I am not necessarily comparing like-for-like on this last figure, but nevertheless the difference is notable.)
One is disposable and serves no purpose beyond that it is expressly designed for. The other is fully reusable, more powerful and flexible, with its mission being promoted as being Mars as well as the moon. However, I rather suspect that its real purpose is deliver many thousands of low cost AI data centres into orbit.
Assuming no catastrophic calamity for either, which one has a long-term future and which does not?
Closing Thoughts
Whenever I tell people about Marklet, without fail, the question I get is always the same one: “How are you going to monetise it?”
My father worked in a factory. His work was characterised by heavy machinery and a “job sheet”. I never understood, because things weren’t like that for me.
I worked for many years in the software and telecommunications industry, but began life in physics and spacecraft engineering. My career was dominated by C++, and then Java and C# as software became about web and web-related technologies. However, my heart lay in local desktop applications, for which there is no money now.
By my last mainstream role, my life had been reduced to atomised ticket work. I never wrote a single line of code that was my own. Whereas my father’s workplace at least had camaraderie and friendship, in mine there was none of that to be had any longer — only Team meetings, git merges and Jira.
Not long ago, I sat with a friend as he had an “around the room” Teams call with his employer which was a derivative of a company we both used to work for in the past. There were 127 people on that call, and we spent the day talking and eating jelly babies, with his mic muted, until his turn came around.
During the day, he commented drily: “I earn £70K a year, but sit all day at my coffee table with a laptop, a bottle of vodka and light bulb without a shade over my head. I don’t even care whether I live or die.”
We are learning the lesson of the over machined society and we are learning it the hard way.
Andy Thomas originally studied physics before moving into programming. He is developing an open source AI project, not because he is an AI accelerationist, but because he wishes to explore how it can be made suitable for use by human beings. He is a Christian.
Addendum
Try Marklet as it is Now
Marklet is on Github. If you wish to try it, to get a feel, you can.
As yet, the AI integration remains to be done. This might take me sometime to implement actually.
This means that if you create a “new chat” and type into the prompt now, the software will generate a “stub response” to simulate AI output. But this is a preview only and not a usable release.
Click here: Marklet Release to go the release page on the Github project. Click Assets, as shown below, on the latest Release (version 0.8 at the time of writing).
On Windows
If you’re on Windows, download the win-x86 zip file and unzip it. Run the Marklet.exe file inside.
Now, Windows will warn you that this is an “unknown app”. This is because I have not purchased a “code-signing” certificate for what is an early preview just yet.
You will need to click “More Info” and “Run Anyway” in the message box which may appear. In the future, I will build a signed Windows installer. For now it is just a Windows zip with a runnable file inside.
On Linux
If you’re on Linux, download and run the AppImage (set the exec permission) or, if you prefer, install the local flatpak file:
flatpak install ./Market-0.8.x86_64.flatpak
You can remove the flatpak later from the software centre, or from the command line:
flatpak remove zone.kuiper.marklet
MacOS?
Marklet should, in principle, run on a Mac but I understand that I must purchase Mac hardware to be able to test it.
If you are more technical, you could install the dotnet sdk, clone the git repo, build and run. Marklet has no special dependencies. It should just build and run. Post a comment below if interest in this on Mac, and I will respond.
I Suggest You Click…
Once running, open the “Settings Window” (Cog bottom left) and go to “Database”.
Click the button shown below.
Clicking the “Insert Test” button will populate the database with test chats which will appear on the left immediately. Things will then look familiar to you with regards any AI chat client and you can browse through the interface.
The interface on the left-side of the window supports drag and drop.
A couple of the test chats are designated “mega chats”. These contain lengthy histories intended to ensure that the UI does not lag significantly when chats reach a thousand or more complex messages in length. My priority at the moment is to ensure that everything works and is robust.
You can type into the prompt box at the bottom, and “stub-bot” will respond as if there was an AI model hooked up (you don’t need Ollama or anything for this). The interface is almost entirely fully functional, including the Search features.
The test button will be removed at some point in the future.
Project Maxims
The following are intended to guide the development of Marklet:
1. Machines Should Not Deceive
Chat and AI systems should not masquerade as human, nor use manipulative psychology such as responses designed to appeal to ego. Modern speech synthesis should contain some audible trait making it discernible from that of human. The same applies to simulated visual appearances and all modes of perception.
2. Automation of the Law of Unintended Consequences is a Bad Idea
Despite the allure, agentic automation and machine sub-goals are to be eschewed. Information is dissipated as deterministic processes interact with the environment. Without consciousness to intervene, consequences move away from desirable outcomes. This is not to say AI cannot interact with the environment, but only that decision making should not be chained as automated sub-goals. Moreover, it is not sufficient for humans to passively “check the data”, but rather that they must be invested in its outcome.
3. An Informational Monad is Heat Death
AI and automated processing should be local and under the control of those who are to receive its benefit or suffer its consequences. AI should be embedded within the personal device, the robot, or employed as on-prem hardware, but not behind monolithic one-way mirrors. There must be valid separation at the level of conscious control so as to maintain an entropy differential. Without this, the flow of information ceases (i.e. informational heat death).
4. Without Consciousness Autonomy Entropy Cannot be Regulated
The use of AI and automated systems to manipulate, restrict, subvert or otherwise control autonomous beings is destructive in the long-term. Without conscious autonomy, nothing new can be created and entropy cannot locally be reversed. The effect is one of slow degeneration.
5. Responsibility Without Control is Merely to Suffer Consequences
Where autonomy is taken from you, you cannot be responsible for decisions made for you by others. Likewise, if you take autonomy from others, you therefore become responsible. If you seek to direct others, it is valid only where conscious consent exists that can be freely and truly withdrawn.