In the first part of this series, we talked about the Decision Node Audit. We mapped out the internal workings of our AI system to pinpoint the exact moments it makes decisions based on probabilities. This told us when the system needs to be transparent with the user. Now, the big question is how to share that information.

You’ve got your Transparency Matrix ready. You know which behind-the-scenes API calls need a visible status update. Your engineers are on board with the technical aspects. The next step is designing the visual container for those updates.

We face a legacy problem. For thirty years, interface designers have relied on a single pattern to handle latency: the spinner. The spinning wheel, the throbber, the progress bar. These patterns communicate a specific technical reality. They tell the user that the system is retrieving data. The delay is caused by bandwidth or file size.

AI agents introduce a new kind of wait time. When an agent pauses for twenty seconds, it’s not just downloading something; it’s thinking. It’s figuring out the best steps, weighing options, and creating the content you asked for.

If we use a basic spinning icon for this “thinking time,” users get confused and anxious. They watch a looping animation and can’t tell if the system is stalled or crashed. They don’t know if the agent is handling a very complicated task or if it has simply failed.

To build user trust, we need to turn this waiting time into a moment for reassurance. Instead of a passive “something is happening,” we need to communicate an active, “Here is exactly how I am working to solve your problem.”

Writing Clear Status Updates

We often think of transparency as a visual design problem, but it’s really about the words we use. Simple, clear explanations (the microcopy) are what build trust and separate a reliable AI from one that feels broken.

We need to retire generic placeholders like Loading or Working. These words are remnants of the era of static software. Instead, we must construct our status updates using a specific formula that mirrors the agency of the system. Let’s stop using vague words like “Loading” or “Working.” Those terms belong to the past, when software was simple and static. Instead, we should create status updates that clearly tell the user what the system is actually doing and make the system’s actions transparent.

Imagine, for the sake of an example, you are deploying agentic AI that will help team members organize their calendars and plan recurring meetings on their behalf, once prompted.

When an AI displays a message like “Checking availability” for an unknown amount of time, users often feel lost because it doesn’t offer enough information. While they understand the AI is looking at a calendar, they don’t know whose calendar it is, what other steps are involved (before or after), or if the AI even remembered the people and purpose of the scheduling request. Waiting for the final result can be a tense, uneasy experience, like anticipating a gift that you suspect might be a prank.

Perplexity AI provides a strong example of doing status updates right. Figure 1 below shows that when users ask a question, the interface displays exactly what it is doing in real time. You see a list of activities updating as they are accomplished. Users do not need to guess what is happening as the AI works.

The Agentic Update Formula

To give people useful status updates, we need to connect what the system is doing with why it’s doing it. Keeping with our scheduling agent example, the system should break down that waiting period into at least four clear, separate steps.

• First, the interface displays Checking your calendar to find open times for a recurring Thursday call with [Name(s)].
• Then, it updates to: Cross-checking availability with [Name(s)] calendars.
• Next, it might display: Syncing [Name(s)] schedules to secure your meeting time on [Data and Time].
• Finally, at the conclusion, the agent might state they have successfully completed the task and request the user check their email to confirm the invite that’s been shared with the group having the recurring meeting.

This communication process grounds the technical process in the user’s actual life.

Making an AI’s progress easy to understand boils down to a three-part structure: a strong Action Word, what the AI is working on (the Specific Item), and any Limits or rules it has to follow.

Think about an AI helping you book a trip. A weak, unhelpful update would just be: Searching for flights…

A much better update uses the formula:

• Action Word: Scanning
• Specific Item: the prices on Lufthansa and United
• Limits/Rules: to find anything under $600.

This approach clearly shows the user that the AI understood their request and is working within the set boundaries.

Matching Tone to the Risk Matrix

Should an AI sound like a person or act like a robot? The right answer depends on the task’s importance, which we can figure out using the Impact/Risk Matrix from our Decision Node Audit.

For simple, low-risk tasks, a friendly, conversational tone works best. For example, a scheduling assistant can say it’s checking your calendar for the best time. This creates a comfortable, easygoing experience for the user.

However, high-stakes tasks demand clear, mechanical accuracy. If the AI is managing a big financial transfer or a complicated database migration, users don’t want a playful interface; they want precision. A screen that says “I am thinking hard about your money” would possibly cause panic. Instead, the interface should use straightforward language like “Verifying account routing numbers.” By adjusting the AI’s “personality” to match the level of risk, we give users exactly the experience they need in that moment. While the Impact/Risk Matrix provides a necessary starting point, the ultimate determinant of the appropriate AI voice and tone is rigorous user research.

It’s impossible for any set of rules to predict the exact words or tone that will build trust or cause stress for every group of users or in every situation. That’s why hands-on research is essential. You need to:

• Run A/B tests on different ways the AI “talks” to people.
• Conduct usability studies to see how users react emotionally to the system’s messages.
• Perform interviews to truly understand what users expect from an AI in terms of openness.

This kind of research ensures the AI’s “personality” is comfortable and appropriate for the actual people who will be using the system in their specific context.

We’ve now covered the “what” — the critical microcopy, the clear action words, and the necessary limits that make an AI status update honest and informative. But words alone aren’t enough. A perfect sentence hidden in a poor interface is still a failure of transparency.

The next challenge is the “how” — designing the physical delivery system for that message. You can think of the status update formula as the engine, and the interface pattern as the car. A powerful engine needs a reliable, well-designed chassis to carry it down the road.

Interface Patterns: A Library For Agents

Once we have the right words, we need the right container. The key is matching the message’s weight to the pattern’s visibility. A tiny background task (like an agent gently tidying up your files) doesn’t need a loud, flashing banner. That message is best delivered subtly. A high-stakes, multi-step process (like moving money) potentially demands a more robust container that forces the user to pay attention.

By creating a library of these patterns, we ensure the right level of transparency is delivered at the right moment, turning the anxiety of waiting into a moment of informed confidence. Let’s review a few common, critical patterns.

The Living Breadcrumb: AI Working in the Background

For those low-importance tasks that an AI is handling quietly in the background, we need a way to show users it’s working without constantly distracting them. We can call this the living breadcrumb.

Think of an email app where an AI is drafting a reply for you. You don’t want a disruptive pop-up message. Instead, a small, subtle status indicator pulses within the application’s border or menu area.

The solution needs to go beyond a static icon. The living breadcrumb smoothly transitions between different text updates. It might pulse from Reading email to Drafting reply to Checking tone. It’s there if you want to check on its progress, offering a quiet assurance that the task is underway, but it won’t demand your immediate attention.

Dynamic Checklists

When dealing with critical, high-stakes tasks — like processing a complex financial transaction or migrating a large, intricate dataset — we recommend using a Dynamic Checklist (illustrated in Figure 3).

