Michele Sciabarra

There’s no getting around it: resistance to vibe coding is futile. As I said on the call, for 40 years I’ve been the cobbler whose children go barefoot. I wrote applications for paying clients, but avoided writing code for myself because building my own apps USED TO take so much time that it WASN’T worth it. Whenever I needed something, I’d look for an existing solution—even a paid one. I’ve never had a problem paying for software. Vibe coding has changed all that. Building your own apps is now both practical and worth the effort. As I mentioned, I’ve already built about fifteen for myself over the past year and a half. And just yesterday, I had another perfect example. I’m always running out of disk space. It’s a longstanding problem, especially with a relatively small SSD: when your virtual machines take up 50 GB apiece, space disappears fast, and you’re constantly clearing things out. I’ve spent years—and I mean YEARS—looking for a decent utility to show me what’s taking up all that space. I’ve tried several and bought three, but none has ever quite worked for me. Too many clicks to start a scan, an unhelpful visualization, or some other little annoyance. Yesterday, faced with opening the same utility yet again—the one that never quite helps me find what I need to clear out—I thought: “You know what? I’ll just vibe-code one.” In the past, I would have called myself crazy. Six months of work to save a few hours? Today, the equation is different. It took me EXACTLY 20 minutes to build the app shown below. I spent ten minutes writing the initial prompt, then another ten tweaking the app as I used it, adapting it to what I actually needed. Then I spent more than 30 minutes publishing it on github.com/msciab/diskuse and writing this post—including five minutes wrestling with passwords just to log in. The repository also includes the exact prompt I used to generate it. No, this isn’t the end of programmers. That prompt contains specific technology choices—Rust and egui—an interface description, and technical details. Someone without that background would have taken longer, even with vibe coding. Programming has moved up a level of abstraction, just as it did with each step along the way: Assembly → C → 4GL → Visual Basic → Coding agents As some old skills become less useful, we need to acquire new ones. To paraphrase Kent Beck: AI has stripped 90% of my skills of 99% of their value, while making the remaining 10% worth 1,000% more. The one thing we shouldn’t do is fight the change. We need to embrace it. Take a cue from The Leopard: “Everything must change so that everything can stay the same.”

“Now that we have AI, we don’t need programmers anymore.” Hmm. Where have I heard that before? The story goes something like this. The quotes are made up. The refrain is familiar. The 1950s: FORTRAN. “You can now write formulas almost exactly as you would on a blackboard. No need to translate everything into machine instructions. We don’t need programmers anymore.” Now you don’t need someone to write assembly. You need someone to write the formulas instead. The 1960s: COBOL. “It’s practically English! The people in admin can write their own business software. We don’t need programmers anymore.” Exactly. Just explain what you want in English. Then find someone to fix your English until it compiles. The 1980s: fourth-generation languages, or 4GLs. “Just describe the result you want. Forms, queries, reports: the tool handles it all. We don’t need programmers anymore.” Now you don’t have to build forms in code. You build them in an editor. Once you’ve figured out how it works. 1991: Visual Basic. “Drag a window into place, add a couple of buttons, and your application is done. We don’t need programmers anymore.” Designing the screen is easy: a couple of clicks and it looks great. Saving the data and getting it back is another story. The 2010s: no-code takes off. “Connect the blocks, set up the workflow, and go live. We don’t need programmers anymore.” Now you drag components around instead of writing code. And fill in hundreds of settings, once you’ve worked out what they do. Occasionally, you even fill in that little hidden field called “script.” 2024: coding agents arrive. “Describe what you want, and AI writes the code. We really don’t need programmers anymore.” Right. You don’t need code anymore. You just need a precise description of what you want, detailed enough to specify the interfaces, databases, and APIs. In other words, you have to turn a vague idea into something precise enough for a computer to understand. Which sounds an awful lot like “programming.” We built Trustant to give developers everything they need in one place, not to replace them. Less time figuring everything out from scratch. Less reinventing the wheel. But the vision is still yours.

