We will all be hackers.

A working replacement, with a foundation underneath

My short links need to keep taking people to the right places. I want to find a link, see where it goes, make changes, create a new one and get a useful view of activity. I want the information under my control and a way back if an update goes wrong.

The underlying redirects had already moved from Rebrandly to Cloudflare. JJ Links gave me a management layer around that foundation: a searchable inventory, editing, activity information, exports and backups. It is a replacement for the work I needed Rebrandly to do, shaped around my own use.

The public edition makes the arrangement inspectable. Cloudflare Bulk Redirects serves the actual links. Workers hosts the dashboard, D1 stores its data, and Cloudflare Access protects it. Taking the dashboard offline does not stop the configured redirects from working.

That last detail is important. We did not decide that, because AI can write code, I should personally recreate the infrastructure that delivers redirects. We used an established capability and built the part that made it useful to me.

We also used AI to make the tool without making an AI model a requirement for operating it. The public edition needs no OpenAI service or AI API at runtime. Building with AI and requiring AI for every use are separate choices.

I am describing a fit for my needs. I have not established feature parity with every Rebrandly plan, a universal cost advantage, or that everybody should make the same choice. The $384 is the subscription I can dispense with. Domains, hosting limits, my existing AI tools and the time spent building and maintaining things still belong in an honest account of cost.

The hacker is the person with the problem

The interesting change starts before any code is written. I can notice something awkward in my life and sit down with AI to do something about it. I can describe the outcome I want, explore possible approaches, try one, examine what happened and change direction.

In this collaboration, the AI team does the implementation, with help from me. My contribution includes the problem, the context, the taste and the judgment. I know what bothers me. I can recognise when an apparently elegant solution makes my actual life more complicated. I am responsible for the choices I accept.

That is what I mean by becoming a hacker: developing the habit of asking whether the arrangement in front of us can be changed, and having the means to try. Some people will want to understand every line of code. Others will work through conversation and judge the result in use.

There is learning involved either way. A capable assistant still needs access to tools, a sensible brief and feedback. A private experiment and a service other people depend on carry different responsibilities. My own setup is unusually well equipped; I should not mistake my experience for proof that everyone already has the same access or finds the process easy.

But the admission requirement has changed. Understanding a problem can now take a person much further towards a working solution than it could when implementation first required finding, briefing and paying a developer. The distance between intention and action has become shorter in my own practice. That is a useful change to experience.

Fill a gap. Replace a product. Follow an intention.

I see three movements happening together.

First, we can fill gaps. A need may be too personal, too occasional or too small to sustain a software company. It can still matter to the person who has it. When the effort of trying a solution falls, more of those needs become worth addressing. We gain things that no vendor was ever going to sell us.

Second, we can replace things we already buy. This is where JJ Links belongs. There was a product, I was a customer, and now I have another way to do the work. A potential software supplier increasingly has to compete with a customer's ability to have something suitable made for them.

Third, the separate app can recede from the relationship. In recent mailing-list conversations I have described this as moving from app to intent. I want something done, and my AI can work with the relevant services, tools and information from the interface I already use.

My bookkeeping is an example from my own experience: I can work with the underlying service through my AI interface. The service remains useful even when I rarely visit its own screens. Building another bookkeeping application would miss the opportunity to use what is already there.

These movements coexist. JJ Links has a dashboard because a dashboard is useful here. Another problem may need a small script, an assistant skill, an established service, or a temporary combination of several tools. The outcome should determine the arrangement.

I am also building JJ Travel Hub around the way I need to understand bookings, people, changes and what happens next. It is still an owner beta, with the TripIt transition being worked through. Based on the experience with JJ Links, I will release Travel Hub as open source too. That is an intention to share the next solution, rather than a claim that a finished public release already exists.

What I mean when I say software is dead

I have been making that claim with increasing emphasis. It is deliberately provocative. It also needs a precise reading.

There will plainly be software running throughout the future I am describing. What I increasingly doubt is the durability of the familiar arrangement in which a vendor packages functionality into an application, I adapt myself to its choices, and I keep paying because obtaining a suitable alternative is too difficult.

