First of all, thanks to Neil Ford for the term “Token Apocalypse” at dev2next. The Token Apocalypse is when the Silicon Valley AI companies are starting to charge for AI usage what it actually costs and not the ridiculous low prices of today that are subsidised through venture capitalists and government loans. When will this happen? Likely directly after they IPO. They all announced that it would happen in 2026, but has been postponed to 2027. Most likely because none of them wants to go first, since they know that they will be the symbol of the Apocalypse when we look back in history. It is also likely that they want to get the World even more hooked on the very pleasant and warm fuzzy feeling of wellbeing that comes with token-maxing.

One of the side-effects of today’s pricing model for AI usage is that it does not really matter if you spend a little extra tokens on guiding the coding agents in making framework decisions., It may even be tempting to let the agents build architecture components for functionality that traditionally would be covered by open source libraries and tools. While it may seem like a wise decision to for example create a totally custom built logging framework for every app, it may be that you discover that going with for example log4j would be better in the long run.

This article is a follow-up to Will AI kill Open Source? from February. I promised a series of articles, so you are now the proud reader of the second article in the series. Let’s dive in and look at how Jakarta EE can mitigate the effects of the dooming apocalypse.

How does it work? It is becoming a common practice to specify very clearly the architectural requirements and boundaries for the coding agents, whether it is in ARCHITECTURE.md, AGENTS.md, or similar. These documents fill up the agent’s context, and you are not even sure the agent will actually follow them to the point, treat them as suggestions, or ignore totally. Hence you have to write a bunch of tests to verify the architecture with ArchUnit or similar. Running these tests will increase the build time and consume resources on your CI. The more comprehensive the documents and tests are, the higher the cost.

When token prices go to the moon, the cheapest prompt is the one you never had to send. The Jakarta EE specifications consist of extremely consicely written, structured documents and well-defined APIs for how to build an enterprise application. They separate clearly what services the Jakarta EE Platform provides, and what is left to the application developer. This means that the coding agents can focus on solving the business problem and not spend time (tokens) on architectural concerns. Simply because Jakarta EE has already solved that problem.

Even if the misconception, or myth, that Jakarta EE is only for monolithic applications running in obese application servers in the basement should be bunked by now, I still hear these claims. Jakarta EE is a robust platform that supports all possible modes of deployments, wether it is functions, microservices, modular monoliths, or monoliths. The specifications can also be used individually if you don’t need the full functionality offered by the Jakarta EE Platform, Web Profile, or Core Profile. No matter how you choose to use them, the Jakarta EE specifications give AI agents a common vocabulary resulting in fewer hallucinated frameworks and more standards-based solutions. All of which saves tokens. And when the Token Apocalypse is here, make sure you are secure and safe sailing towards a brighter future with Jakarta EE.

By the way, other than the image, not a single token was used in writing this article…