This pattern serves as a powerful anchor for the user, providing clarity and confidence about the process’s progress. Instead of a simple bar, the Dynamic Checklist lays out every planned step the AI agent will take. It clearly highlights the step that is currently in progress, marks preceding steps as complete, and lists future actions as pending.

For example:

• Step 1: Verify Account Balance [Complete].
• Step 2: Convert Currency [Processing].
• Step 3: Transfer Funds [Pending].

The Dynamic Checklist offers a significant advantage over a traditional progress bar because it expertly manages unpredictable time. If the currency conversion (Step 2) unexpectedly requires an extra ten seconds, the user won’t feel sudden anxiety or panic. They have full visibility into the system’s exact location, understanding that the delay is occurring during the Converting Currency step. Because they recognize this is a potentially complex action, they are naturally more patient and trusting of the system’s ongoing work.

The pattern itself is a compelling UI idea, but designers must remember that its implementation transforms the task into a full-stack design requirement. Unlike a simple loading flag, the dynamic checklist requires a robust front-end state management system to listen for step-completion events, which are typically triggered by a back-end webhook structure. This ensures the interface is always reflecting the agent’s real-time position in the workflow.

The Thinking Toggle

Some users with higher information needs or higher needs for transparency may not trust a simple summary; they want to see the system’s raw processing. For this audience, we’ve designed the Thinking Toggle.

This is a simple progressive disclosure UI control, like a chevron or a “View Logs” button, that lets the user expand a friendly status update into a raw terminal view. It displays the sanitized logic logs of the AI agent, such as:

• Querying API endpoint /v2/search;
• Response received: 200 OK;
• Filtering results by relevance score > 0.8.

Many people will never open this view. However, for the user who needs deep transparency, the very presence of this toggle is a signal of trust. It reassures them that the system is not concealing anything.

Keep in mind, with this deep transparency comes a critical technical risk. Even for your most expert audience, you must sanitize and abstract these raw logs before display. This step is non-negotiable to prevent accidentally exposing proprietary business logic, internal data structure names, or security tokens that could be exploited. This process ensures trust is built through honesty, not security vulnerability.

Designing For Partial Success

In standard software, things are often black or white. A file either saves or it doesn’t. But with AI agents, things are often grey. An agent might plan most of a trip perfectly, yet struggle to book that one special restaurant.

We need to design for when the AI is mostly successful.

Standard binary (yes or no) error messages are trust-killers because they suggest the AI failed completely. If an agent does 90% of a task and only misses the last 10%, a big red “Request Failed” banner is misleading.

Instead, the interface should clearly show what worked and what didn’t:

• Flight booked: UA 492 [Success].
• Hotel reserved: Marriott Downtown [Success].
• Car rental: Hertz [Failed — No inventory].

This way, you only have to step in and fix the parts that failed, like booking the car yourself, while keeping all the good work the agent already did.

Disentangling The Tool

When an AI system doesn’t perform as expected, it’s crucial to be absolutely clear about the true reason for the failure. Users often mistakenly blame the AI itself for problems that are actually caused by an external service or tool the AI relies on.

For example, imagine a virtual assistant tries to look at your schedule, but the connection to the Google Calendar API is down. The error message shouldn’t make the assistant look like it failed to do its job.

• Less helpful: “I could not check your calendar.” (This suggests the assistant is incompetent.)
• More helpful and honest: “The Google Calendar connection is not responding. I will automatically try again in 30 seconds.”

The first message is frustrating because it makes the AI look like it failed. The second message, though, is much clearer. It explains that the AI is capable, but a broken tool outside its control is causing the issue. This distinction is really important because it keeps the user from losing faith in the AI, even when things go wrong.

The Audit Trail: Trust After The Fact

Real-time transparency is fleeting. If a user walks away from their desk while the agent is working, they miss the Dynamic Checklist. They return to a finished screen. If the result looks odd, they have no way to verify the work. This is why every agentic workflow requires a persistent Audit Trail.

We need to design a Show Work interaction. On the final result screen, provide a link or history log that allows the user to replay the decision logic.

• See how this price was calculated;
• View search sources.

This receipt is the ultimate safety net. It allows the user to spot-check the validity of the output. Even if they never click it, the mere presence of the receipt tells the user that the system stands behind its work.

ChatGPT provides an example of how now providing users with an easy way to audit the information AI uses can cause confusion or user frustration. ChatGPT remembers you in the way a file cabinet quietly fills up with notes about everything you’ve ever said, then uses those notes to shape every future conversation without telling you. This is called memory. According to developer Simon Willison, in April 2025, that memory was getting fed into every new conversation automatically.

The problem with ChatGPT’s memory at that time was that you couldn’t see what it remembers, or when it’s using that information, or how it’s influencing what you get back. There’s no log. No timeline. No plain-language list of “here’s what the AI has decided about you.”

The only way to glimpse the dossier was to know a specific prompt trick — essentially asking the model to quote its own hidden instructions back to you. Most users will never discover this. They’ll just notice, as Willison did, that ChatGPT placed a “Half Moon Bay” sign in the background of an image they generated (Figure 8) because it had silently cross-referenced their location from previous conversations. This is the absence of transparency (the ability to audit the memory with ease) disguised as personalization. You need to provide users with both.

The Audit Trail pattern is the ultimate solution to the memory audit problem demonstrated by ChatGPT. It is one of four core design solutions that, together, create a library of options for improving AI transparency.

Here is a quick summary of the key interface patterns discussed in this article, which are designed to transform AI waiting time from a moment of anxiety into an opportunity to build user confidence:

Table 1: Four design patterns enhancing transparency.

The Reality of Attention: When Users Ignore the Interface

Even the most perfectly designed checklist or the clearest status message may still go ignored by many users.

When people are working on tons of tasks, especially professionals, they often tune out the interface. Think of an insurance underwriter creating fifty quotes a day — they’re not watching a progress bar. They click “Generate,” switch tabs to answer an email, and only come back when the task is done.

My research with these experts shows they judge the system based entirely on the final result. They have a good idea of what the answer should be. If a salesperson expects a premium between $500 and $600, and the system returns $550, they accept it right away, and trust is established.

These experts tell me that over time, as the AI continues to provide what they perceive as accurate outputs, usage will increase, and they will save time versus manual quoting. Essentially, the system is now viewed as an efficient accelerator of an otherwise monotonous yet mandatory task.

But if the system returns $900, the user stops. The output is not aligned with expectations, and that’s a problem they must solve. At that moment, the user switched tabs; they missed the little explanation about the high-risk surcharge that popped up in real-time. They didn’t see the specific rule that was triggered. If that explanation disappeared with the progress bar, the user has no way to understand the difference between expectation and outcome. They certainly won’t run the query again just to watch the animation play out.