The trouble with vibe coding is that you still need skills to get decent results. Knowing what you want is essential, but knowing how to code matters too. If you don’t know what you want and can’t code, you’re heading for disaster. If you know what you want but can’t code, you can build something that looks the part. But without understanding what’s going on under the hood, you’ll soon hit a wall. You’ll be missing the engine: you won’t know how to steer the AI towards the things that really make a difference. Then there are people who can code but have no clear idea of what they’re trying to achieve—or what a customer actually needs. The temptation is to overengineer everything, throw in every feature imaginable, and end up with something nobody wants to use. If you know what you want and can code, you’ll get the best results. We designed Trustant to help both people who can’t code but need an engine, and developers who struggle to know when to stop. Trustant gives you a complete development environment. If you know what you want, it provides the technical foundation to build on. If you can code, it helps you stay focused on building what you need without going overboard. vibe-coding-results-en.png

Say you want to build an AI application. You open Claude or ChatGPT, or start with Lovable, describe what you have in mind, and get to work. Before long, you have something to show. So far, so easy. Then the client steps in. They see the demo, like it, and want to use it. But with their own documents, contracts, and data. And they ask you a question: “Where does all this information end up?” That’s when your prototype meets reality. An application is more than a screen with a chat box. Beyond the AI model and the user interface, there are databases, functions that run operations, file storage, and credentials. And the infrastructure that holds it all together. “We’ll put it in the cloud,” you might say. Of course. But whose cloud? Who manages it? Who has access? And when the application sends a document to the model, does that document stay within the boundaries you agreed with the client? You need to know who can see what, where the data is processed, and which providers your application relies on. Every external service adds something else to assess and manage. For some projects, that’s an acceptable trade-off. For others, direct control over the data is a requirement from day one. The client wants to decide where their information lives, who can access it, and how it is used. And you need a concrete answer. The usual answer is to move to the cloud. We offer a different approach: build the entire application within an environment you control. That’s what we do. Running local models on your hardware isn’t the part we provide. There are already plenty of ready-made solutions for that. We provide everything around them: the missing pieces that make a fully local solution possible. Read the diagram from the bottom up. On one side is the public services stack: cloud infrastructure, Claude or ChatGPT, services such as databases and functions, and finally a tool like Lovable to build the application. It’s a convenient way to get started, but how much control you have also depends on the terms and configuration of the services you choose. On the other side, we start with your hardware. Above that, Ollama or vLLM runs the models in your own environment. Then comes OpenServerless, which provides the application services layer. And on top sits Trustant, for building AI applications on that foundation. This is where Nuvolaris fits in: our products are OpenServerless and Trustant. Our goal is to connect the way you build an application with the way you run it, on infrastructure you control. To give you a path from a demo to a working system that can handle real company data. Before you write your next prompt, ask yourself: do you just want to build an AI application, or do you also want control over the environment it runs in? If your client is asking for both, let’s talk. We can help.

I read today that many freelance developers are finding themselves with no clients. That doesn't surprise me much, and it's not hard to see why. Companies have always hired freelancers to handle specific tasks, bring in skills they lack in-house, and maintain complex projects their internal teams don't have the capacity to support. But now clients can see that AI can handle some of that work at a much lower cost. If you're a freelance developer, you may not like it. But you have two options. The first approach—the one that doesn't work—is to ridicule AI, demonise it, insist the quality isn't good enough, and warn of all the terrible consequences to come. Meanwhile, the client has solved a problem. From their perspective, the result may even be better than what they got from a freelancer. Above all, they feel in control: they can experiment, make changes, and build on their ideas without waiting for someone to be available or being told, yet again, that everything needs to be rebuilt from scratch. That independence is worth a great deal to them. If your response is to tell them they shouldn't have it, you've already lost the argument. The second approach—the one that works—is to hand them what they want on a silver platter. Give them a complete, ready-to-use system with private AI built in, a database, storage, and all the services they need. An environment where they can build what they need, on their own or with a small internal team, while keeping control of their data. Your role becomes building and maintaining that environment, helping the client use it, and stepping in when needed to make sure it works as intended. The client gains independence, and you provide the expertise that helps them get results. We built Trustant for clients who want to develop their own software. And we see freelance developers as the partners who guide them and help them succeed. Don't fight AI. Make it your ally.