AI puts pressure on that last part. If I can explain my needs and obtain a useful implementation, the existence of a working application becomes a weaker reason for me to remain a customer. A polished interface may be valuable. It may also be a layer my assistant can work around or help replace.

This makes me sceptical of the comfortable assumption that there will always be a substantial business in selling the next convenient wrapper around an accessible capability. Some of those businesses may discover that a customer can now assemble the value without them.

Rebrandly and TripIt are concrete names in my own exploration of this question. I can see a future in which neither has a reason to remain in my setup. Their present usefulness to other people, or their ability to develop different reasons to be chosen, is a separate question. A single replacement cannot settle the future of either company.

The challenge for a supplier becomes more interesting: what are you providing that remains worth choosing when the customer can have AI build a credible alternative? Reliable operation, unusual access, deep knowledge, accumulated context, excellent service and relationships may all matter. Each has to produce value in practice.

Solid foundations, adaptable layers

This distinction is foundational to how I think about what comes next.

Some capabilities should be dependable enough that many other things can be built on them. They need clear interfaces, intelligible limits, continuity and someone taking responsibility for their operation. Other capabilities are close to a person's particular circumstances: the view they want, the workflow that suits them, the connection between two things that previously sat apart.

In JJ Links, the distinction is unusually visible. Cloudflare runs the redirect capability. My AI team built the way I administer and understand my links. The personal layer can change while the established redirect engine keeps doing its work.

The two roles have different demands. A personal layer should be relatively easy to adapt or replace. A foundation should be something I can reasonably depend on while doing so. The more inexpensive experiments we can build, the more important it becomes to know which underlying capabilities each experiment relies on.

Cloudflare earns its place in this example. That does not make it infallible or remove platform dependence. I still depend on its availability, rules, pricing and continued access. Exportable information, clear boundaries and a workable way to move remain valuable. Having source code is one form of control; understanding the dependencies is another.

Open source and infrastructure are also different questions. A foundational service can be open source. A personal tool can be open source. Making a project public does not by itself establish that it is reliable enough to become someone else's foundation.

I expect an abundance of small, specific solutions built around dependable capabilities. I would like more providers to make those capabilities straightforward to connect to, combine and leave. That is the infrastructure opportunity I see: make it easier for people and their AI assistants to do useful things without having to rebuild the difficult underlying work.

The nudge that changed the project

The economic argument leaves out something essential if it stops at replacing a subscription.

I had a solution I liked. Johannes saw it, asked whether I would share it, and gave me a reason to take it further. That relationship changed the direction of the project. It also made the work more fun.

Preparing something for another person asks different questions. Can they install it in their own account? Does it contain my information or assumptions? Can they understand its limits? Which parts are tied to the place where I originally built it? A private solution becoming reusable is work worth recognising.

The public JJ Links README reflects that work. It explains the Cloudflare setup, provides an installation path, and includes a prompt someone can give their own AI assistant to handle the technical steps. The source is available under the MIT licence. Other people can make it theirs.

Johannes did. His video describes using it for his own short links. I am taking his account seriously as the experience of another user; it is not an independent audit or a claim about adoption at scale.

Still, it changes what we know. We have moved from a solution that worked for me to a solution another person found useful enough to install and publicly appreciate. The nudge mattered. So did the response.

Joy can compound too

I enjoyed building something that solved my problem. Johannes enjoyed taking it into his own life. Seeing that gave me another kind of pleasure: the thing had become valuable to somebody else. Now I want to share the next thing too.

There is a compounding effect in that sequence, even before we count users or saved subscriptions. A relationship created an opportunity. Sharing produced an experience. The experience increased my willingness to share again.

I suspect it will also give Johannes more confidence and inspiration to build something of his own when the next need appears. That is an expectation about what might happen next. I cannot turn his enthusiasm into evidence that a future project has already happened.

But I can see how the sequence could continue. Someone benefits from a shared solution, discovers how approachable adaptation can be, makes something for another problem, and lets somebody else use it. Useful code travels alongside practical knowledge and the feeling that making things is something people like us can do.