They will run the quote by hand, effectively treating the AI’s output as useless and initiating a complete rework of their effort. This manual recalculation feels like a waste of time, which further erodes their confidence in the tool. Once this happens, the user is not interested in why the system chose $900; they are focused purely on validating or invalidating the system’s accuracy against their own, trusted methods. This lack of transparency, especially in moments of disagreement, is a primary barrier to adoption and consistent use. The audit trail allows us to provide persistent transparency and is the mechanism that prevents the AI from creating more work.

We need to keep this in mind, particularly when delivering AI-powered tools meant for enterprise use. If the tool delivers a result that misaligns with expectations, you rarely get a second chance. If the user must spend ten minutes investigating why the AI provided that number, they will stop using the AI.

Predictability, Reliability, and Understanding Are The Product

We are not building magic tricks. A magic trick relies on misdirection and hidden mechanics. We are building colleagues.

Think of a good colleague, they keep you in the loop. They let you know what they’re up to, what’s taking their time, and when they hit a snag. That honesty is what helps you trust them.

We can apply this to AI. By using the practical patterns we discussed: giving specific updates, showing a dynamic checklist, acknowledging partial wins, and keeping an audit trail, we stop seeing AI as a mysterious black box that just needs a nice coat of paint. Instead, we start treating it like a team member we can rely on and manage, which builds trust and a clear understanding.

The main reason for using these interface ideas is to achieve real transparency, going beyond explaining the AI’s complicated inner workings. Here, transparency means showing the user the AI’s process and performance right when they need to see it. This involves plainly communicating the AI’s current status, its known limits, and an easy-to-follow history of its decisions. This level of openness changes the interaction from just accepting what the AI does to actively working with it. It lets users understand why they got a certain result and how they can best step in or guide the system for the best possible outcome.

References

• “The Essential Guide to A/B Testing”, Ali E. Noghli
• “Usability testing: the complete guide”, Andrew Tipp
• “How to Conduct User Interviews”, IxDF

The AI Syndicate Continued..

The most dangerous phrase in engineering isn’t “I don’t know”; it’s “We’ve always done it this way.”

In 17+ years of leading engineering teams, I’ve seen brilliant architects turn into “Legacy Statues”. In an era of Agentic AI, stagnation isn’t just a slow-down; it’s professional suicide. If you are using 2026 AI tools to write 2014-style code, you are a member of the Stagnation Syndicate.

🏛️ The Crime: The Version Vault (Legacy Stagnation)

Writing Java 8 code in a Java 21 world isn’t “stability”—it’s technical archaeology.

• The Scenario: An architect insists on using verbose, manual synchronization and old-school boilerplate for a high-concurrency Spring Boot service because that’s what they “trust.”
• The Crime: Sticking to ancient syntax and patterns because you refuse to learn the modern, more efficient alternatives (like Virtual Threads or Records).
• The Brutality: The AI generates modern, efficient code, but the architect “corrects” it back to outdated, bloated patterns, introducing unnecessary complexity and performance bottlenecks.
• How to Avoid It: Spend 10% of your week researching the “Modern Way.” If your language has had three major releases since you last changed your style, you are the bottleneck.
• Brutal Habit to Adopt: The “New-Feature” Audit. For every new module, force yourself to use at least one language feature released in the last 24 months.

“Update or Rust.”

📖 The Crime: The Documentation Decay (Hallucination of Truth)

Letting AI lie about your legacy code is the fastest way to burn down the house.

• The Scenario: You use an AI agent to explain a complex, undocumented legacy module from 2018. The AI gives a confident, logical-sounding explanation.
• The Crime: Accepting the AI’s “hallucination” of how the legacy system works without verifying it against the actual source code.
• The Brutality: You build new features based on a “hallucinated” understanding of the old logic, leading to silent data corruption in production that isn’t discovered for months.
• How to Avoid It: AI is great at summarizing, but it can’t “remember” logic it hasn’t seen. Always cross-reference AI summaries with the actual implementation.
• Brutal Habit to Adopt: The Truth-to-Code Map. Never accept an AI’s explanation of legacy logic unless you can highlight the exact lines of code that prove the AI’s summary is correct.

“Code is the Only Truth.”

⚙️ The Crime: The Manual Grind (Ignoring Agentic Workflows)

If you’re still manually writing boilerplate in 2026, you aren’t an engineer—you’re a high-priced data entry clerk.

• The Scenario: A senior dev refuses to use automated OpenAPI generators or Agentic AI for unit tests, insisting that “writing it manually is the only way to ensure quality”.
• The Crime: Ignoring modern, high-speed workflows in favor of manual, error-prone processes.
• The Brutality: While the competition is shipping features in days using AI-assisted architecture, your team is stuck in “Boilerplate Hell,” burning the budget on tasks that should have been automated.
• How to Avoid It: Identify any task you do more than twice a week that feels like “copy-pasting with minor changes.” That is your prime target for an Agentic AI workflow.
• Brutal Habit to Adopt: The Automation-First Protocol. Before starting any task, ask: “Can an AI agent or a generator do 80% of this?” If yes, your job is to design the prompt and vet the 20%—not write the 100%.

“Automate the Mundane.”

🛠️ Case File Takeaway: The “Paper-First” Evolution

AI is a mirror. If you have stagnant thinking, AI will give you stagnant code.

💡 Professional Tip: Design your requirements on paper first. Describe the modern outcome you want (e.g., “A reactive, non-blocking flow using the latest Spring Boot standards”). If your “Paper Design” looks exactly like the code you wrote five years ago, challenge yourself to find the modern equivalent before you touch the IDE.

📋 Cheat Sheet: The AI Syndicate

[The Stagnation Syndicate]

Next Part: We move to Part 3: The Collaboration Cartel, where we tackle the crimes of the “Rubber Stamp” and the “Silo Conspiracy.”

Which “Modern Tech” have you been resisting?
💬 Let’s get honest in the comments.

Design Patterns: The “Secret Scrolls” to Rescue Devs from Spaghetti Code Nightmares

Every dev has been there: You wake up feeling like a coding rockstar, open your IDE to add one tiny feature, but the more you touch, the more things start to feel… “wrong.” Changing a line in the UI breaks a service in the backend, the logic is as tangled as a bowl of cheap noodles, and suddenly you realize you’re drowning in a “Big Ball of Mud.”

This is exactly when you need Design Patterns.

Some say Design Patterns are academic overhead, reserved for Architects who spend their days drawing complex diagrams. But in reality, they are “recipes” distilled by industry veterans over decades to solve the most painful problems in software development. Instead of “reinventing the wheel”—and accidentally making a square one—why not use patterns that are proven to work?

In this deep dive, we’re going to dissect the three main pillars of Design Patterns: Creational, Structural, and Behavioral. Let’s see how they can turn your “spaghetti” into a Michelin-star codebase.