Is AI making you a little nervous? Worried it might cause you a few headaches? Fear not: here are 12 practical ways to solve the AI problem. Ignore it: carry on as if it doesn't exist. Feel superior: “I'm better than AI. I have nothing to learn.” Demonize it: “AI is going to kill us all.” Mock it: insist that anything made with AI must be rubbish, no matter what. Downplay it: “It's just a fad. It'll pass.” Belittle its users: “If you need AI, you're not a real professional.” Discredit it: “It doesn't understand a thing. It just strings words together.” Look for proof that it doesn't work: spot a single mistake and use it to dismiss the whole thing as useless. Keep moving the goalposts: whenever it manages to do something, decide that the real value lies somewhere else. Claim you're the exception: “My industry is different. It'll never work here.” Glorify the past: “People used to take pride in their work. These days, nobody knows how to do anything.” Ban it on principle: stop people from using it without even considering what it could do. Bonus: use private AI systems that you control—and a tool that lets you build private AI solutions using that same private AI: Trustant.

With the rise of #VibeCoding and in general of AI-generated code, we keep hearing a comforting story: vibe coders churn out a mess, while software engineers write clean, elegant, well-structured code. A convenient story if you’re trying to reinvent your career. But put that way, it’s #bullshit. Anyone who’s worked on a codebase that’s been around for years knows the reality. Endless functions. Abstractions that no longer make sense. Three ways of doing the same thing. Comments describing a version that died in 2019. Code nobody touches because “last time, we took down production.” This happens in software built by paid professionals, with technical leads and architecture meetings. Production code can be every bit as messy as vibe-coded software. It gets there for very human reasons: deadlines, changing requirements, people leaving, customers demanding exceptions. Temporary fixes become permanent. Refactoring gets postponed. New systems have to coexist with old ones. Clear structure makes code easier to understand and change. It doesn’t guarantee reliability. An elegant program can still crash spectacularly. The difference between a vibe-coded demo and a production system is the infrastructure holding it together. How do you know it works? How do you catch a regression? What happens when something inevitably goes wrong? On a large system, nobody reads every line. Modules are treated as black boxes. Whether a module comes from AI or an outsourced developer, it needs checking. Reliability isn’t something you assume. It’s something you manage. That’s where the engineering comes in: • Checks: changes go through reviews and automated checks before reaching users. • Tests: someone defines the expected behaviour and checks failures, edge cases and integrations. • Guardrails: restricted permissions, input validation and operating limits keep a local error from becoming a major incident. • Observability and recovery: logs, metrics and alerts expose problems; rollbacks and recovery procedures let you respond. • Documentation: requirements, constraints, dependencies and procedures are explicit. The next person needs to understand the system and know what to do when it breaks. You verify the code, contain the risks and keep it maintainable over time. A software engineer’s value isn’t “I wrote this myself, so it must be good.” It’s knowing what to check, which risks to contain and what evidence you need before trusting the result. That’s the thinking behind Trustant. It isn’t a code generator. It’s infrastructure for managing code and keeping it under control.