The pleasure is part of what makes me return to the work. So are curiosity, generosity and the chance to do something with another person. A cost calculation that leaves all of that out would explain my behaviour rather badly.

I do not know how widely this pattern will spread, or which communities will develop around it. I do know that a small interaction has already changed my own plans. That is a modest piece of evidence with a surprisingly large amount of possibility attached to it.

One more person can be enough

A commercial product has to justify the work of building a business around it. A useful act of sharing can have a different threshold.

If I already have something that solves my problem, and making it reusable allows one more person to benefit, that can be enough reason for me to release it. I do not need to establish a market, acquire a thousand users or invent a subscription before the act becomes worthwhile.

There is an important practical qualification. Releasing source does not require promising permanent support, and a repository does not absolve me of explaining the intended use and known limits. Someone else needs enough information to decide whether the tool belongs in their life.

Nor does everything have to become public. Some solutions are too specific, contain information that should remain private, or simply require more preparation than I want to undertake. Sharing is a choice. For JJ Links, Johannes made the value of that choice wonderfully concrete.

If many people make similar choices, the resulting collection may look less like a catalogue of universal products and more like a huge assortment of starting points. Some will be used unchanged. Some will be adapted with AI. Some will be useful only to the person who made them and one other person.

That last outcome deserves to count as success.

What happened, and what I am forecasting

It is easy to let an exciting example do more argumentative work than it can carry. Here is where I draw the line.

Observed: My AI team produced JJ Links around the link-management work I needed. A public edition exists, with an open-source licence and documented dependencies. Johannes reports installing and using it, and made a public video about the experience. His request changed my original intention, and I now intend to share Travel Hub too.

My assessment: JJ Links gives me a better fit and removes a $384 annual subscription. That is a report about my own needs and spending. It does not establish a universal comparison with a commercial service, or make the entire arrangement costless.

My inference: AI-assisted implementation and reusable infrastructure have made this kind of personal replacement practical for me. Making the result available has extended its usefulness to another person. The case shows a route that others can inspect and attempt.

My forecast: Many more people will solve their own problems this way. More existing subscriptions will become replaceable. Shared solutions and the experience of adapting them will encourage further building. For some tasks, separate applications will recede as AI works directly with underlying capabilities.

Still open: How broadly this spreads, how much upkeep people accept, what it means for access and inclusion, which suppliers develop new value, and how the balance of power shifts towards or away from the infrastructure providers. We do not know those outcomes yet.

My bookkeeping example supports the possibility of accessing a service through a chosen AI interface. JJ Links supports the possibility of replacing a product and sharing the result. Neither example establishes that every application will disappear. I see a trajectory worth exploring, and I want to keep adjusting the forecast as the evidence develops.

Try one real problem

For someone curious about this, I would start with a small irritation they understand well. Something they can recognise as better or worse when they try it. Give an AI assistant the context and the desired outcome, then ask what existing capabilities could do most of the underlying work.

Keep the first useful version small. Try it in ordinary use. If it is replacing a working service, keep a way back while it earns confidence. Learn where the effort actually goes: specifying the need, granting access, checking the result, living with it, changing it.

Then show it to someone. Their reaction may reveal a different need, an assumption you missed, or a reason to share. That conversation can be as consequential as the implementation.

For a software business, I would start with the corresponding question: if a customer and their AI team can assemble the part they currently buy from us, what will make us worth choosing? That is a question about actual customer value and the capabilities we can make available to them.

For an infrastructure provider, there is an invitation here too. Give people dependable capabilities, clear interfaces, useful documentation and a comprehensible way to control their own information. Make the foundation good enough that a great many personal solutions can safely grow around it.

And for me? I will keep paying for things that earn their place. I will keep asking my AI team to help change the things that do not. I will release Travel Hub when it is ready to be useful to somebody else.

Johannes asked one question, and a solution made for me became a gift. If the next thing helps one more person, that can be reason enough to do it again.