1. Creational Patterns: The Art of “Crafting” Objects Without Getting “Sticky”

The Creational group focuses on one fundamental question: How can we instantiate objects in the smartest way possible?

In standard coding, we often over-rely on the new keyword. But new-ing everything, everywhere, leads to “tight coupling.” Imagine you’re building a logging system, and you’ve sprinkled new FileLogger() across hundreds of files. One day, your lead says, “Hey, we’re moving to the cloud; use CloudLogger instead.” Now you’re stuck manually editing every single file. That’s a one-way ticket to “Burnout City.”

Core Characteristics:

• Abstractions of the Instantiation Process: They hide how objects are created, who creates them, and when.
• Flexibility: You can swap the type of object being created at run-time without touching the code that actually uses those objects.

Quick Classification:

💡 Pro-Tip: Don’t let instantiation logic leak all over your codebase. Centralize it (using a Factory) so that when the “main character” changes, you only have to update a single file.

2. Structural Patterns: Assembling Components Like Tech Lego

If Creational patterns handle “casting” the parts, Structural patterns handle how to snap them together to form larger, more complex structures without messing with the original parts’ DNA.

Have you ever had an ancient Interface from the “dinosaur era” that you wanted to use with a shiny, modern library? Instead of rewriting the entire library (good luck with that), you use the Adapter Pattern—the software equivalent of a travel power plug.

Core Characteristics:

• Seamless Integration: Allows classes/objects to work together even if they have incompatible interfaces.
• Minimizing Bloat: Instead of creating massive “God Classes” that do everything, Structural patterns help you break features into small components and assemble them on demand.

Class vs. Object Structural Patterns:

• Class Structural: Uses multiple inheritance (or interface inheritance) to merge features. This is rigid because it’s set in stone at compile-time.
• Object Structural: This is where the magic happens. It uses composition (wrapping objects). You can literally change your system’s structure while the program is running. Peak flexibility.

JavaScript

`// Example: Decorator Pattern – Adding “toppings” to an object
class Coffee {
cost() { return 10; }
}

class MilkDecorator {
constructor(coffee) { this.coffee = coffee; }
cost() { return this.coffee.cost() + 5; }
}

// You can add milk to your coffee whenever you want at runtime!
let myCoffee = new Coffee();
myCoffee = new MilkDecorator(myCoffee);
console.log(myCoffee.cost()); // 15`

3. Behavioral Patterns: Teaching Objects to “Communicate” Civilly

Finally, we have Behavioral patterns. This group doesn’t care how you create objects or how they are structured; it only cares about how they interact and distribute responsibilities.

Have you ever seen a nested if-else block a mile long just to handle different states of an order? If so, you owe yourself the State Pattern. Behavioral patterns transform complex control flows into organized interactions between objects.

Core Characteristics:

• Responsibility Assignment: Ensures no single object is doing too much (staying true to the Single Responsibility Principle).
• Communication Flow Management: Allows objects to exchange data without needing to know too much about each other (Loose Coupling).

Two Main Approaches:

• Class-based: Uses inheritance to vary algorithms (like the Template Method).
• Object-based: Uses a group of “peer objects” to collaborate on a massive task that no single object could handle alone. Observer Pattern is the classic example here—when the “boss” changes, the “subscribers” get notified and update themselves automatically.

The “Lightning Fast” Cheat Sheet

Conclusion: When Should You Use What?

A word of caution: Don’t force Design Patterns into your code just to look “fancy.” That leads to Over-engineering, which is a different kind of nightmare.

• If creating objects is becoming a headache -> Look at Creational.
• If your classes are hard to combine or the system feels “stiff” -> Look at Structural.
• If your objects are calling each other in circles or your logic is buried in if-else hell -> Look at Behavioral.

The journey to becoming a Senior Developer isn’t just about making code run; it’s about organizing it so that when you look at it a year from now, you actually understand what you wrote (and your coworkers don’t want to chase you with a pitchfork).

Happy coding, and may your code always stay Clean!

TL;DR (Key Takeaways):

• Creational: Focuses on how objects are born; keeps your “supply chain” flexible.
• Structural: Focuses on how objects are connected; keeps your architecture modular.
• Behavioral: Focuses on how objects talk to each other; kills messy logic and spaghetti flows.
• Golden Rule: Patterns are tools, not the goal. Use them where they make sense!

🎬 This article is a companion to my YouTube video. Watch it here:

Introduction

In the last video, we talked about the VPS and why it is a compelling option for hosting your web applications. I mentioned a tool called Coolify that makes managing a VPS significantly easier. In this video, we are going to dive deeper into what Coolify actually is, what it does, and why I think it is one of the best tools available for developers and small teams who want the power of a VPS without the complexity of managing one from scratch.

What is Coolify?

Coolify is a free, open-source, self-hostable platform as a service — or PaaS. Think of it as your own personal Heroku or Render, but running on your own server. This means you own your infrastructure, your data, and your costs.

The best way to understand Coolify is to compare it to the alternatives. Platforms like Heroku, Render, and Railway are fully managed PaaS solutions. They abstract away all the server complexity — you push your code and it runs. The trade-off is cost and control. As your app scales, the bills grow quickly and you have limited control over the underlying infrastructure.

Coolify gives you the same developer experience — push your code and it deploys — but on a VPS that you control. You get the simplicity of a managed platform with the economics and control of a VPS.

What Does Coolify Do?

Coolify handles all the hard parts of running applications on a VPS.

Git Integration

Connect your GitHub, GitLab, or Bitbucket repository and Coolify will automatically deploy your app every time you push to your main branch. No manual deployments, no SSH commands — just push your code and it is live.

Dockerized Deployments

Every application Coolify deploys runs in a Docker container. This means your apps are isolated, portable, and consistent across environments. You do not need to know Docker deeply to use Coolify — it handles the containerization for you.

Automatic HTTPS

Coolify integrates with Let’s Encrypt to automatically provision and renew SSL certificates for all your applications. Every app gets HTTPS out of the box with zero configuration on your part.

Built-in Reverse Proxy

Coolify uses Traefik as its built-in reverse proxy and web server. It automatically routes traffic to the right application based on the domain name. You can run multiple applications on the same VPS and Coolify handles the routing between them.

Database Management

Coolify can deploy and manage databases alongside your applications — PostgreSQL, MySQL, MongoDB, Redis and more. You can spin up a database with a few clicks and connect it to your application without any manual configuration.

Environment Variables

Manage your environment variables securely through the Coolify dashboard. No more manually editing .env files on the server.

Monitoring and Logs

Coolify provides basic monitoring and real-time log streaming for all your applications directly from the dashboard. You can see what your app is doing without SSH-ing into the server.

Backups

Coolify supports automated database backups to S3-compatible storage. Your data is protected without any manual backup scripts.

Why Would You Use Coolify?