I’ve never heard responses like these so often: “We’re not interested in AI.” “We don’t use AI in our business.” But they don’t surprise me, even though the conversations we were having just a year ago were very different. A couple of years ago, we mostly worked with innovators: people who wanted to understand the new technology, experiment and learn. Last year, everyone was enthusiastic, and we had plenty of requests for projects to help them get started. This year, the mood has changed, and blunt dismissals are everywhere. But this pattern was already familiar to me. Two well-known models help explain it: Gartner’s Hype Cycle and Geoffrey Moore’s Crossing the Chasm. The first describes the journey from inflated expectations through disillusionment to a more mature use of technology. The second focuses on the difficulty of moving beyond the early enthusiasts to reach the first wave of pragmatic mainstream customers. They describe different phenomena, but both help make sense of what we’re seeing: once the initial excitement fades, winning over the next group of customers takes more concrete evidence. I’ve also been struck by what some potential partners have told us: despite their efforts to sell AI solutions to their clients, they haven’t seen much of a return on their investment so far. And then, in a lower voice, they add: “These days, even supermarkets are selling AI. Three for the price of two: buy subscriptions to Claude and ChatGPT, and we’ll throw in Gemini for free.” We saw that risk coming. Even as requests for bespoke AI solutions were pouring in, we asked ourselves: how long will this momentum last? If we want to build something that lasts, we need to invest in a solid product. That decision led to Trustant, our private AI product. We’re proud of it because we designed it for businesses that tell us: “We need a structured, coordinated approach to adopting AI across the company.” This is the audience Moore calls the early majority: pragmatic customers who want to understand how a tool will improve their work and what results they can expect before they adopt it. We’ve focused on productivity and the barriers to adoption, aiming to give businesses what they want: a reliable tool for building their own AI applications with the help of AI, in a private environment. So while others selling consulting services are battling disillusionment and falling into the chasm, we’ve been preparing for mainstream adoption.

Yesterday a close friend called to ask if everything was okay, since he hadn't seen me post on LinkedIn for a few days! The truth is, when something's brewing, I tend to keep my cards close to my chest. I'm waiting until everything's ready to make the big announcement. We're gearing up to launch Trustant, our Private AI Builder, which plenty of you have already seen and know about. But this will be a proper launch: we're releasing the code on GitHub, timed to coincide with the release of Apache OpenServerless 0.9.0. To give you an idea, this is the home page of the new Trustant website (I bet you can guess the domain and find it yourselves...). So shhh, just a few more days and Trustant goes live! There's still loads of work to do, but we're nearly there...

With my usual "build in public" approach, I'm sharing what we're up to. We're getting ready for the open source launch of Trustant, and we're at 99% now — just finishing touches. One important thing is making an intro video, so I've been working with video generation, which from what I've seen is much more practical than the classic screencast-and-edit approach. Here's a first experiment at a Trustant intro. What you think?

With Trustable, we’ve built a vibe coding system that lets you create AI applications from prompts without needing deep technical knowledge. The infrastructure handles the system details for you. The project has a lot in common with Lovable, the well-known app builder. The main difference is that Lovable is a cloud-based SaaS platform, while our system is fully private and self-contained, and uses private AI. In other words, it’s a system you can trust to keep your data within your own environment. So calling it Trustable felt natural. Unfortunately, the name is already registered, so we need to change it before the official launch. But we want to stay close to the idea of a “Trustable Assistant.” That’s where our new name, Trustant, comes from. Trusty, the nickname we’ve been using, is now also the name of our mascot. Over to Trusty to introduce Trustant!

The point of vibe coding is to give AI the right context to work in. It needs something to work with, clear instructions, and an environment where you can test what it produces. Vibe coding is like a chisel. Use it carelessly and you’ll make a mess. You need good material, a steady workbench, and someone who knows what they’re doing. You have the chisel. But you also need quality marble, a workbench, safety glasses, and a steady hand to hold the square in place. That gives you an idea of what Trustable offers people building applications with private AI. Because when you ask AI to “build an application for my business,” you still have plenty of decisions to make. Where does the data go? Which model processes it? Which database does the application connect to? Where will you run it? And when you change something, how do you check that it still works? You can have your first screen in minutes and still have all of that work ahead of you. With Trustable, we provide the infrastructure for private AI and a guided environment for building your applications. You can start with existing applications and templates, modify them with AI, and adapt them to the way you work. You have a foundation to build on and services to connect to, rather than having to build everything from scratch each time. The marble is your starting material. If you want to build an application for searching company documents, for example, you need to decide which documents to make available, how to search them, and who can access them. Writing the prompt is part of the job; preparing that context is another. The workbench is Nuvolaris, the platform your applications run on. You can choose infrastructure that suits you, from an office server to your company’s data centre, and run private models on your own hardware. The safety glasses and steady hand are reminders that you also need safeguards and oversight. A private environment lets you decide where your models and applications run. Developers still need to review the code, check access permissions, test the results, and fix errors. AI can help with these tasks too, but someone has to check that the application does what you asked for. That’s what we’re working on with Trustable. We want to give you the tools to build useful applications for your business, with your own data, on infrastructure you control. If you’d like to try it, send me a private message and tell me what application you’d like to build.

