# Maximizing AI Efficiency with BCE Architecture and Quarkus

**Podcast:** The InfoQ Podcast
**Published:** 2026-05-11

## Transcript

If your team has AI running and a proof of concept, but you're still figuring out how to run it reliably in production, you're not alone.
That's the gap most engineering teams are navigating right now.
QCon AI Boston, this June 1st and 2nd, brings together senior engineers, software architects, and technical leaders who've already made that shift.
They'll share the patterns that scaled, the mistakes that didn't make the blog post, and what they'd actually do differently.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at boston.qcon.ai.
can or cannot work with Java.
But without further ado, Adam, please introduce yourself.
Yeah, you said the veteran.
The truth is, in my first projects, I got the criticism, it is impossible to be that young and an architect.
So if someone calls me a senior or a veteran, and this is not true, I'm still a junior.
Age is just a number, and I'm 30.
So I'm a freelancer since 1997.
My first conference as a speaker was in the year, maybe in 1999 or 2000.
And I did a lot back then with, of course, e-commerce and web.
And do you know James, Java Apache Mail Enterprise Server?
You remember something like this?
I ran James on my server for mailing because I only knew Java back then.
So I used my own mail server and it was James, Java.
And I think it was PostFix and something else.
And I couldn't understand how they are operating.
So I used Java.
And because of that, somewhere became aware that I'm doing this.
And I was asked for my first talk at a conference.
Since then, I'm speaking at conferences, but I'm not considering myself as a speaker.
So I have actually no strategy.
If I'm invited to a conference, what you will hear me speaking about is what I do in projects.
So I don't have to prepare a lot.
This is about me.
And I spend all the time on Java.
And I'm coding more than ever with Java right now.
Thank you.
I will just put a bit of the controversy of how I see you and a couple of the things that I like about you.
So, as you mentioned, you're very flexible and very adaptable and that you take a challenge.
And for that, I remember your first presentation more than a decade ago when you came and talking about Cluj's in Transylvania.
And obviously everybody, when we discussed about Transylvania, we were talking about Dracula.
And at that point, I think there were more than 100 people in the room, maybe even more, around 200.
And everybody told you that's so Hollywood and you'll not catch anybody in Transylvania about that.
Someone stood up and said, we hate Dracula.
And I was not prepared for that, actually.
And you're very flexible and you just adapted and you transformed everything into a distillery and something that goes with moonshine.
That's people in Transylvania they are very proud of because it's like this hard liquor, vodka-like alcohol that everybody prepares at home.
But on the other side, when everybody was going...
with the stream, with spring and everything, you are one of the partisans going against it.
So for me, it's a very nice balance.
As you said, you're very flexible on one hand and adapting quite quickly.
But when you see that there is no need, you're just sticking to your ground and you're a hardliner, maybe if you allow me to say so.
Looking at that.
What you were preaching even at that point was to use as few dependencies as possible when building something, especially in Java.
And at that point, we were discussing about Java enterprise education.
So GE, now it's Jakarta EE.
And now it's a mainstream, but there is a catch to it.
Now you're one of the partisans of Quarkus.
Why?
Spring was not good.
And why do you like Quarkus?
The truth is, at the beginning, in my very beginning, I became a freelancer by accident.
I really like Java always for unknown reasons.
And back then there were too many application servers which were not compatible with each other.
And I saw how it's possible that there are so many consultants out there and they can switch between the application servers back and forth.
For me, it is hard to understand one.
And then J2E happened.
And for me, it was the huge simplicity because, okay, the spec is orders of magnitude simpler.
than all the application servers combined because it was an abstraction.
So I like somehow J2E and Jakarta and so forth.
And most of my clients back then ran application servers.
And then they started to install Spring in an application server.
And this is what I didn't understand.
So, okay, why are you doing this?
I would run Spring on Tomcat.
I get it.
I will buy, you know, support from Interface 21.
or from the Spring company, they were renamed then as Spring Source.
But running Spring inside WebSphere is crazy.
I don't get it.
So we have two dependency injections.
Who can justify such an architecture?
And the second thing, which I never got about Spring in the early days, many projects, there was more XML than Java.
And I didn't like XML at all.
There were Diplomata scriptors in J2E as well, and I didn't like them.
So I tried to generate Diplomata scriptors.
But it seemed to me like the Spring community is proud of the fact that they can define everything in XML.
But my observation was back then, they defined it once and it never changes.
So I couldn't get the point why they are doing this.
I was then influenced by Ruby on Rails, convention of a configuration.
And since Java EE5, this was the early days.
Since Java E5, we had this in Java and I was really happy.
So it is like it worked for me.
If I showed this to someone, everyone liked that.
My workshops get bigger and bigger.
And, you know, there are more and more fangirls and fanboys of this approach.
But if you talk publicly about J2E, everyone associated, you know, WebSphere, which puts in two hours, which I never use.
I never use WebSphere.
And for me, it was like it was a secret weapon.
I was in many very successful projects.
And I think the main success is because we did this convention of a configuration, fast startup times.
It is almost like Quarkus right now, 20 years ago.
And now Quarkus is similar.
Fact is, Quarkus is the fastest runtime right now.
Most of my projects are serverless.
Java is 35 times faster or 30 to 35 times faster than Python, Ruby, Node.js or whatever.
And Quarkus starts the fastest.
So fact is my clients are saving money with Quarkus.
So easy is it.
We could use something different, but the question, why?
Because what also amazes me, you know, the entire discussion of business first and agile adapter requirements, if this is true, everyone should run on Micronode or Quarkus if they're using Java.
So if this were true, and if fashion is in place, then I don't care.
It's okay, then pick whatever you like.
But I even try to replace Quarkus with plain Java, actually.
If Java 25 is enough, why we need Quarkus?
It's not like I'm a Quarkus fanboy.
But I think right now, Quarkus is the most logical choice.
I covered Quarkus for quite a long time, and I spoke to Max and some of the team.
And what I really liked, particularly in the discussion that I had with Max, is the fact that he wasn't afraid of getting inspired from other ecosystems like Python, JavaScript, and take what was actually useful from there.
And leaving aside all the other politics and all the other things about these ecosystems, one of the best thing was the fast feedback loop.
And in my opinion, that's one of the strong points that Quarkus comes with.
The ability of having tests run while you're typing and have a very, very fast feedback.
And also the versatility from being able to run it natively when needed, but also to run it on the JVM.
And that's quite useful.
So I do understand the movement towards this.
And, well, this is technology.
But there is one other aspect that your last presentation included, that was in September last year, again with the Java Users Group.
You coded, and you coded a lot.
You usually coded fast, but this time you had some help from AI Almighty, or however it's the proper naming.
But you brought to light a pattern, or I think it's a pattern, right?
BC, Boundary Control Entity.
And that's another classic, well, old pattern.
Why is it enough?
Yeah, we should do another session in Cluj.
So you are the Java user group, so you just have to know to ping me and I will speak again.
I know the discussion, the discussion is started already, Adam.
It's something that I am promising myself and I'm promising you for more than a decade now.
We should not do a battle of the frameworks.
I know that you like to have fun while coding and you like challenges, so I'll try to put that together.
Okay, cool.
So the BCE, similar story, boundary control entity is called 1992, Ivor Jacobson, several books.
This is a different background.
I was always a singleton, a freelancer.
And I was hired by larger companies through sometimes unusual ways because it's not always possible to hire a singleton.
And I had to justify my choices against huge consulting companies.
What I observe is that everyone has a point of view.
And there's lots of discussion.
And some companies, it's still the case, they use external service or software suppliers or service providers to implement their stack.
And what happens then is that the service providers are not implementing according to a standard or whatever.
Everyone does something different.
And back then, it was even worse because some of them use even code generators, others just use whatever.
So it meant for my clients.
If software supplier A creates software, it is not supported by software supplier B, and they were stuck with diverse software.
This was the first problem.
The next problem was endless discussions about naming.
And I think I wrote my first enterprise book in German.
It was, I guess, 2005 or 2003 or something like this.
And I used my own names, which I liked a lot.
This was like, I remember there was like behavior.
There was a facade and it was domain, something like this.
And the problem was, everyone said, the idea is great, but why you call it facade and not endpoint?
Why you not call it domain and not data?
And I had started to discuss, you know, the names in endless emails.
And I say, I would never do this again.
So since then, what I learned 20 years ago is, if there is a standard, it is way easier to pick the standard, even if it's suboptimal.
So boundary control entity.
Boundary is fine.
I don't like control.
I like entity.
So this is, I would like to replace control, but it's too late.
The standard is set in stone.
So what I did then in projects is, if we start something, what is the absolute common base?
The common base is Java.
It's like if we pick Java, there's no discussion, you know, Scala, Groovy, Clojure, whatever.
We just stick with Java.
It is not enough.
We can always pick something different, but this is the absolute minimal stuff what everybody knows, Java.
Then how to reduce the dependencies?
Because every framework back then was additional discussion.
I don't know whether you remember back then the projects, which logging framework we're picking.
And I was sick of all the, you know, pointless discussion.
And I said, okay, we don't take anything.
We just use whatever Java provides us and stop.
And if we need something, then we discuss.
And what happened then?
Basically, IBM shop had mostly web sphere.
Thankfully, I was not allowed in such projects.
My Red Hat clients had JBoss and I usually back then introduced Glassfish.
And the Glassfish back then, I was a huge fanboy for one reason.
It was the reference implementation.
So if I found the bug, it was fixed quickly.
This was great relation to the team.
Plus, my clients could buy support for Glassfish if they had to without switching to Glassfish Enterprise.
It was the same bits.
which was not true for JBoss.
This is why I switched a lot of JBoss projects to Glassfish back then.
And Glassfish was the same discussion.
If we already have Glassfish and you're paying money for Glassfish, why we need external frameworks?
Just stick what we have.
And what happened then?
Zero dependencies.
Most of my 20 years old projects have no dependencies.
Developers were happy we never had to upgrade.
Migrate and the cool story is recently we migrated some of the old projects to Quarkus.
And there was almost nothing to do.
So my clients were more than happy.
And another observation is there were different departments which always experimented with modern frameworks, whatever, reactive or whatever they tried, everything died.
So I cannot remember, you know, any instance where they experimented with something which was cooler than our boring choice and it survived.
So the learning from it is if you stay with the boring, you're building something for the future.
Otherwise, you'll just have something like a sandbox project that is changing quickly, and then you'll have a lot of headaches into maintaining an operational cost that comes with it.
And even though probably there is an asterisk to your affirmation about the old projects 20 years ago moving to Quercus is the same, probably you had to change the name.
But my clients were always surprised how easy it was.
So in one project, we were two persons, and I think...
three days and it was done more or less.
So it was mechanical work.
It's not like, you know, you need a planning.
And this was more than that because this was a really old project with JNDI or whatever.
So we have to replace JNDI lookups with injection.
So it was more than that because it was really old, but it still worked.
And why it worked?
Because patents back then were consistent.
Patents now are consistent.
There were no external dependencies.
So there was more or less mechanical conversion without AI even in this particular project.
We just did it manually.
And maybe if I may, what I did in Cluj, I also introduced BCE and the upcoming conferences I will talk about that.
What I found by accident is that AI really loves BCE.
So LLMs know BCE by heart because it's that old and they are really efficient building BCE structured projects, which is good for me because my old projects live even longer.
But more than that.
About BC, I think it's something specific to Java.
It's a secret sauce, let's call it, that is easier for the LLN to generate proper code in Java.
And that's, if I remember correctly from our previous discussions, is the way how Java works into adding new features in the language itself.
It's a very democratic process.
It's open.
And then you have specification that is very well documented.
And then you have multiple implementations.
May they be referenced or not, but it's easy to do.
How do you think the way how Java is built helps with being that easy to generate code in?
There are some studies from Tencent and even the plain study, if you just pick Java without anything, just plain Java SE, just the language.
As I remember, it's like the efficiency of LLMs generating clean Java code is like by 80% compared, I think, 60% Python and Node.js.
So even if you ask LLM to generate, you know, Java CLI applications without any framework, this is already better.
I apply a trick.
So this was an accident.
But how I always worked with JavaE, I ignored GlassFish, I ignored Quarkus.
I rarely read the tutorials from GlassFish.
Quircus, what I did instead, I read the spec.
And not really read, rather than scan the spec or search actively in the spec.
I usually back then had to know a folder with all the Java E specs were downloaded there and a full text search.
And if I had something to know, I found that.
And if the server behaved differently, I opened the bug.
So this was my approach back then.
So, okay, this is the spec, no discussion.
Would you like to be J2E certified or not?
This was my hard line.
If you would like to be J2E certified or Java E or Jakarta E, then do so and read the spec.
And then I thought, because all the specs were publicly available forever, LLMs have to know it.
And I was stunned how well they know it.
And then what I did, this was one year ago, started with it in my projects.
I grounded the LLMs against the spec and so far zero hallucination.
So I cannot remember any case.
where they invented an own non-existing annotation or, you know, whatever.
So they know Jaxxrace and so forth by heart.
And the cool story is why it works so well, because there was backward compatible.
Because the specs were backward compatible, whatever version they picked, it was always the same story.
This works that well that in most projects I have a skill or rules, or this is maybe...
100 lines of code, 100 rules, but most of the rules like, you know, don't generate too many unit tests, don't write stupid javadoc, never generate getters and setters.
These are the rules, not what exactly to do.
And you get code, which looks like my code.
So this is amazing how well it works.
And in all my projects, we're doing this right now.
And what I like about the fact is...
The LLM generates the same code as I would generate back then in Cluj, of course, with different namespaces, whatever, but it's the same ideas and principles.
So our discussion was September last year.
So autumn 2025.
And at that point, the trend was to use a cloud.md file or whatever it was the agent.md file.
But then we spoke after a couple of months.
And what you said is that you started cleaning up a bit.
How did your setup change?
Did you start using skills?
Because that's the new thing we are discussing now about context engineering.
But my feeling is that agents are getting more and more powerful and you have to even make your setup even leaner.
What's your impression?
What I did in Cluj back then, I presented before it was released Kiro.
So this was, I think in the week, Kiro is like Vision Studio Code Fork with spec-driven development, I remember.
And I also showed Cloud Code.
And this is why I didn't want to release that because I had one Cloud MD file and there were like 500 rules and there were everything I did.
So it was from CSS to Java to AWS Serverless.
Everything was there.
And I said, before I release it, I would like to clean it up, which actually happened.
So I think the beginning of this year, I released AI Rails.dev.
This is the website.
And these are the skills.
So basically what I had in Cluj is refactored right now to individual skills.
And interestingly, this is the AI implementation of BCE design of the ideas.
But to answer your question precisely, I have lots of skills and I have, for instance, one skill for Java CLI application.
I have one skill for unit testing.
I have one skill for microprofile server applications.
This is what actually would be compatible with the Cluj.
In one of my sessions, what I did is I used the old Cluj project.
I still found it with the distillery.
Use the skill to migrate it to Quarkus and it worked.
The idea of this is be a little bit faster, but create perfect code.
And the reason being is the most asked question in my sessions and workshops is, how well LLMs are working in huge projects.
So this is the pain point, you know, okay, this is in my greenfield, hello world, it works, but what about my project?
And my finding is the better the structure and the cleaner the code, the better it works in huge projects.
As you said, probably a lot of the Java code is big, bloated, and with a lot of wrong ideas.
So how would you approach this kind of project, especially...
During this period when it's the, let's call it the token wars, when everybody has to have the eyes on the fuel and that's the token.
Because obviously the context windows are getting larger and larger, but that means more chatty APA calls to the LLMs.
In yesterday's workshop, we find something interesting with BCE, Java standards, micro profile, no dependencies.
This is maybe exaggerated, but Cloud Opus, we did a little research.
Cloud Opus found out that we can save 88% of inference costs with this architecture.
So I think it's too optimistic, but I still remember 88, it was yesterday.
I would say even a half is good or 30%.
So how come?
If you would check out one of my BC projects and fire up Cloud Code, and let's say distillery in Cluj, I had...
For sure, distillery one.
Okay, what is BCE?
We should explain maybe what BCE is.
BCE is, I think, the simplest possible architecture.
The basic idea is in the root folder, only Java packages or web component namespaces or whatever are allowed.
And every package has to have a business name.
We call it component.
So distillery for Dracula, we had maybe ghosts and blood or whatever.
So this would be this.
And every component has always the same structure.
If there is an external API boundary, if there is some logic control, and if there is some data entity, that's all.
So the boundary control entity, we can explain to a developer.
This is why developers like it, actually, in five minutes.
So now, if you do distillery, and we then ask LLM to add another liquor, so what I remember is Horinka, Palinka, Zujka, right?
This is the...
Romanian liquors.
So from then, because I had to write it a lot, let's say we have a fourth one, right?
Alcohol-free beer.
This is up to date, right?
And then what you will see is that the Cloud Code picks a tool, searches on the top level for the right package and stays in the package.
And because Cloud Code or Cloud Code doesn't matter, LLM, like Cloud Opus 4.6 or DevStral from Mistral, for instance, or OpenAPI, CHGPT, they were trained on BCE and were trained on microprofile server and so forth.
They know boundary has to be Jaxores.
They know entity has to be JPA and they know what JPA is.
They know what JDBC is.
So with a three-word prompt, I can extend an existing component, which wouldn't be possible without standards.
Because if you don't have such standards, you have to put it in context.
And with standard Java, And BCE, the context can be almost empty because the LLMs know what I mean.
Okay.
So to just make sure that I got it correctly, the BCE pattern, you're just looking at, let's say, a package from the business point of view.
And you have all the needed points there.
Even though you might have some, let's say, redundancy, some code application, we don't touch it as we used to do previously.
When you split it on the business side and then...
you had these helpers and so on and so forth.
The BC keeps everything contained.
Maybe something like a modulate will be the heap name currently where you have modules where you have everything integrated.
And then each structure has the same.
So probably accounting is one and then HR, another and so on and so forth.
And that allows you to just copy the same structure easily.
And even when needed, you don't need to Just think about, okay, dry principles and so on and so forth to just be a lot of fuss about it and make even your words into copying that functionality.
Okay.
When should we think about extracting functionality that can be used in multiple places?
Because I know there is a huge debate about it.
There was the dry that were people pushing around and then it's the other one that says you should start extracting it when it's used more than a couple of times.
What's the golden number for you?
Without BC, just as a roll of thumb, what I do is one copy is okay.
And before I copy third time, I will try to abstract or whatever.
So I will copy first and see how it goes.
Because at the beginning of the project, the probability is very high that you will delete everything anyway.
So common misconceptions.
So if you need in a project audits or logging to meet your SLOs or whatever.
Then I would consider logging as a valid name for a component.
So I will put a logging component with all the logging stuff because it's actually required by the business.
And if I've shared components, it's not a problem that multiple components access the logic of a single component.
Maybe back then I always picked the example like Amazon orders and tax maybe calculations or the tax calculator is something internal.
And for that, it would be taxes with control and entity, but not boundary, because there is no reason to expose tax calculation, you know, country-specific tax calculation for AWS or, sorry, for Amazon customers, bookstore customers.
And if you have something like, let's say, string utilities is a big one, like is empty, is not empty, and so forth, there's nothing against.
Some projects are very text heavy.
So in this particular case, I will create a BCE component called text or text manipulation or whatever.
Just be specific what is inside and what is actually forbidden in BCE are names like util, common, foundation, because they are too generic.
And what I saw in projects is you will find everything there.
Best example is Java Util, right?
The Java Util package, if you open that, you have from date to functions to collections, everything is there.
I think maintainability means this is like one package, one business meaning, and you open without surprises what's inside, but the name has to be as specific as possible.
Thank you.
And because you mentioned, or I think you mentioned, it's about observability.
How do you feel about it?
Definitely it's useful, but also that field was a lot of roller coaster rides.
What's the simplest one from your point of view?
My observation is this OpenTelemetry wins right now.
This is the most successful project or most popular projects, even more popular than Kubernetes itself.
This is a CNCF project, OTEL, and especially in the age of agents, they have to be monitored and OpenTelemetry will be even more important.
And recently I added OpenTelemetry to Quarkus because of demand of my clients, but it is the right choice.
It is just standard.
And what also shifts a bit is back then we had metrics because storage was expensive.
But if you have good logs and AI, the question is, if you write nice logs, maybe you don't need too many metrics, right?
What can happen is this is the question, can I use LLMs or not?
Because if something goes wrong, you could ask LLM, you know, to analyze slices of your log and you get good answers.
This is my take and the SLOs.
Service level objectives have to be defined more or less by business.
But regarding observability, what I at least would like to have is a simple counter which counts successful and failed use cases.
How many books are ordered and how many orders failed?
Or even better, how many messages are received and how many poisoned messages occurred?
And if I have this...
It is already good because I can create an average or whatever and pass it to LLM and say, hey, watch this.
And if something happens, anomaly detection, just notify me.
So I think the counters are a must and nice dashboards are nice to have, I would say.
Well, who doesn't like a nice picture, right?
Is there anything else, Adam, that I should have asked you?
Yes.
How I developed the skills in BCE, because what I did, I ask always.
an LLM where is this a good idea?
And of course, it's a little bit dangerous to ask such a question, but the next question is why?
And so far, LLMs were very happy with BC.
We're also very happy, no dependencies, zero dependencies.
And what I stunned is, it was not very popular opinion, my opinion, zero dependencies back then.
So I was developing everything with scratch.
So now I'm just using what's in Java first and so forth.
And now I'm...
the fashionable guy, right?
So I'm full in trend now, which is the first time.
So I'm, I think maybe the first time not against the current, right?
Because with Quarkus, Serverless, native, GraalVM is cool.
I would say zero dependency is very cool.
And in one project, actually, we think about ISO security certification and it was my approach.
We are done, basically.
So actually there is almost nothing to do because we have no dependencies, just standards.
We only have to map, you know, the requirement to standard and My client is happy.
So they were also pleasantly surprised how well it worked out.
So you're a bit confused now when most of the people are listening to you, you don't have to do that many arguments.
All the same to me, you know, why we hired you.
This is normal, right?
So, okay, cool.
It was not, you know, in last few years, but yeah.
Okay.
Last question on my side, and then we can wrap.
You mentioned most of the trends.
There is another one, and that's the sovereignty part.
How do you feel about it?
I know that you mentioned AWS a couple of times and there are debates about it, meaning that even though Amazon and all the big three have boots on the ground, so they have data centers in Europe, they are still US companies and that means that data can move across the ocean.
But that's a topic for boardrooms, not for techies.
How do you look at it?
Because I know that Germany is quite sensible on privacy and then probably came out to you.
How do you ensure?
that you provide your customers also the needed privacy in cloud perspectives?
Yeah, first about cloud.
So before Corona pandemic, I was very happy with OpenShift and private clouds.
And I was more or less forced in some companies by management to go to the cloud.
And management couldn't justify it.
They say, hey, we are more agile and scalable.
This was the arguments.
And I say, okay, if we go to the cloud, we do it the right way.
not just moving whatever we have on-premise to the cloud and hope it will be better, because from my perspective, it will be only more expensive, but not better.
So we refactored everything to serverless, for instance.
So now we have the cloud, right?
Now I would be happy just to move everything because with Quarkus, it's not a problem where it runs.
Actually, our AWS Lambda serverless, they look like back then on-premise Docker containers.
So there will be not a big deal at all to move it back.
More problematic is the network infrastructure security permissions.
This is your cloud dependency, not necessarily Java.
And another dependency, which is even stronger, is the LLM.
You should not forget, because right now we get lots of mandates and how to use the LLMs, but the Opus runs in the US.
Could run in Frankfurt, but it's still AWS or Asia Foundry or AGI or Google GCP Vertex, I think is the name.
So LLMs is almost solved problem because I am able to run powerful models locally.
So I could actually develop, if I like, whatever we talk today locally.
I don't do this because all my clients are using remote models.
But I think next year we are that far that we get powerful models, open source models, which are good enough.
And the cool story is even the open source model, even more so.
They know Java really well, so I don't need the most powerful model because I don't care about esoteric frameworks, whatever.
It is good enough to know, you know, cut off date two years ago, and I'm happy.
I know German companies, which are great hosters.
I wouldn't have a problem to host there.
But the fact is that AWS, for instance, we host whatever we have in Frankfurt.
So there is not a lot of difference.
But if the management says, you know, this is still somehow a US company.
I'm not a manager, but if they say move it to our own cloud, I will be happy to do so because our applications run everywhere.
We will spend more time with infrastructure as code.
So what I'm a little bit concerned with, if we move back to private data center, their infrastructure as code is not as good as Azure or AWS, but it's cool projects.
Okay, management, if you like.
Give us a few months and we will replicate whatever AWS or Asia has and we will try to build infrastructure as code on your cloud, right?
Well, to just be a bit of a contrarian, as I learned from you, currently what I'm doing, I'm just trying to find tools, good old-fashioned tools that I can use in my terminal rather than doing everything in the cloud, in the terminal with the yellow lamp.
For instance, now I'm playing a bit with Transcriber, an open source project.
because it's possible.
So I want to see what are the limits rather than just going for the LLM, you know, keeping the saw sharpened mainly.
You are not contrarian because we do the same.
If you go to my GitHub account and you search for a project called with Z, ZEATS, and the ZEATS is zero dependency seeds, you will find maybe 20 to 30 terminal JavaScript, Java 25 scripts, we perform useful things.
Then, What you could like is ZSmith, also on my GitHub account.
And what is this?
It is Java 25 zero dependency agent.
And I use it.
It runs in terminal to automate things.
For instance, our podcast was pre-processed with Smith.
So what it does is it reads the transcript, finds links, finds the guests.
Of course, I read through it, but it's a great help because it finds more links than I would.
ZSmith and TornadoVM and GPULama.
So I tested that.
You will be able to run LLMs like DevStrell from the Hugging Face with one dependency, Tornado VM.
This is a specific JDK with Java locally.
And I see this also as future because inference, this is time of inference.
So a company is spending time to think, you know, how to run LLMs.
And with Java is our known process.
We already have Java.
So we put, you know, GPU Lama on it and we can run it without Olama, without installing because I'm...
more concerned about, for instance, what they do in CIHCD.
We will have to launch it, run it somehow with Java.
It's that easy.
For me, it's really hard to imagine how to do it with Python, for instance.
There will be so many dependencies and mess, and with Java is nothing.
Well, Tornado VM, that's a cool gimmick.
I have to talk to them as well because they build some cool stuff there.
Yeah.
And they released Tornado VM 4, which is way faster than the old one.
And I think it's a kind of a future.
It seems like it because in the end, the AI is getting now more into operational space.
And then obviously you don't do that much training anymore.
So you're just going towards inference where you're just moving to other type of loads.
And if you take a look at Uber, Amazon, most of the companies are running inference on Java, actually.
This is multithreaded and running Python in production.
You could do this, but I don't know whether it's a good idea if everything else is in Java, for instance.
Yeah, well, we're not going to debate that.
Not now.
Okay.
Thank you, Adam.