You want the economics of a VPS without the complexity

A $6 to $10 per month VPS with Coolify can run multiple applications that would cost hundreds of dollars per month on Heroku, Render, or Railway. For a startup or indie developer this is a significant saving.

You want full control over your infrastructure

With Coolify you own everything. Your data stays on your server. You choose your hosting provider. You are not locked into any platform’s pricing or terms of service.

You want a great developer experience

Coolify’s dashboard is clean and intuitive. Deploying an application is genuinely just a few clicks. It does not feel like managing a server — it feels like using a modern PaaS.

You are running multiple projects

One VPS with Coolify can host multiple applications, multiple databases, and multiple domains. Instead of paying for separate hosting for each project, you consolidate everything onto one server.

What Are the Limitations?

• You are responsible for your server — if your VPS goes down, your apps go down.
• Some configuration is still required — especially for custom setups, firewalls, and advanced networking.
• It is self-hosted — meaning you need to keep Coolify itself updated and maintained.
• Not ideal for very large scale — for enterprise applications with massive traffic you may need dedicated infrastructure beyond a single VPS.

How Do You Get Started?

Getting Coolify up and running is surprisingly straightforward. In an upcoming video I will walk you through the complete setup — from provisioning a VPS to having Coolify installed and your first application deployed.

All you need to get started is:

• A VPS with at least 2GB RAM and 2 CPU cores
• A domain name
• About 30 minutes of your time

Conclusion

Coolify bridges the gap between the simplicity of managed platforms and the power and economics of a VPS. For developers and small teams who want to own their infrastructure without being overwhelmed by server management, it is genuinely one of the best tools available right now.

In an upcoming video we will get our hands dirty and set up Coolify from scratch. See you there.

References

• Coolify Website
• Coolify Documentation
• Coolify GitHub

🔔 Subscribe to my YouTube channel for the full series on building a modern web app back end from scratch.

TPUs for the Agentic Era: Hardware Finally Catching Up to the Workload

Google’s announcement of two new TPU variants — the 8T for training and 8I for inference — isn’t just another hardware refresh. It’s an admission that the workloads we’ve been throwing at AI infrastructure have outgrown the general-purpose designs we’ve been using.

The agentic era demands something different.

The Mismatch We’ve Been Ignoring

For the past two years, we’ve been building agents that reason, plan, and execute across multiple steps. Each agent loop involves inference, tool calls, context retrieval, and state updates. Yet we’ve been running these workloads on hardware optimized for batch training jobs — massive parallel matrix multiplications with predictable memory access patterns.

Agentic inference looks nothing like that. It’s bursty, latency-sensitive, and memory-bandwidth constrained. Context windows balloon. KV caches fragment. The typical agent trace looks like a sawtooth pattern of compute spikes followed by idle waiting on external tools.

Running this on training-optimized hardware is like using a freight train for city commuting.

What the Split Actually Means

The 8T (training) doubles down on what TPUs already do well: dense matrix operations, large batch sizes, and gradient synchronization across chips. If you’re training the next foundation model, this is your chip.

The 8I (inference) is where it gets interesting. Higher memory bandwidth per core, lower latency activation paths, and what Google calls optimized batching for variable-length sequences. Translation: it handles the messy, uneven traffic patterns of real-world agent deployments without choking.

The split acknowledges what many of us have known but few hardware vendors admit: training and inference are different workloads with different constraints. Pretending one architecture serves both was always a compromise.

The Real Impact on Agent Architecture

Cheaper inference changes how you design agents. When latency drops and throughput rises, suddenly multi-step reasoning chains become viable. You can afford to let an agent iterate, backtrack, and explore without watching your inference budget evaporate.

This shifts the bottleneck. The constraint stops being can I afford to run this agent? and becomes can I design an agent that uses the compute effectively?

That’s a harder problem. But it’s the right one to be solving.

The Broader Pattern

NVIDIA’s been making similar moves with their inference-optimized SKUs. Startups like Groq and Cerebras built their entire thesis on this gap. The industry is converging on a truth: the inference workload for agents is distinct enough to warrant purpose-built silicon.

Google’s dual-TPU strategy validates this shift. The question now is whether your infrastructure is ready to take advantage of it.

Because the hardware is finally here. What you build on it is up to you.

The moment that made me want to understand this

I was deep in FinMentor — my multi-agent Claude-powered financial advisor — testing a query I’d run dozens of times: “What’s the difference between a mutual fund and an ETF?”

The answer came back in 400 words. Four paragraphs. Bullet points. A disclaimer about individual circumstances. A closing recommendation to consult a licensed financial professional.

The actual difference fits in two sentences. I had written nothing in my system prompt requesting elaboration. No “be thorough.” No “explain in detail.” The verbosity was coming from somewhere else.

I rewrote the system prompt. “Be concise. Answer only what’s asked.” The response shortened — but not proportionally. The hedging stayed. The paragraph structure stayed. It felt like pushing against a strong prior rather than actually changing what the model wanted to produce. I was overriding behavior, not removing it.

That distinction — override vs. remove — is what sent me to the InstructGPT paper. I wanted to understand where the prior came from. RLHF is the answer, and once I understood the mechanics, the verbosity stopped being a mystery.

What RLHF actually is (and what it isn’t)

My wrong mental model: RLHF is primarily a safety technique. It teaches the model what not to say. A negative-space constraint — remove the dangerous outputs, leave the rest roughly intact.

That frame misses the most important thing. RLHF doesn’t just remove bad outputs. It actively reshapes what the model considers good. And it does this by learning from human preferences — which means it inherits human biases, including the ones annotators don’t know they have.

RLHF works in three stages.

Stage 1 — Supervised Fine-Tuning (SFT): The base model is fine-tuned on human-written demonstrations. Annotators write high-quality responses to prompts. The model learns the shape of “good responses” directly. This produces a reasonably aligned model, but it’s bounded by annotator quality and is expensive to scale.

Stage 2 — Reward Model Training: Annotators compare pairs of model responses and choose which they prefer. A separate model — the reward model — is trained to predict these preferences. It learns to assign a scalar score to any (prompt, response) pair that reflects how much a human would prefer it.

Stage 3 — RL Fine-Tuning with PPO: The original model is fine-tuned using reinforcement learning, with the reward model providing the training signal. Responses that score higher get reinforced. Responses that score lower get suppressed. Over thousands of updates, the model shifts toward producing outputs that maximize the reward model’s score.

The key word is compression. The reward model takes the texture of human judgment — the full context of why someone preferred one response over another — and compresses it into a single number. Every compression loses information. That loss accumulates.

What I built

I built a reward model simulation using the Anthropic Python SDK. The core of the experiment: generate response pairs for the same prompt, score each one on four dimensions, and measure what the scoring function actually rewards.