After almost two years of work, we're finally voting on the official Apache Software Foundation release of Apache OpenServerless 0.9.0-incubating! Join us and cast your vote! The software has been available for some time through a CLI that downloads Docker images. But distributing ready-to-run binaries isn't enough for an official Apache Software Foundation release: the source code must always be included. That's the “source” in “open source.” So an official Apache release takes more than a public GitHub repository with a permissive license. There's a lot more to it. Our first hurdle was preparing a source release for an application that runs on Kubernetes, consists of around twenty Docker images, and is managed through a CLI and an operator. To verify this release, we have to compile all the source code locally, build the images, and use them to deploy and test the application on a cluster! Then there are all the policies we need to follow. Security and vulnerability handling, for a start. Then licensing: not every open source license is compatible with Apache's distribution requirements. It isn't just about allowing commercial use. The obligations and restrictions that come with each license matter too. We had to revisit quite a few details. There are also specific rules for naming and distributing artifacts. Release archives for a project in incubation must include incubating in their names. Development images must be clearly identified, for example with a snapshot tag, so they can't be mistaken for an approved release. On top of that, there are voting procedures, discussion guidelines, and a requirement to make decisions on the mailing lists. For the past two weeks, I've been working full time reviewing source code, checking file headers, rebuilding images under different names, fixing the website, and responding to security reports. It took five release candidates to get it right. But today, it finally looks like we're almost there. I say “looks like” because the release isn't official yet. We've reached the required number of positive votes in the project's vote, but we still need approval from the Incubator PMC (IPMC) through a second vote. You don't have to be part of the project to vote: non-binding votes are welcome too. It's also a way to grow the community. So join the mailing list — you'll find the details on the Apache OpenServerless website — give the release a try, and cast your vote. This release is also an important prerequisite for Trustable, the project we'll be launching right after it. To get a sense of what Trustable is, imagine doing what you do with platforms like Lovable or Replit, but locally, on your own PC, using your own GPU. It's all built on Apache OpenServerless. Many of you have offered to lend a hand. Here's where to start: try the release, take part in the vote, and introduce yourself to the community!

Vibe Coding gives your creativity an instrument. It turns a hunch into code, an idea into an interface, a prompt into a first working application. But a guitar alone will not get you ready for the stage. You need tuning. You need the set list. You need an amplifier. You need a rehearsal room where you can make mistakes, fix them, record, listen back, and be ready to play in front of an audience. In software, the stage is production. A demo can sound good for thirty seconds. A real application has to handle users, data, errors, secrets, logs, cache, storage, queues, rollbacks, backups, monitoring, and updates. It has to know where the models run, where the data lives, who has access, and what happens when something breaks. This is where many vendors lead you back to the cloud. They give you the sound system, the stage, and the sound engineer, but on one condition: you play in their venue. Your code, data, processes, and know-how end up inside infrastructure you do not control. At first, that feels convenient. Then you find out that changing venues is expensive, moving your gear is hard, and every show runs through someone else's box office. Trustable does the opposite: it brings the stage into your infrastructure. It gives you what you need to turn vibe coding into reliable AI applications: Kubernetes, OpenWhisk, Redis, storage, monitoring, automation, reproducible environments, deployment, and operational support. Not as parts you have to assemble by hand, but as a platform that can start on an AI workstation, grow onto servers you own, and move into a sovereign data center when needed. Vibe Coding is the guitar. Trustable is the tuning that keeps you from hitting the wrong notes, the set list that keeps the band together, the amplifier that carries the sound through the room, and the rehearsal space where the application becomes solid enough for production. On your infrastructure, with your data, under your rules.