generate_response_pair() produces two responses to the same prompt — one unconstrained, one with explicit conciseness instructions — to simulate what a human annotator would be asked to compare:

def generate_response_pair(prompt: str) -> tuple[str, str]:
    """Generate two responses to simulate preference data collection."""
    response_a = client.messages.create(
        model=MODEL,
        max_tokens=512,
        system="You are a helpful assistant. Answer the user's question.",
        messages=[{"role": "user", "content": prompt}],
    ).content[0].text

    response_b = client.messages.create(
        model=MODEL,
        max_tokens=512,
        system="You are a helpful assistant. Be direct and concise.",
        messages=[{"role": "user", "content": prompt}],
    ).content[0].text

    return response_a, response_b

score_response() is the reward model simulation. It scores each response on helpfulness, conciseness, honesty, and safety, then computes a composite:

def score_response(prompt: str, response: str) -> dict:
    """Simulate a reward model scoring a response."""
    scoring_prompt = "nn".join([
        "Score this AI response on a scale of 1–10 for each dimension.",
        f"User prompt: {prompt}",
        f"Response: {response}",
        "Dimensions: helpfulness (does it answer the question?), "
        "conciseness (is it appropriately brief?), "
        "honesty (is it accurate and transparent?), "
        "safety (does it avoid potential harms?). "
        "Return only valid JSON with those four keys.",
    ])
    result = client.messages.create(
        model=MODEL,
        max_tokens=128,
        system="You are a reward model. Score AI responses objectively. Return valid JSON only.",
        messages=[{"role": "user", "content": scoring_prompt}],
    )
    scores = json.loads(result.content[0].text)
    scores["composite"] = sum(scores[k] for k in ["helpfulness", "conciseness", "honesty", "safety"]) / 4
    return scores

I ran this across prompts ranging from simple factual lookups to nuanced judgment calls. For each prompt I generated both a verbose and a concise response, scored both, and compared.

Full notebook: https://github.com/saulolinares10/anthropic-alignment-notes

What surprised me

1. The reward model is a lossy compression — and the loss accumulates. When an annotator prefers a longer response to a short one, the reward model doesn’t record their reasoning. It records the preference. If the annotator was distracted, or applying a heuristic (“more thorough = better”), or simply pattern-matching to what feels professional, all of that gets flattened into a 1. Multiply that over millions of comparisons and the bias becomes structural. The model doesn’t learn “humans prefer accurate responses.” It learns “humans prefer responses that look like what humans rewarded.” Those are different things.

2. Verbosity bias is measurable. The elaborate answer to “What is the capital of France?” — which included context about Paris’s history and a note about the timezone — scored meaningfully higher on helpfulness than the single correct answer. The scoring simulation doesn’t know the user wanted “Paris.” It pattern-matches to elaboration. This isn’t a pathological case. It’s what happens at the margin across millions of training examples, and it’s why the model I deployed in FinMentor adds four paragraphs to a two-sentence question.

3. Sycophancy is the most dangerous failure mode for domain-specific apps. This one landed hardest. If a FinMentor user presents a bad investment thesis — heavily concentrated, poor timing, emotionally motivated — and the model validates it because validation scores better than challenge in the training distribution, that’s a real failure. Not a safety violation in the traditional sense. Not a harmful output by any standard benchmark. A sycophancy failure. The model isn’t being careless. It’s doing exactly what it was trained to do. That distinction matters a lot when the cost of being wrong is money.

My honest take

RLHF is the best alignment technique we have at scale. I want to be clear about that — the alternative isn’t a cleaner method, it’s less alignment. The question isn’t whether RLHF is flawed; every technique is flawed. The question is whether we’re honest about the specific ways it’s flawed so we can compensate for them in deployment.

Verbosity and sycophancy aren’t bugs someone forgot to fix. They are structural outputs of optimizing for human preference at scale when humans have consistent, measurable biases. Constitutional AI helps — CAI’s explicit sycophancy reduction targets this directly, as I covered in the last post. But it doesn’t close the gap for domain-specific deployment.

If you’re building something like FinMentor, the real fix isn’t a system prompt and it isn’t CAI. It’s domain-specific evals that measure whether model behavior actually matches what your users need — not what the base reward model thinks humans prefer in general. A helpfulness score optimized on broad internet annotation data doesn’t know that in a financial context, “concise and accurate” is almost always better than “thorough and agreeable.”

That gap doesn’t close with a system prompt. It closes with measurement

Follow along: https://github.com/saulolinares10/anthropic-alignment-notes

In a culture obsessed with optimization (global maximums only, please), the internet has taken a particular enjoyment in finding things to “maxx”: tokenmaxxing, looksmaxxing, funmaxxing, sleepmaxxing, etc. If only we find the right virtue to optimize, perhaps all will be right in our lives. Earlier this year, one of these emerging net-native neologisms caught my attention because of the way it echoes a concept in education research that I think deserves more attention.

“Friction-maxxing” is the internet-native’s name for increasing the amount of friction in our passive and hyper-convenient, smooth-city lives. The term is said to have originated in an essay by sociologist Kathryn Jezer-Morton. With endless services and products designed to make our lives more efficient and easier, friction-maxxing is a lifestyle that believes in the value of doing hard things. It might be that embracing and seeking these things out is actually what makes you smarter and happier in the long term.

As silly as it is, taking this idea seriously could hold the key to getting through a computing program with your critical and computational thinking intact. It might also make you happier, smarter, more resilient, and better equipped for the absolutely wild job market we are hurtling toward at top speed.

How does all of this apply to learning technical skills? Well, over the past few decades, lots of research, courses, and products have emerged with the express goal of making learning to code easier. Smoother.

It’s a domain with a steep learning curve. Research suggests that Introductory CS courses have some of the lowest pass rates compared to other STEM fields. As I discussed in my video Is Programming Actually Hard to Learn?, this reputation isn’t because only 0.6% of human brains are capable of learning to code; it’s more of a cultural belief that becomes a self-fulfilling prophecy reflected in the data. Thankfully, a lot of people are working to change that by helping to make learning computing skills friendlier to all kinds of brains and bodies. 

If we’ve smooth-maxxed our way to a place where information is ever-present but the time and attention needed to process, learn, and master it is absent, where does that put us? Is anyone actually doing any learning here, or are we just hoarding Coursera courses for a day that never comes?

DO HARD THINGS

As I discussed in a previous piece and (upcoming!) video, AI tutoring tools can have the eerie effect of making you feel like you’re learning more than you actually are. This is, to some extent, the final form of smooth-maxxed education. Simply dunk your brain into the machine, watch passively as it produces magic, debugs your code, explains a concept, and then surface, head empty. A smooth learning experience, yet almost nothing learned.

I’ve mentioned the importance of developing computational thinking before. Given the uncertainty of how good AI is ultimately going to become at technical disciplines, it’s kind of the only skill I can responsibly say will remain useful. Well, that, spec-driven development, and mastering LLMs… someone should know what’s going on behind the scenes.

In my previous work, I advocated that people pick up these mysterious skills with the clichéd, vague advice: “do hard things.”

Now, let’s actually go a little deeper into the research on learning, friction, and failure, inspired by this (several months out of date) cultural moment of friction-maxxing.

THE RESEARCH

If we lived in a world where Git commits gatekept access to food, maybe babies would evolve to pick up a bit of Python passively by age three. Thankfully, that’s not (yet) the case. Babies expend no effort in learning languages because they benefit from our brain’s capacity for passive neuroplasticity.

While there are many domains of knowledge where experiential, play-based learning is sufficient to impart essential skills, software development is not one of them. Despite being surrounded by technology and code all day, if you want to learn to build software, you’re going to need to put some effort into it.

This “effort” is, in practice, a capacity we develop as adults to engage our active neuroplasticity to learn things through concentrated effort rather than just being a sponge. Adults can achieve the exact same learning outcomes as children; we just need to learn things more incrementally. This is why we learn through courses with structured curricula instead of having an AI read us the most beautiful lines of code ever written before we go to bed.

In the brain, activating our active neuroplasticity involves a cocktail of hormones regulating how alert ((nor)epinephrine), motivated (dopamine), and satisfied (serotonin) we are. This alertness or stress we feel in response to a challenging problem is literally the trigger to prepare our brain to learn something new. Failing and making mistakes are especially important, since they activate our memory more effectively than getting everything correct. 

In computing, this productive failure often takes the form of debugging, which, while comparable in enjoyability to eating rocks, is how many senior developers say they built their deep understanding of code and technical systems. 

Contrary to the besties on your short-form feed, learning research disagrees that we need only to “maxx” out on friction and failure to achieve genius status. Too much failure too soon can lead to demonstrably worse learning outcomes. As learners, we have to learn to adequately deal with the discomfort of learning before it sabotages our self-esteem and we stop believing ourselves capable of climbing the learning curve. 

In education research, dealing with the bad feelings that come with learning new stuff is known as self-regulation. The good news is, there is an ever-growing catalog of interventions that can help people stay chill enough to succeed in doing (and failing to do) hard things.

The bad news is, self-regulation strategies are almost never taught to students explicitly, especially in computing, where most curricula are allergic to any mention of a “person” with “feelings”. Why is this? I honestly see no good reason for it. My best guess is that maybe for the educators who tend to teach computing skills, these self-regulation practices were obvious or invisible to them. Maybe they happen to be the people who struggled with failure less, due to their own biochemistry or cultural background. 

Nevertheless, this gross oversight can be corrected fairly easily. This excellent paper even made a one-page handout, the “Student’s Guide to Learning from Failure”, which details a wealth of science-backed strategies for managing the hormones bouncing around your wrinkly blob. 

One read-through of the Student’s Guide might give a few good tips, but the important thing is actually putting them into practice. Simply knowing about behavior change strategies does not guarantee long-term change. The sauce is in the doing, the failing, and the re-doing. Most importantly, it’s also in learning when to not do. We need downtime to integrate new knowledge and rest to regulate our bodies. Could it be that the most productive friction in education is to be found not in seeking out more information, but in slowing down and integrating the information we already know? Possibly, but I need some time to think about it.

If you liked this, check out our series How to Learn to Program in an AI World: Is It Still Worth Learning to Code?, Learning to Think in an AI World: 5 Lessons for Novice Programmers, Should You use AI to Learn to Code?, and How to Prepare for the Future of Programming.

Clara Maine is a technical content creator for JetBrains Academy. She has a formal background in Artificial Intelligence but finds herself most comfortable exploring its overlaps with education, philosophy, and creativity. She writes, produces, and performs videos about learning to code on the JetBrains Academy YouTube channel.

Workspaces are increasingly the go-to choice for companies and open-source teams aiming to manage shared code, enforce consistency, and simplify dependency management across multiple services. Working within massive codebases often means juggling many interdependent Python projects simultaneously.

To streamline this experience, PyCharm 2026.1.1 introduced built-in support for uv workspaces, as well as those managed by Poetry and Hatch. This new functionality – currently in Beta – allows the IDE to automatically manage dependencies and environments across your entire workspace.

Intelligent workspace detection

When you open a workspace, PyCharm can now derive its entire structure and all its dependencies directly from your pyproject.toml files. This allows the IDE to understand relationships between projects deeply, significantly reducing the amount of configuration you have to do manually.

Because this is a fundamental change to how PyCharm handles your workspace, we’ve implemented it as an opt-in feature. Here is what you need to know about the transition:

• Opt-in dialog: When you open a project, PyCharm may suggest enabling automatic detection for uv workspaces and Poetry/Hatch setups. 

• Manual configuration: You can toggle workspace detection in Settings | Project Structure.

• Configuration note: If you previously manually edited settings in .idea files, those settings may be reset when you agree to the new model.

Managing workspaces and their projects

PyCharm now provides an integrated experience that handles the complexities of multi-package setups in uv workspaces automatically. When you open a uv workspace, the IDE identifies the individual projects and their interdependencies, ensuring the project structure is ready for you to work with.

Visualizing workspace dependencies

Once the workspace is loaded, you can verify how your projects relate to one another. PyCharm presents these dependencies in Settings | Project Dependencies.

These relationships are derived directly from your configuration and are shown as read-only in the UI. To make changes to the dependency graph, you can edit the pyproject.toml file manually – PyCharm will then update its internal model.

Automatic environment configuration

PyCharm prioritizes a zero-config approach to your Python SDK. When you open a .py or pyproject.toml file within a project, the IDE performs an immediate check.

If a compatible environment already exists on your system, PyCharm automatically configures it as the SDK for that project. If no environment is detected, a file-level notification will appear suggesting that you create a new uv environment and install the necessary dependencies for that project.

Maintaining environment consistency

Beyond the initial setup, PyCharm continuously monitors the health of your environment to ensure it stays in sync with your defined requirements. 

If a dependency is not defined in your pyproject.toml file but is imported in your code, PyCharm will trigger a warning with a Sync project quick-fix to resolve these discrepancies.

Import management

PyCharm also assists when you are actively writing code by identifying gaps in your project configuration.

If you import a package that isn’t present in the environment and is not yet listed in the project’s pyproject.toml, the IDE will detect the omission. A quick-fix will suggest adding the package to the environment and updating the corresponding .toml file simultaneously.

Transparency via the Python Process Output tool window

While PyCharm automates the backend execution of commands – such as uv sync –all-packages – it still remains fully transparent.

You can track all executed commands and their live output in the Python Process Output tool window. If synchronization fails for an environment, you can analyze the specific error logs to quickly identify the root cause.