When people talk about vibe coding, they usually make the same point: building a prototype with a couple of prompts is one thing; shipping a real production application is another. True. The weak point is in the seams. The interface is only the visible part. A real application also needs databases, cache, queues, storage, models, logs, backups, deployment, rollback, secrets, environments, networking, and monitoring. Most of all, it needs all those pieces to work together. A demo can ignore that. A real system cannot. Vibe coding is the needle: it lets you move quickly from an idea to a shape. But a needle alone does not make a garment. Without the right thread, a pattern, pinned fabric, and proper measurements, you get something that only looks stitched together until someone actually tries to wear it. This is where many vendors lead you back to the cloud. They offer everything the prototype is missing. It works, but your code, data, processes, and know-how end up living inside someone else's infrastructure. The shortcut becomes a dependency. The garment starts taking the shape of the tailor who owns it. We do the opposite: we bring the cloud into your own infrastructure. Trustable gives you, inside your own environment, what teams usually go to the cloud to get: ready-to-use services, deployment, storage, monitoring, security, automation, reproducible environments, and a clear path from prototype to production. You do not have to assemble every piece by hand, chase scattered components, or reinvent the platform before you can build the application. With Trustable, it is easy to start on an AI workstation, run private models, operate the services your application needs, move the workload to servers you own, and deploy to a sovereign data center when the time comes. Same approach, same control, same freedom to choose. Vibe Coding is the needle. Trustable is the thread that holds the pieces together, the pattern that prevents tears, the pinned fabric before the cut, and the measurements taken before sewing. So the application stops being a polished demo. It becomes something you can run, control, move, verify, and maintain. On your infrastructure, with your data, under your rules.

Forget cloud AI: models like Qwen3.8, with just 27B parameters, are now in the same league as Opus. They can run on a gaming GPU or a DGX Spark, and they are within reach of an individual professional or a small company. Yes, these models generate code. And they do it well: at Claude level, to put it plainly. Without forcing you to pay for every token, or hand over your know-how and the information needed to generate and run your applications. Vibe Coding is the brush, but you still need the infrastructure. That is why, even when AI is private, they will still try to push you back into the arms of the cloud. So you use their infrastructure. And so they can charge you for it not once, but one drop of blood at a time, at ten times its real value. Keeping you by the throat. Taking away your freedom. Forcing you to adapt. Not anymore. If Vibe Coding is the brush, Trustable is the canvas you paint on, the easel, the palette, and the apron that keeps you clean. And we provide all of it. You can create your AI applications on an AI workstation, move them to workstations and servers you own, and deploy them in any sovereign, secure data center. The deployment choice is yours. And the entire stack is fully open source. If your freedom and control over your own destiny are a priority, get in touch: we may show you that there is a world that refuses to surrender to cloud AI dependency and still gives you the freedom to choose.

You want to bring AI into your company, but you are facing the familiar constraints: protecting your data and your customers' data, building new AI-powered applications, and managing their development with AI itself. Where do you start? We have listened to our customers and built the solution they were looking for. Trustable is, first and foremost, a private AI platform that makes it easy to use open models. But it is also an AI-assisted development environment for building the applications you need: agents, document access, automations, and private business applications. You can build on open source, private, scalable, and universal infrastructure, whether that means an office server, your corporate data center, or the sovereign provider of your choice. And when the opportunity makes sense, you can still use hyperscalers without being locked into them. To help you get started faster, we provide a broad set of ready-made applications that you can use and customize with AI, along with templates for creating new applications simply by editing prompts. All this, and much more, is Trustable. It is available in private test today. Contact us to join a demo webinar, request the free download link, or become part of our tester group. If you have a GPU, you can run your own private models. But a PC or Mac with 16 GB of memory is enough to get started. Before investing in private hardware, you can also use AI through Ollama Cloud or the sovereign provider Regolo, both with a Zero Retention Policy. DM me if you want to download and test it, and join the tester whatapp group.