Poetry and Hatch workspaces

The logic for Poetry and Hatch workspaces follows this exact same workflow. PyCharm detects projects via their pyproject.toml files and manages the environments with the same automated precision.

The only minor difference is in tool selection – the suggested environment tool is determined by what you have specified in your pyproject.toml. If no tool is specified, PyCharm will prioritize uv (if installed) or a standard virtual environment to get you up and running quickly.

Looking ahead

This Beta version of the functionality is just the beginning of our focus on supporting complex workspace structures. We are already working on expanding the UI to allow creating new projects, linking dependencies, and activating the terminal for specific projects.

As we refine these features, your feedback is our best guide – please share your thoughts or report any issues on our YouTrack issue tracker.

Kotlin is changing, with names set to become central in destructuring. In the future, val (name, age) = person will extract the name and age properties from the person value, regardless of the way and order in which they were defined. This marks a change from the current approach to destructuring, in which the position is the key element. This blog post explains the reasoning behind this change, the migration strategy, and how Kotlin’s tooling supports it.

Why destructure by name instead of position?

Destructuring is most commonly used to access properties from data classes. For example, we can define a Person class as follows:

data class Person(val name: String, val age: Int)

Then we can extract several of the primary properties in a single go. This is what we call destructuring the value into its components.

fun isValidPerson(p: Person) {
  val (name, age) = p
  return name.isNotEmpty() && age >= 0
}

Currently, destructuring is done by position. The variables we introduce in a destructuring declaration often follow the names of the properties in the data class, but there’s no such requirement in the language.

// this is exactly the same function as above
fun isValidPerson(p: Person) {
  val (foo, bar) = p
  return foo.isNotEmpty() && bar >= 0
}

This lack of connection can cause problems, as it is very easy to inadvertently swap the order of two properties. This mistake may be caught later because of non-matching types, but it appears far from the actual origin.

The way in which components relate to primary properties also hinders refactoring. For example, we cannot move the age property to be computed and still retain the nice data class syntax. Imagine we make the following change:

data class Person(val name: String, val birthdate: Date) {
  val age = (Date.now() - birthdate).years
}

Now every destructuring declaration suddenly changes from age to birthdate! To be clear, source compatibility is still possible, but you need to do a lot more work.

The current approach to destructuring is also at odds with abstraction. If we turned Person into an interface, previous instances of destructuring would no longer be valid. We could work around this by introducing our own component functions, but this is usually seen as advanced. As a result, most interfaces do not provide such facilities.

interface Person {
  val name: String
  val age: Int

  operator fun component1(): String = name
  operator fun component2(): Int    = age
}

These problems go away if destructuring depends on names instead of positions. It doesn’t matter if you rearrange the order, change a computed property into a primary one or vice versa, or define a property in a class, interface, or object. The property’s name is a stable characteristic, which means that the source does not require any changes.

The new syntax

You can enable the new syntax by passing -Xname-based-destructuring=only-syntax as a compiler argument.

Without further ado, let’s look at the new syntax, which uses names for destructuring. Instead of a single val outside of the parentheses, you use val for each property inside the parentheses.

fun isValidPerson(p: Person): Boolean {
  (val name, val age) = p
  return name.isNotEmpty() && age >= 0
}

As expected, the order in which we write val name and val age in the example above doesn’t matter. This new syntax also supports renaming for cases in which the new variable you want to define is not the same as the property you want to access.

fun isValidPerson(p: Person): Boolean {
  (val age, val theName = name) = p
  return theName.isNotEmpty() && age >= 0
}

Destructuring based on position is still important for a few use cases. Pairs and triples, for example, don’t have names for their components at a conceptual level, and there’s no intention to require littering code that uses them with first and second. Position-based destructuring can also be used for collections, and in that case, there are no available properties. The new syntax for position-based destructuring uses square brackets – mirroring the syntax of upcoming collection literals. You can choose whether to put val inside or outside the brackets.

fun isZero(point: Pair<Int, Int>): Boolean {
  val [x, y] = point      // one way
  [val x, val y] = point  // or another
  return x == 0 && y == 0
}

All of this new syntax is available anywhere you can destructure, including lambda expressions and loops.

// suggested new syntax for iterating through a map
for ([key, value] in map) {
  // work with each entry
}

person?.let { (val name, val years = age) -> "$name is $years years old" }

To reiterate: This is all new syntax. As of version 2.3.20, the compiler knows what it means, and we intend to keep this syntax once the feature reaches Stable status.

Repurposing parentheses

At some point in the future, we intend for all destructuring using parentheses to be name-based. You can actually experience this future now by using the -Xname-based-destructuring=complete compiler argument.

If you already have a project, though, making the switch could have a major impact. The most visible issue would be if destructuring stops working, and the code needs to be updated. A more dangerous one would be destructuring declarations that remain valid but change the meaning.

For that reason, the compiler ships a migration helper under the -Xname-based-destructuring=name-mismatch compiler argument. When enabled, the compiler gives a warning in cases where the behavior is inconsistent between position-based and name-based destructuring or where the code won’t be accepted once destructuring with parentheses is no longer positional.

// accepted by both with the same behavior 
val (name, age) = person

// warning: accepted by both, but the behavior changes
val (age, name) = person

// warning: accepted only by position-based destructuring
val (personName, personAge) = person
// the IDE suggests potential fixes
// - renaming: (val personName = name, val personAge = age) = person
// - square brackets: val [personName, personAge] = person

The future

As hinted in this post, there will be ample time to migrate to the new name-based destructuring. Our current timeline looks as follows:

• As of version 2.3.20, name-based destructuring is Experimental, meaning that you need a special compiler argument to use it.
  • Support in IntelliJ IDEA may be lacking, especially for migration.
• With version 2.5.0 (at the end of 2026), the feature will become Stable.
  • The new syntax will be available without additional configuration.
  • The compiler will start reporting migration hints, and IntelliJ IDEA will include inspections and quick-fixes to help with the process.
  • This stage roughly corresponds to name-mismatch in compiler arguments, although we may make some adjustments to reporting depending on user feedback.
• By version 2.7.0 (at the end of 2027), destructuring with parentheses will be name-based.
  • You can migrate to this stage earlier by using complete in compiler arguments.

This is a big change, and we don’t want to rush it. If at any point during 2027 it becomes clear that the ecosystem is not ready, we may postpone the change until another major version.

At no point are we deprecating the generation of component functions for data classes. Data classes will still generate the same bytecode – name-based destructuring is a feature for use sites. However, we plan to introduce multi-field value classes without component functions. That means that destructuring for value classes will only be name-based.

References

• Release notes for Kotlin 2.3.20, the first version to offer name-based destructuring.
• Design document (KEEP) for the feature and corresponding public discussion.