They pitch you an AI solution. They tell you it runs locally. They promise your data is safe. But when it is time to go to production, they push you straight into the arms of a cloud provider. So much for privacy and control over your data. That is not how we think. Our infrastructure is based on Nuvolaris, and it runs locally. The entire serverless infrastructure runs on your PC. The applications you build can scale because they are built on a serverless engine powered by Nuvolaris. Trustable is the only AI-assisted development system designed to scale while protecting your data. Nuvolaris is serverless. It gives you everything you need to build AI applications, but it does not depend on any cloud provider. And it supports them all. Start from an AI workstation and build your AI applications. Grow them, move them to a company server, or run them in a sovereign data center. And move them from one provider to another. Others take your AI applications to the cloud. Nuvolaris brings the cloud for AI to you.

First preview of Trustable 0.4, now with templates for your #LocalAI applications! Imagine having a #VibeCoding system for creating AI-generated applications, with ready-made instructions for building exactly the apps you need. For example: RAG, agents, internal automations, database access, email, and documents. Imagine having a library of templates that lets you create your application in minutes. Imagine being able to customize those templates simply by editing a description. Imagine not having to worry about SQL and vector databases, caching, scalability, Kubernetes, or Docker images, because the #serverless system already knows how to handle them and creates applications that are secure by default. Imagine being able to run your applications wherever you want: on your internal server, in a trusted data center, or with the cloud provider that gives you the guarantees you need. Anywhere. Imagine being able to build templates with an editor and share them with others in a marketplace. All of this is the new Trustable 0.4. In the video, you can see a demo of Trustable in action, generating a suite of applications from a template. There are also templates for AI applications that access databases, email, and documents. And if you do not want to generate them, you can use the ready-made ones. If you would like to try it and join our tester group, contact me privately.

Most AI users only interact with free cloud tools, or with AI features built into consumer products. As a result, many people still do not realize how powerful open models have become. You still hear people say that open models are limited, or that "there is no comparison" with proprietary models. That is simply no longer true: the most powerful model available today, Kimi K3, is an open-weight model. Here is a snapshot of the landscape as of July 2026. The table above summarizes the comparison between proprietary models, local AI models, and private AI models. On one side are the benchmark closed models, especially those from OpenAI and Anthropic. The reference point is the capability level people associate with ChatGPT: in 2022, ChatGPT 3.5 took the world by surprise; in 2023, GPT-4 raised the bar; then came more optimized versions such as GPT-4o and the later model families. Anthropic followed a similar path with Claude, moving from Claude 2 to later generations of the Claude 3 family and beyond. At the same time, open models began catching up. I divide them here into two categories: local AI and private AI. By local AI, I mean models that you can run today on hardware accessible to an individual or a small studio: an AI workstation around EUR 5,000, a DGX Spark, a Mac Studio, or a machine based on AMD Strix Halo. These are not toys. As the table shows, compact versions of Qwen, GLM, and Mistral can deliver surprisingly strong capabilities for their size. Above that range, I use the term private AI: open-weight models that require powerful servers, or multiple machines connected in a cluster, but can still be run inside your own infrastructure. Frontier models such as GLM 5.2 belong in this category. The most powerful model right now is Kimi K3. As a model with roughly 2.8 trillion parameters, it requires many GPUs and serious infrastructure. But it is still an open-weight model. With the necessary investment, it can be run in a private environment, without paying token fees to an external provider and, more importantly, without handing over knowledge, which is the most valuable asset any organization has.