In the first part of this series, we established the fundamental shift from generative to agentic artificial intelligence. We explored why this leap from suggesting to acting demands a new psychological and methodological toolkit for UX researchers, product managers, and leaders. We defined a taxonomy of agentic behaviors, from suggesting to acting autonomously, outlined the essential research methods, defined the risks of agentic sludge, and established the accountability metrics required to navigate this new territory. We covered the what and the why.

Now, we move from the foundational to the functional. This article provides the how: the concrete design patterns, operational frameworks, and organizational practices essential for building agentic systems that are not only powerful but also transparent, controllable, and worthy of user trust. If our research is the diagnostic tool, these patterns are the treatment plan. They are the practical mechanisms through which we can give users a palpable sense of control, even as we grant AI unprecedented autonomy. The goal is to create an experience where autonomy feels like a privilege granted by the user, not a right seized by the system.

Core UX Patterns For Agentic Systems

Designing for agentic AI is designing for a relationship. This relationship, like any successful partnership, must be built on clear communication, mutual understanding, and established boundaries.

To manage the shift from suggestion to action, we utilize six patterns that follow the functional lifecycle of an agentic interaction:

• Pre-Action (Establishing Intent)
  The Intent Preview and Autonomy Dial ensure the user defines the plan and the agent’s boundaries before anything happens.
• In-Action (Providing Context)
  The Explainable Rationale and Confidence Signal maintain transparency while the agent works, showing the “why” and “how certain.”
• Post-Action (Safety and Recovery)
  The Action Audit & Undo and Escalation Pathway provide a safety net for errors or high-ambiguity moments.

Below, we will cover each pattern in detail, including recommendations for metrics for success. These targets are representative benchmarks based on industry standards; adjust them based on your specific domain risk.

1. The Intent Preview: Clarifying the What and How

This pattern is the conversational equivalent of saying, “Here’s what I’m about to do. Are you okay with that?” It’s the foundational moment of seeking consent in the user-agent relationship.

Before an agent takes any significant action, the user must have a clear, unambiguous understanding of what is about to happen. The Intent Preview, or Plan Summary, establishes informed consent. It is the conversational pause before action, transforming a black box of autonomous processes into a transparent, reviewable plan.

Psychological Underpinning
Presenting a plan before action reduces cognitive load and eliminates surprise, giving users a moment to verify the agent truly understands their intent.

Anatomy of an Effective Intent Preview:

• Clarity and Conciseness
  The preview must be immediately digestible. It should summarize the primary actions and outcomes in plain language, avoiding technical jargon. For instance, instead of “Executing API call to cancel_booking(id: 4A7B),” it should state, “Cancel flight AA123 to San Francisco.”
• Sequential Steps
  For multi-step operations, the preview should outline the key phases. This reveals the agent’s logic and allows users to spot potential issues in the proposed sequence.
• Clear User Actions
  The preview is a decision point, not just a notification. It must be accompanied by a clear set of choices. It’s a moment of intentional friction, a ‘speed bump’ in the process designed to ensure the user is making a conscious choice, particularly for irreversible or high-stakes actions.

Let’s revisit our travel assistant scenario from the first part of this series. We use this proactive assistant to illustrate how an agent handles a flight cancellation. The agent has detected a flight cancellation and has formulated a recovery plan.

The Intent Preview would look something like this:

Proposed Plan for Your Trip Disruption

I’ve detected that your 10:05 AM flight has been canceled. Here’s what I plan to do:

1. Cancel Flight UA456
   Process refund and confirm cancellation details.
2. Rebook on Flight DL789
   Book a confirmed seat on a 2:30 PM non-stop flight, as this is the next available non-stop flight with a confirmed seat.
3. Update Hotel Reservation
   Notify the Marriott that you will be arriving late.
4. Email Updated Itinerary
   Send the new flight and hotel details to you and your assistant, Jane Doe.

[ Proceed with this Plan ] [ Edit Plan ] [ Handle it Myself ]

This preview is effective because it provides a complete picture, from cancellation to communication, and offers three distinct paths forward: full consent (Proceed), a desire for modification (Edit Plan), or a full override (Handle it Myself). This multifaceted control is the bedrock of trust.

When to Prioritize This Pattern
This pattern is non-negotiable for any action that is irreversible (e.g., deleting user data), involves a financial transaction of any amount, shares information with other people or systems, or makes a significant change that a user cannot easily undo.

Risk of Omission
Without this, users feel ambushed by the agent’s actions and will disable the feature to regain control.

Metrics for Success:

• Acceptance Ratio
  Plans Accepted Without Edit / Total Plans Displayed. Target > 85%.
• Override Frequency
  Total Handle it Myself Clicks / Total Plans Displayed. A rate > 10% triggers a model review.
• Recall Accuracy
  Percentage of test participants who can correctly list the plan’s steps 10 seconds after the preview is hidden.

Applying This to High-Stakes Domains

While travel plans are a relatable baseline, this pattern becomes indispensable in complex, high-stakes environments where an error results in more than an inconvenience for an individual traveling. Many of us work in settings where wrong decisions may result in a system outage, putting a patient’s safety at risk, or numerous other catastrophic outcomes that unreliable technology would introduce.

Consider a DevOps Release Agent tasked with managing cloud infrastructure. In this context, the Intent Preview acts as a safety barrier against accidental downtime.

In this interface, the specific terminology (Drain Traffic, Rollback) replaces generalities, and the actions are binary and impactful. The user authorizes a major operational shift based on the agent’s logic, rather than approving a suggestion.

2. The Autonomy Dial: Calibrating Trust With Progressive Authorization

Every healthy relationship has boundaries. The Autonomy Dial is how the user establishes it with their agent, defining what they are comfortable with the agent handling on its own.

Trust is not a binary switch; it’s a spectrum. A user might trust an agent to handle low-stakes tasks autonomously but demand full confirmation for high-stakes decisions. The Autonomy Dial, a form of progressive authorization, allows users to set their preferred level of agent independence, making them active participants in defining the relationship.

Psychological Underpinning
Allowing users to tune the agent’s autonomy grants them a locus of control, letting them match the system’s behavior to their personal risk tolerance.

Implementation
This can be implemented as a simple, clear setting within the application, ideally on a per-task-type basis. Using the taxonomy from our first article, the settings could be:

• Observe & Suggest
  I want to be notified of opportunities or issues, but the agent will never propose a plan.
• Plan & Propose
  The agent can create plans, but I must review every one before any action is taken.
• Act with Confirmation
  For familiar tasks, the agent can prepare actions, and I will give a final go/no-go confirmation.
• Act Autonomously
  For pre-approved tasks (e.g., disputing charges under $50), the agent can act independently and notify me after the fact.

An email assistant, for example, could have a separate autonomy dial for scheduling meetings versus sending emails on the user’s behalf. This granularity is key, as it reflects the nuanced reality of a user’s trust.

When to Prioritize This Pattern
Prioritize this in systems where tasks vary widely in risk and personal preference (e.g., financial management tools, communication platforms). It is essential for onboarding, allowing users to start with low autonomy and increase it as their confidence grows.

Risk of Omission
Without this, users who experience a single failure will abandon the agent completely rather than simply dialing back its permissions.

Metrics for Success:

• Trust Density
  Percentage breakdown of users per setting (e.g., 20% Suggest, 50% Confirm, 30% Auto).
• Setting Churn
  Number of Setting Changes / Total Active Users per month. High churn indicates trust volatility.

3. The Explainable Rationale: Answering Why?

After taking an action, a good partner explains their reasoning. This pattern is the open communication that follows an action, answering Why? before it’s even asked. “I did that because you’ve told me in the past that you prefer X.”

When an agent acts, especially autonomously, the immediate question in the user’s mind is often, Why did it do that? The Explainable Rationale pattern proactively answers this question, providing a concise justification for the agent’s decisions. This is not a technical log file. In my first article of this series, we discussed translating system primitives into user-facing language to prevent deception. This pattern is the practical application of that principle. It transforms the raw logic into a human-readable explanation grounded in the user’s own stated preferences and prior inputs.

Psychological Underpinning
When an agent’s actions are explainable, they feel logical rather than random, helping the user build an accurate mental model of how the agent thinks.

Effective Rationales:

• Grounded in Precedent
  The best explanations link back to a rule, preference, or prior action.
• Simple and Direct
  Avoid complex conditional logic. Use a simple “Because you said X, I did Y” structure.

Returning to the travel example, after the flight is rebooked autonomously, the user might see this in their notification feed:

I’ve rebooked your canceled flight.

• New Flight: Delta 789, departing at 2:30 PM.
• Why I took this action:
  • Your original flight was canceled by the airline.
  • You’ve pre-approved autonomous rebooking for same-day, non-stop flights.

[ View New Itinerary ] [ Undo this Action ]

The rationale is clear, defensible, and reinforces the idea that the agent is operating within the boundaries the user established.

When to Prioritize This Pattern
Prioritize it for any autonomous action where the reasoning isn’t immediately obvious from the context, especially for actions that happen in the background or are triggered by an external event (like the flight cancellation example).

Risk of Omission
Without this, users interpret valid autonomous actions as random behavior or ‘bugs,’ preventing them from forming a correct mental model.

Metrics for Success:

• Why? Ticket Volume
  Number of support tickets tagged “Agent Behavior — Unclear” per 1,000 active users.
• Rationale Validation
  Percentage of users who rate the explanation as ‘Helpful’ in post-interaction microsurveys.

4. The Confidence Signal

This pattern is about the agent being self-aware in the relationship. By communicating its own confidence, it helps the user decide when to trust its judgment and when to apply more scrutiny.

To help users calibrate their own trust, the agent should surface its own confidence in its plans and actions. This makes the agent’s internal state more legible and helps the user decide when to scrutinize a decision more closely.

Psychological Underpinning
Surfacing uncertainty helps prevent automation bias, encouraging users to scrutinize low-confidence plans rather than blindly accepting them.

Implementation:

• Confidence Score
  A simple percentage (e.g., Confidence: 95%) can be a quick, scannable indicator.
• Scope Declaration
  A clear statement of the agent’s area of expertise (e.g., Scope: Travel bookings only) helps manage user expectations and prevents them from asking the agent to perform tasks it’s not designed for.
• Visual Cues
  A green checkmark can denote high confidence, while a yellow question mark can indicate uncertainty, prompting the user to review more carefully.

When to Prioritize This Pattern
Prioritize when the agent’s performance can vary significantly based on the quality of input data or the ambiguity of the task. It is especially valuable in expert systems (e.g., medical aids, code assistants) where a human must critically evaluate the AI’s output.

Risk of Omission
Without this, users will fall victim to automation bias, blindly accepting low-confidence hallucinations, or anxiously double-check high-confidence work.

Metrics for Success:

• Calibration Score
  Pearson correlation between Model Confidence Score and User Acceptance Rate. Target > 0.8.
• Scrutiny Delta
  Difference between the average review time of low-confidence plans and high-confidence plans. Expected to be positive (e.g., +12 seconds).

5. The Action Audit & Undo: The Ultimate Safety Net

Trust requires knowing you can recover from a mistake. The Undo function is the ultimate relationship safety net, assuring the user that even if the agent misunderstands, the consequences are not catastrophic.

The single most powerful mechanism for building user confidence is the ability to easily reverse an agent’s action. A persistent, easy-to-read Action Audit log, with a prominent Undo button for every possible action, is the ultimate safety net. It dramatically lowers the perceived risk of granting autonomy.

Psychological Underpinning
Knowing that a mistake can be easily undone creates psychological safety, encouraging users to delegate tasks without fear of irreversible consequences.

Design Best Practices:

• Timeline View
  A chronological log of all agent-initiated actions is the most intuitive format.
• Clear Status Indicators
  Show whether an action was successful, is in progress, or has been undone.
• Time-Limited Undos
  For actions that become irreversible after a certain point (e.g., a non-refundable booking), the UI must clearly communicate this time window (e.g., Undo available for 15 minutes). This transparency about the system’s limitations is just as important as the undo capability itself. Being honest about when an action becomes permanent builds trust.

When to Prioritize This Pattern
This is a foundational pattern that should be implemented in nearly all agentic systems. It is absolutely non-negotiable when introducing autonomous features or when the cost of an error (financial, social, or data-related) is high.

Risk of Omission
Without this, one error permanently destroys trust, as users realize they have no safety net.

Metrics for Success:

• Reversion Rate
  Undone Actions / Total Actions Performed. If the Reversion Rate > 5% for a specific task, disable automation for that task.
• Safety Net Conversion
  Percentage of users who upgrade to Act Autonomously within 7 days of successfully using Undo.

6. The Escalation Pathway: Handling Uncertainty Gracefully

A smart partner knows when to ask for help instead of guessing. This pattern allows the agent to handle ambiguity gracefully by escalating to the user, demonstrating a humility that builds, rather than erodes, trust.

Even the most advanced agent will encounter situations where it is uncertain about the user’s intent or the best course of action. How it handles this uncertainty is a defining moment. A well-designed agent doesn’t guess; it escalates.

Psychological Underpinning
When an agent acknowledges its limits rather than guessing, it builds trust by respecting the user’s authority in ambiguous situations.

Escalation Patterns Include:

• Requesting Clarification
  “You mentioned ‘next Tuesday.’ Do you mean September 30th or October 7th?”
• Presenting Options
  “I found three flights that match your criteria. Which one looks best to you?”
• Requesting Human Intervention
  For high-stakes or highly ambiguous tasks, the agent should have a clear pathway to loop in a human expert or support agent. The prompt might be: “This transaction seems unusual, and I’m not confident about how to proceed. Would you like me to flag this for a human agent to review?”

When to Prioritize This Pattern
Prioritize in domains where user intent can be ambiguous or highly context-dependent (e.g., natural language interactions, complex data queries). Use this whenever the agent operates with incomplete information or when multiple correct paths exist.

Risk of Omission
Without this, the agent will eventually make a confident, catastrophic guess that alienates the user.

Metrics for Success:

• Escalation Frequency
  Agent Requests for Help / Total Tasks. Healthy range: 5-15%.
• Recovery Success Rate
  Tasks Completed Post-Escalation / Total Escalations. Target > 90%.

Table 1: Summary of Agentic AI UX patterns. Remember to adjust the metrics based on your specific domain risk and needs.

Designing for Repair and Redress

This is learning how to apologize effectively. A good apology acknowledges the mistake, fixes the damage, and promises to learn from it.

Errors are not a possibility; they are an inevitability.

The long-term success of an agentic system depends less on its ability to be perfect and more on its ability to recover gracefully when it fails. A robust framework for repair and redress is a core feature, not an afterthought.

Empathic Apologies and Clear Remediation

When an agent makes a mistake, the error message is the apology. It must be designed with psychological precision. This moment is a critical opportunity to demonstrate accountability. From a service design perspective, this is where companies can use the service recovery paradox: the phenomenon where a customer who experiences a service failure, followed by a successful and empathetic recovery, can actually become more loyal than a customer who never experienced a failure at all. A well-handled mistake can be a more powerful trust-building event than a long history of flawless execution.

The key is treating the error as a relationship rupture that needs to be mended. This involves:

• Acknowledge the Error
  The message should state clearly and simply that a mistake was made.
  Example: I incorrectly transferred funds.
• State the Immediate Correction
  Immediately follow up with the remedial action.
  Example: I have reversed the action, and the funds have been returned to your account.
• Provide a Path for Further Help
  Always offer a clear link to human support. This de-escalates frustration and shows that there is a system of accountability beyond the agent itself.

A well-designed repair UI might look like this:

We made a mistake on your recent transfer.
I apologize. I transferred $250 to the wrong account.

✔ Corrective Action: The transfer has been reversed, and your $250 has been refunded.
✔ Next Steps: The incident has been flagged for internal review to prevent it from happening again.

Need further help? [ Contact Support ]

Building the Governance Engine for Safe Innovation

The design patterns described above are the user-facing controls, but they cannot function effectively without a robust internal support structure. This is not about creating bureaucratic hurdles; it is about building a strategic advantage. An organization with a mature governance framework can ship more ambitious agentic features with greater speed and confidence, knowing that the necessary guardrails are in place to mitigate brand risk. This governance engine turns safety from a checklist into a competitive asset.

This engine should function as a formal governance body, an Agentic AI Ethics Council, comprising a cross-functional alliance of UX, Product, and Engineering, with vital support from Legal, Compliance, and Support. In smaller organizations, these ‘Council’ roles often collapse into a single triad of Product, Engineering, and Design leads.

A Checklist for Governance

• Legal/Compliance
  This team is the first line of defense, ensuring the agent’s potential actions stay within regulatory and legal boundaries. They help define the hard no-go zones for autonomous action.
• Product
  The product manager is the steward of the agent’s purpose. They define and monitor its operational boundaries through a formal autonomy policy that documents what the agent is and is not allowed to do. They own the Agent Risk Register.
• UX Research
  This team is the voice of the user’s trust and anxiety. They are responsible for a recurring process for running trust calibration studies, simulated misbehavior tests, and qualitative interviews to understand the user’s evolving mental model of the agent.
• Engineering
  This team builds the technical underpinnings of trust. They must architect the system for robust logging, one-click undo functionality, and the hooks needed to generate clear, explainable rationales.
• Support
  These teams are on the front lines of failure. They must be trained and equipped to handle incidents caused by agent errors, and they must have a direct feedback loop to the Ethics Council to report on real-world failure patterns.

This governance structure should maintain a set of living documents, including an Agent Risk Register that proactively identifies potential failure modes, Action Audit Logs that are regularly reviewed, and the formal Autonomy Policy Documentation.

Where to Start: A Phased Approach for Product Leaders

For product managers and executives, integrating agentic AI can feel like a monumental task. The key is to approach it not as a single launch, but as a phased journey of building both technical capability and user trust in parallel. This roadmap allows your organization to learn and adapt, ensuring each step is built on a solid foundation.

Phase 1: Foundational Safety (Suggest & Propose)

The initial goal is to build the bedrock of trust without taking significant autonomous risks. In this phase, the agent’s power is limited to analysis and suggestion.

• Implement a rock-solid Intent Preview: This is your core interaction model. Get users comfortable with the idea of the agent formulating plans, while keeping the user in full control of execution.
• Build the Action Audit & Undo infrastructure: Even if the agent isn’t acting autonomously yet, build the technical scaffolding for logging and reversal. This prepares your system for the future and builds user confidence that a safety net exists.

Phase 2: Calibrated Autonomy (Act with Confirmation)

Once users are comfortable with the agent’s proposals, you can begin to introduce low-risk autonomy. This phase is about teaching users how the agent thinks and letting them set their own pace.

• Introduce the Autonomy Dial with limited settings: Start by allowing users to grant the agent the power to Act with Confirmation.
• Deploy the Explainable Rationale: For every action the agent prepares, provide a clear explanation. This demystifies the agent’s logic and reinforces that it is operating based on the user’s own preferences.

Phase 3: Proactive Delegation (Act Autonomously)

This is the final step, taken only after you have clear data from the previous phases demonstrating that users trust the system.

• Enable Act Autonomously for specific, pre-approved tasks: Use the data from Phase 2 (e.g., high Proceed rates, low Undo rates) to identify the first set of low-risk tasks that can be fully automated.
• Monitor and Iterate: The launch of autonomous features is not the end, but the beginning of a continuous cycle of monitoring performance, gathering user feedback, and refining the agent’s scope and behavior based on real-world data.

Design As The Ultimate Safety Lever

The emergence of agentic AI represents a new frontier in human-computer interaction. It promises a future where technology can proactively reduce our burdens and streamline our lives. But this power comes with profound responsibility.

Autonomy is an output of a technical system, but trustworthiness is an output of a design process. Our challenge is to ensure that the user experience is not a casualty of technical capability but its primary beneficiary.

As UX professionals, product managers, and leaders, our role is to act as the stewards of that trust. By implementing clear design patterns for control and consent, designing thoughtful pathways for repair, and building robust governance frameworks, we create the essential safety levers that make agentic AI viable. We are not just designing interfaces; we are architecting relationships. The future of AI’s utility and acceptance rests on our ability to design these complex systems with wisdom, foresight, and a deep-seated respect for the user’s ultimate authority.

If you’ve ever handled GST reporting for a growing business, you already know the pattern.

Data exists.
Reports exist.
Returns are filed.

And yet — reconciliation issues keep appearing.

Mismatch between GSTR-1 and sales.
ITC differences in GSTR-2B.
Late discovery of supplier defaults.
Refunds stuck without visibility.

The problem is rarely the tax law.

The problem is workflow design.

The Real Issue: Fragmented Review Systems

In many businesses, GST workflows look like this:

Sales team generates invoices.

Accounts team prepares returns.

Data is exported from accounting software.

GSTR-2B is downloaded separately.

Refund tracking happens via email follow-ups.

Notices are checked manually on the portal.

Each step works independently.

But no system connects them in real time.

That’s where friction begins.

What Actually Breaks in Traditional GST Processes

1. No Real-Time Comparison

Most teams compare GSTR-3B vs GSTR-2B at the last minute.

By then:

Corrections are rushed

ITC adjustments are reactive

Risk increases

1. Refund Visibility Is Weak

Once a refund is filed:

Status tracking becomes manual

Communication gaps appear

Working capital planning suffers

1. Notices Are Discovered Late

If notice monitoring isn’t centralized, it depends on:

Someone checking the portal regularly

Email alerts not being missed

That’s not a reliable system.

Where a CFO Dashboard Changes the Process

A GST-focused CFO Dashboard doesn’t replace accounting software.

It layers structured oversight on top of it.

Here’s what that means in practical terms:

✔ Sales Overview Connected to GSTR-1

You can visually compare invoice data with filed returns.

✔ Purchase Data Aligned with GSTR-2B

ITC eligibility becomes visible before filing pressure begins.

✔ GST Calculation Monitoring

Cash vs credit utilization can be reviewed early.

✔ Centralized Notice Tracking

All compliance alerts in one interface.

✔ Refund Status Visibility

Filed → Processing → Approved → Credited
Everything traceable.

The Bigger Shift: From Filing to Monitoring

Most teams operate in “return filing mode.”

A dashboard-based system shifts the mindset to:

Monitoring → Reviewing → Acting early

Instead of:
Preparing → Filing → Fixing later

That small change improves both compliance quality and decision speed.

Technical Perspective: Why Centralization Works

From a systems standpoint, the issue is data separation.

When:

Invoice data

Purchase data

GST return summaries

Refund workflows

Compliance alerts

Are isolated across tools, cross-verification becomes manual.

A centralized CFO Dashboard creates:

Single-source visual review

Early mismatch detection

Structured KPI monitoring

Reduced dependency on memory or manual tracking

It’s not about automation hype.

It’s about visibility architecture.

Final Thoughts

GST compliance in India isn’t simple.

But complexity becomes manageable when visibility improves.

A structured CFO Dashboard doesn’t eliminate responsibility.
It reduces fragmentation.

And in compliance-heavy environments, structured visibility often makes the biggest difference.

Kubernetes is powerful – but with great power comes great “who deployed this to prod?”

That’s where Admission Controllers come in.

They act like policy enforcement gates inside the Kubernetes API server. Before anything gets stored in the cluster, admission controllers can validate it, modify it, or completely reject it.

Let’s break it down properly.

What Are Admission Controllers?

An Admission Controller is code that intercepts requests to the Kubernetes API server after authentication and authorization, but before the object is persisted in etcd.

In simpler terms:

They’re middleware for the Kubernetes API.

If you run:

kubectl apply -f deployment.yaml

The request flow looks like this:

Request → Authentication → Authorization → Mutating Admission → Schema Validation → Validating Admission → etcd

Admission controllers sit right in the middle of this pipeline.

Two Main Types of Admission Controllers

Mutating Admission Controllers

These can modify incoming requests before they are stored.

Common examples:

• Adding default labels
• Injecting sidecar containers (for example with Istio)
• Adding default resource limits
• Overriding missing fields

Mutating controllers run first.

They take your original object and are allowed to change it.

Validating Admission Controllers

These cannot modify the request.

They only decide:

• Allow ✅
• Reject ❌

Examples:

• Blocking privileged containers
• Enforcing image registry policies
• Validating required labels
• Enforcing naming standards

Validating controllers run after mutation, meaning they see the final version of the object.

That ordering is important.

Static vs Dynamic Admission Controllers

Admission controllers come in two forms.

Static (Built-in)

These ship with Kubernetes and are enabled via the API server flag:

--enable-admission-plugins

Common examples:

• NamespaceLifecycle
• LimitRanger
• ResourceQuota
• ServiceAccount

For example, NamespaceLifecycle prevents you from creating new resources in a namespace that is being terminated.

Many features people assume are “core Kubernetes behavior” are actually implemented using these built-in admission controllers.

Dynamic (Webhook-Based)

These are far more flexible.

They include:

• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

Instead of embedding logic directly in the API server, Kubernetes calls an external HTTPS service (a webhook) and asks:

“Is this request okay?”
“Do you want to change anything?”

This means you can implement custom logic in:

• Go
• Python
• Node
• Any language capable of serving HTTPS

This is where things get powerful.

Why Admission Controllers Matter

In real-world clusters, most use cases fall into two categories: security and governance.

Security

Admission controllers can enforce a security baseline across your cluster.

Examples:

• Block containers running as root
• Allow images only from trusted registries
• Enforce read-only root filesystems
• Prevent hostPath usage

For example, you can reject any deployment that includes:

securityContext:
  privileged: true

That alone can prevent some serious security risks.

Governance & Compliance

They also help enforce organizational standards:

• Naming conventions
• Required labels
• Resource limits
• Replica restrictions

For example, you can enforce that every deployment must include:

labels:
  environment: production

No label? No deploy.

Simple. Effective.

Real-World Example: Ingress Controllers

When installing an ingress controller like F5 NGINX Ingress Controller, you’ll notice it creates:

• MutatingWebhookConfiguration
• ValidatingWebhookConfiguration

Why?

Because Kubernetes doesn’t understand NGINX-specific configuration logic.

The webhook:

• Validates ingress annotations
• Prevents invalid configurations
• Stops broken NGINX reloads
• Protects production traffic

Without this layer, a bad Ingress definition could generate an invalid NGINX config and impact live traffic.

That webhook is your safety net.

How Mutating and Validating Work Together

Let’s say you create a Deployment like this:

replicas: 1

Here’s what might happen:

1. A mutating webhook changes replicas to 3
2. A validating webhook checks that replicas are not greater than 5
3. If valid → the object is stored in etcd

This layered approach ensures:

• Defaults are applied
• Policies are enforced
• Broken configurations never reach the cluster state

Enabling Admission Controllers

On the API server, you enable them using:

--enable-admission-plugins=MutatingAdmissionWebhook,ValidatingAdmissionWebhook

To verify webhook support:

kubectl api-versions | grep admissionregistration.k8s.io

If you see:

admissionregistration.k8s.io/v1

You’re good to go.

Writing Your Own Admission Controller

If you want to build one yourself, here’s the high-level flow:

1. Build an HTTPS service
2. Accept AdmissionReview objects
3. Return:

• allowed: true/false

• Optional JSON patch (for mutation)

  1. Register it using:

• MutatingWebhookConfiguration

• or ValidatingWebhookConfiguration

Your webhook must:

• Use TLS
• Be reachable inside the cluster
• Include a CA bundle in its configuration

Once configured, Kubernetes will call your service every time matching resources are created, updated, or deleted.

Final Thoughts

Admission Controllers are one of the most powerful – and often overlooked – features in Kubernetes.

They give you a programmable control layer inside the API server.

If you’re running Kubernetes in production and not leveraging admission controllers, you’re relying entirely on developers to “do the right thing.”

And we all know how that usually goes

Use them wisely – and your cluster becomes significantly safer and more predictable.

If you build products for a living, you have felt the last year’s shift. Teams can generate apps in hours using AI assistants, prompt-to-UI builders, and other ai software development tools. The surprise is not that prototypes are faster. It’s that the gap between a convincing demo and a reliable system is getting wider.

That gap is where most startups burn time. You can ship a front end fast, but you still have to answer investor and customer questions about auth, data integrity, background processing, auditability, and what happens when a launch spike hits. AppGen is absolutely real. The risk is believing prompts replace platforms.

The pattern we see in practice is simple. App generation compresses the “build” phase, but it does not eliminate the “operate” phase. If you want to develop software that survives production traffic, you need a sane operating model that prevents unmanaged sprawl while keeping iteration speed.

Low-Code Compressed UI And Workflows. AppGen Compresses Everything

Low-code’s big win was letting more people ship internal apps and workflows without waiting on a full engineering cycle. It reduced hand-coding for common UI patterns, CRUD screens, and automations. It also quietly created a new job for engineering leaders. Deciding what was safe to build outside the main product codebase, and how to keep it governable.

AppGen takes that same direction and turns the dial up. Instead of assembling prebuilt components, you can often generate a working application skeleton, adapt it through iteration, and even get drafts of tests and documentation. That changes the day-to-day of product teams because the bottleneck moves.

When creation is cheap, coordination becomes expensive. You spend less time writing the first version and more time answering questions like:

• Where does user identity live, and what is the source of truth?
• Who owns data access rules when five generated apps all touch the same dataset?
• How do you prevent “zombie deployments” that keep running, consuming resources, and exposing risk?

Those are not theoretical. They are the same failure modes we saw with shadow IT, RPA sprawl, and untracked API integrations. The tools changed. The operational problem did not.

How AppGen Changes The Way You Develop Software

AppGen is best understood as an acceleration layer over application development. It can draft a working app, propose database tables or collections, scaffold endpoints, and create workflow logic from patterns. That makes it a powerful ai development platform capability, even when the tool is packaged as a “prompt experience.”

The key detail is what AppGen is actually optimizing. It is optimizing initial assembly and iteration. That is why it feels magical on day one.

Production success is optimized by different forces. Reliability under load, least-privilege access, predictable cost curves, safe deployments, and observability are not “first draft” problems. They show up once you have real users, real data, and real consequences.

A practical way to frame AppGen is:

• AppGen helps you get to a useful slice of product faster.
• Engineering judgment and platform choices determine whether that slice can be shipped, secured, and operated.

If you are a startup CTO or technical co-founder, this is the moment to set guardrails. Not to slow people down, but to keep the speed from turning into rework.

Vibe-Coding Is Fast. Unmanaged Sprawl Is Faster

Tools that generate code locally or in a lightweight hosted environment are great for momentum. They are also where teams accidentally recreate the problems AppGen claims to solve.

The common failure pattern looks like this. A generated app ships with a pile of credentials, unclear permission boundaries, and a backend that is “good enough” until it is not. Then the team starts bolting on essentials one by one. Auth this week. File storage next week. Rate limits after the first scrape. Background jobs after the first time a webhook retries for hours.

Each bolt-on is reasonable in isolation. Collectively, it turns into operational debt.

Two external references are worth keeping in mind as you evaluate the risk:

First, the OWASP Top 10 is a blunt reminder that many production incidents are not exotic. They are access control mistakes, injection issues, insecure design, and security misconfiguration. Generated code can include these issues just as easily as hand-written code, especially when you iterate quickly.

Second, shadow IT is not just an enterprise buzzword. The UK NCSC guidance on shadow IT describes the core problem plainly. Untracked services create blind spots in asset management and security, which becomes painful when you need incident response or compliance answers.

AppGen does not automatically fix these. It can actually amplify them if you treat every generated artifact as shippable production.

The Platform Move: Let AppGen Create. Let A Backend Platform Operate

The teams that keep their speed without drowning in sprawl usually separate two concerns.

They use AppGen and other application development tools to generate UIs, flows, and even bits of server logic quickly. Then they standardize the backend runtime on a platform that can handle the boring but critical parts. Identity, data access, file storage, background work, realtime, push notifications, environments, and monitoring.

This is where “backend app development” becomes less about writing endpoints and more about choosing a stable operating surface area.

If you want a concrete shortcut, we built SashiDo – Backend for Modern Builders for exactly this split. You generate and iterate where speed matters. Then you connect to a managed backend that gives you a MongoDB database with CRUD APIs, authentication, storage, realtime, jobs, and functions without standing up DevOps.

That does not mean you stop coding. It means the code you do write is aimed at product differentiation, not rebuilding commodity plumbing.

Where AppGen Is Strong Today (And Where It Still Breaks)

App generation is strongest when the problem is pattern-based.

It excels at producing a first version of an admin panel, a CRUD workflow, a simple onboarding funnel, or an internal tool that needs to exist by Friday. It also helps engineers move faster when the goal is to explore multiple approaches quickly.

It breaks when you need deep context and accountability. “Context” here is not just business logic. It includes your organization’s constraints, your data classification, regulatory obligations, and your acceptable risk profile.

A useful test is to ask what happens after the app is “done.”

If the answer includes any of these, you are in platform territory:

• You need fine-grained access control with predictable defaults.
• You need to store files safely and serve them globally.
• You need scheduled or recurring jobs that do not silently fail.
• You need realtime sync where clients share state.
• You need push notifications at scale.
• You need cost predictability as usage grows.

That is also why “prompts replace platforms” is the wrong mental model. Prompts can assemble. Platforms make the result operable.

The Production Checklist Most Teams Discover Too Late

When teams move from prototype to product, the missing pieces tend to cluster. You can use this as a readiness checklist before you cross a few hundred active users, or before you sign a contract that implies uptime expectations.

Identity And Access Control

You want one consistent identity system, a clear token story, and predictable rules for who can read and write what. If you are bolting auth on after the fact, you usually end up with inconsistent permission logic across endpoints.

In our world, every app includes a complete user management system with social login providers ready to enable. If you want to see how this maps to the Parse ecosystem, our developer docs are the fastest way to align SDK behavior with your access rules.

Data Model And CRUD Boundaries

AppGen will propose schemas quickly. The hard part is deciding what must be stable, what can evolve, and how you prevent “schema drift” across generated apps. MongoDB makes iteration easy, but you still want explicit ownership of collections and write paths. MongoDB’s own CRUD documentation is a good baseline for thinking about safe read and write patterns.

Background Work And Scheduling

Retries, webhooks, recurring tasks, and long-running jobs are where production systems quietly fail. If you do not standardize job visibility and alerting, you find out about failures from customers.

We run scheduled and recurring jobs with MongoDB and Agenda, and you can manage them through our dashboard. Agenda’s official documentation is worth reading even if you never touch it directly, because it clarifies the failure modes you need to plan for.

Storage And Delivery

Most generated apps treat file uploads as an afterthought. Production systems cannot. You need permissioned uploads, predictable URLs, and fast delivery. We use an AWS S3 object store with built-in CDN. If you care about how that impacts performance, our write-up on MicroCDN for SashiDo Files explains the architecture choices.

Realtime And Push

Realtime features and push notifications are often “version two” items in prototypes. In production, they are the retention engine. If you add them late, you also add late-stage risk.

We send 50M+ push notifications daily, and we have seen the scaling pitfalls. Our engineering notes on sending millions of push notifications are helpful if you want to understand the operational edge cases.

Uptime, Deployments, And Self-Healing

The moment you have external customers, downtime becomes a product feature. If your generated app runtime cannot do zero-downtime deploys or self-heal common failures, your team becomes the pager.

If you want a practical tour of what “high availability” means at the component level, read our guide on enabling high availability. It is written for builders who want fewer surprises, not for people shopping for buzzwords.

Why Governance Matters Without Returning To Central IT Gatekeeping

The usual objection is that governance slows teams down. That is only true when governance is implemented as approvals and paperwork.

Modern governance is closer to platform engineering. Provide a default backend surface. Make secure paths the easiest paths. Instrument everything. Then allow people to create quickly without turning every app into a bespoke operational snowflake.

This is also where AI risk thinking is useful. The NIST AI Risk Management Framework is not a developer tutorial, but it reinforces a point that matters for AppGen. You still need humans accountable for risk decisions, even when AI accelerates implementation.

If you want your team to move fast, give them strong defaults. That is more effective than telling people to “be careful” with generated code.

What To Measure So Speed Does Not Become Fragility

If AppGen is your accelerator, your dashboard needs to keep up.

Most teams already track feature throughput. The metrics that drift during AppGen adoption are operational. Time to restore service, change failure rate, deployment frequency, and lead time for changes. Those are not vanity metrics. They tell you whether your new speed is sustainable.

The DORA 2024 Accelerate State of DevOps Report is useful here because it highlights how teams evolve delivery practices as tooling changes, including the emerging impact of AI. The takeaway is not to chase a benchmark. It is to notice when your delivery system starts producing incidents instead of features.

Cost And Lock-In: The Real Objection Behind Most Platform Debates

When a CTO says, “I’m worried about lock-in,” it often hides two separate concerns.

The first is portability. Can you move your data and logic if the business needs change. The second is cost. Will pricing surprise you the moment your product finds traction.

AppGen does not remove either concern. In fact, a pile of generated apps can be less portable if each one bakes in its own backend assumptions.

A managed backend can be a practical compromise if it is built on portable primitives, and if the cost model is transparent. We built SashiDo on Parse and MongoDB, which is a familiar stack for many teams that want flexibility.

On pricing, the only responsible way to discuss numbers is to point you to the canonical source because backend pricing changes over time. Our current plans, included quotas, and overage rates are listed on our pricing page. If you are modeling runway, treat that page as the source of truth and sanity-check your request volume, storage growth, and data transfer.

If you are comparing platform directions, it also helps to compare the operational surface area, not just the database. For example, if you are evaluating a Postgres-first stack but you want a Parse-style backend with integrated auth, push, storage, and jobs, our comparison on SashiDo vs Supabase is a useful starting point.

Getting Started: From Generated Prototype To Production In A Week

The easiest mistake is waiting too long to introduce the “real” backend. Teams often try to keep the generated backend until they hit a scaling wall, then migrate under pressure.

A calmer approach is to introduce the production backend when any of these become true: you have more than a few hundred weekly active users, you start integrating payments or sensitive data, you need scheduled jobs, or you want to ship push notifications without building infrastructure.

Here is a straightforward migration path that keeps momentum while reducing risk:

• Start by standardizing identity. Decide where users live and how tokens are issued, then align your generated app flows to that.
• Move your core domain data to one backend. Keep a single source of truth for collections, access control, and indexes.
• Add background jobs early. Even simple products need retries, cleanup tasks, and scheduled workflows.
• Attach storage and CDN. Treat files as first-class product data, not a sidecar.
• Decide on realtime and push boundaries. Make sure the backend is capable before you promise the experience.
• Add scale knobs before the spike. If you need to scale compute, plan it as a parameter, not a rewrite.

If you are doing this on SashiDo, our two-part getting started series is designed for exactly this journey. Begin with SashiDo’s Getting Started Guide and continue with Getting Started Guide Part 2 once you are ready to layer in richer features.

When you reach the point where performance or concurrency becomes the bottleneck, scale should not require a new architecture. That is why we introduced Engines. Our post on the Engine feature explains when you need it and how the cost is calculated.

Key Takeaways For Teams Adopting AppGen

• AppGen accelerates creation, but it does not eliminate security, compliance, or operability work.
• Unmanaged generation creates sprawl. The fix is a platform default, not more approvals.
• Standardize the backend early if you need auth, jobs, storage, realtime, or push. These are hard to bolt on late.
• Measure delivery health, not just feature throughput, so your new speed does not increase incidents.

Frequently Asked Questions

How Do You Develop Software?

Developing software in an AppGen world starts with tightening the loop between idea and validation, then hardening what works. Use AI to draft UI and flows, but standardize identity, data ownership, and deployment practices early. Treat security and operability as product requirements, not a later refactor.

What Is A Synonym For Developed Software?

In practice, teams use phrases like production-ready software, shipped application, or deployed system. The important nuance is that developed software implies more than written code. It includes the supporting backend services, configurations, monitoring, and the ability to operate safely under real users and real failure modes.

When Should I Move A Generated App To A Managed Backend?

Move when the app becomes business-critical, or when you cross thresholds that create operational risk. Typical triggers are a few hundred weekly active users, storing sensitive data, adding scheduled jobs, or shipping push notifications. Migrating before the spike is cheaper than migrating during an incident.

What Usually Breaks First In Prompt-Generated Apps?

Access control and background work tend to fail first because they are easy to gloss over in a prototype. You also see fragile environment handling, missing observability, and ad-hoc storage decisions. These issues compound because each new feature adds more integrations and more places for secrets and permissions to leak.

Conclusion: AppGen Raises The Floor. Platforms Still Decide The Ceiling

AppGen is not a fad. It is the next compression step in how teams develop software, and it will keep making the first version cheaper. The teams that win will not be the ones who generate the most apps. They will be the ones who can turn the right generated apps into secure, observable, and scalable products without pausing innovation.

If you are iterating fast and want a backend you can standardize on early, SashiDo – Backend for Modern Builders is designed for that reality. You can deploy a MongoDB-backed API, auth, storage with CDN, realtime, functions, jobs, and push notifications in minutes, then scale without building a DevOps team.

A helpful next step is to explore SashiDo’s platform at SashiDo – Backend for Modern Builders and map your generated app’s needs to a production-ready backend surface before you hit your next growth spike.

Sources And Further Reading

• OWASP Top 10 (2021)
• NIST AI Risk Management Framework 1.0
• DORA 2024 Accelerate State of DevOps Report
• UK NCSC Guidance: Shadow IT
• MongoDB Manual: CRUD Operations

Related Articles

• AI App Builder vs Vibe Coding: Will SaaS End-or Just Get Rewired?
• Why CTOs Don’t Let AI Agents Run the Backend (Yet)
• AI that writes code is now a system problem, not a tool
• Why Vibe Coding is a Vital Literacy Skill for Developers
• Jump on the Vibe Coding Bandwagon: A Guide for Non-Technical Founders

I’m thinking about recording some tutorial videos with my commentary explaining how to use the aps and tools i made bloom and bunnybox and maybe some other stuff, but my natural voice is really triggering for me because its so deep and loud. Would it be unethical if I lightly altered my voice (pitch/formant) so I can actually make content without dysphoria shutting me down? I’m not trying to deceive anyone — just trying to make this doable for myself.

Based on findings from the JetBrains Developer Ecosystem Survey Report 2025, The State of Rust 2025 offers a detailed look at how the Rust ecosystem is evolving – how developers use Rust today, which tools they use, how much they rely on AI tools in their workflows, and where the language is gaining momentum.

With Rust continuing to attract a strong wave of new developers and expanding into new areas of application, the report provides a clear snapshot of a language that is maturing quickly while still inspiring curiosity, experimentation, and long-term professional adoption.

Is Rust still popular in 2025?

Yes, Rust remains both popular and in demand in 2025. The survey shows that developers continue to adopt Rust across learning, hobby, and professional contexts, indicating sustained interest rather than short-term experimentation.

Note: The survey provides statistically meaningful insights into Rust adoption, developer experience levels, and usage patterns across different types of projects.

65% of respondents say they use Rust for side or hobby projects, while 52% report that they are currently learning the language. At the same time, 26% of developers already use Rust in professional projects. This mix highlights a healthy adoption pattern in which experimentation and learning coexist with real-world usage.

Newcomers continue to fuel Rust’s popularity

Rust’s momentum is reinforced by a steady influx of new users. In 2025, 30% of respondents reported that they started using Rust less than a month ago. This is a significant increase compared to previous years and a clear sign that interest in Rust is not slowing down.

At the other end of the spectrum, the share of developers who have been using Rust for 3 years or more continues to grow, showing that Rust not only attracts newcomers but also retains long-term users.

“My teaching experience this year has been a lot of groups moving to Rust from existing C and C++ projects, particularly in the government and government-adjacent sector. They are generally having a pretty positive experience, and the language has evolved sufficiently that the learning curve doesn’t feel vertical anymore to these users.”

Herbert Wolverson
Author of Hands-on Rust book and consultant at Ardan Labs

Why does Rust remain popular? 

Developers continue to choose Rust for its performance, memory safety, and reliability. As tooling, documentation, and learning resources improve, Rust becomes easier to adopt without losing its core strengths.

Together, these factors explain why Rust remains popular. Developers are not just talking about Rust – they are learning it, experimenting with it, and increasingly using it in real projects.

Who uses Rust today?

To understand the changing demographics in the Rust ecosystem, it helps to look beyond raw numbers and focus on who these developers are. The Rust community in 2025 combines a large number of newcomers with a strong base of experienced developers, making for a unique and balanced ecosystem.

Most Rust users are experienced developers

The majority of Rust users already had programming experience before they started learning it. This means Rust adoption is largely driven by developers who have worked with other languages and systems and are making a conscious choice to explore Rust. These are not beginners picking a first language, but professionals and hobbyists looking for better tools.

Developers come to Rust from many ecosystems

Many developers who adopt Rust arrive from widely used languages such as Python, Java, TypeScript, C++, and JavaScript. This diversity helps explain why Rust appears in so many different contexts. Web developers, backend engineers, and systems programmers all bring their own expectations and use cases, pushing the ecosystem to grow in multiple directions at once.

This mix of experience and backgrounds helps Rust mature faster. Newcomers benefit from an ecosystem shaped by real-world demands, while experienced developers help validate Rust as a serious option for long-term projects.

“All roads lead to Rust!
Furthermore, Rust is increasingly a brownfield language: it shows up alongside the languages people already know, not instead of them.
Python developers reach for Rust (via PyO3/maturin) to speed up hot paths without rewriting their entire codebase. Ruby and Elixir shops do the same via native extensions. Meanwhile, C and C++ teams use Rust to incrementally harden their systems: new modules in Rust, old ones migrated over time, the two coexisting at the FFI boundary for months or years.
”

Luca Palmieri
Author of 100 Exercises to Learn Rust and Principal Engineering Consultant at Mainmatter

Why newcomers choose Rust

While many Rust users are experienced programmers, a large share are still new to Rust itself. This steady flow of newcomers is one of the most important forces shaping the ecosystem.

Many developers begin exploring Rust with clear motivations: They want performance without sacrificing safety, or stronger guarantees than they’ve experienced in other languages. Rust’s focus on memory safety, correctness, and predictability aligns well with these goals.

To help developers navigate Rust’s learning curve, JetBrains provides several educational resources designed to support different learning styles and experience levels.

• How to Learn Rust: Vitaly Bragilevsky’s guide lays out a practical approach to learning Rust, explaining the language’s core concepts, common beginner challenges, and how tools like RustRover can support the learning process. It offers clear strategies, recommended resources, and a realistic path for newcomers to build confidence with Rust.
• Learn Rust plugin: This guided learning plugin teaches Rust fundamentals through interactive lessons, editor hints, and instant feedback. It works in both RustRover and CLion, so developers can learn inside the IDE while writing real code.
• 100 Exercises to Learn Rust: Based on 100 Exercises to Learn Rust by Mainmatter’s Luca Palmieri, this course offers a hands-on, test-driven path through Rust, starting with your first println! and progressing to advanced concepts like ownership, lifetimes, pattern matching, and generics.

These resources make it easier for you to move from curiosity to confidence. They help explain not just how Rust works, but why it works the way it does, which is key to mastering the language.

The Rust Ecosystem Today: Tools, Workflows, and Maturity

A language’s success with newcomers depends not only on syntax or features, but on how well developers can work with it day to day. These workflows reduce friction, making Rust easier to pick up and Rust projects easier to maintain over time. In 2025, Rust’s ecosystem shows clear signs of maturity.

Tooling plays a central role in this progress. Cargo provides a consistent foundation for building, testing, and managing dependencies, while formatting and linting tools help teams maintain quality and consistency. These workflows reduce friction and make Rust projects easier to maintain over time.

What developers build with Rust in 2025

Rust’s use cases offer a clear view of where the ecosystem stands today. Let’s look at what developers are actually building with it.

Systems programming and command-line tools continue to sit at the heart of Rust’s identity. These domains reflect the problems Rust was originally designed to solve, and they still attract developers who need performance, control, and safety.

At the same time, Rust’s role has broadened significantly. Web and backend development are now common use cases, showing that Rust is increasingly trusted for building services and APIs. This shift matters because backend systems are often long-lived and business-critical, so choosing Rust here signals confidence in its stability and ecosystem support.

Beyond its core areas, Rust is used in networking, embedded systems, security, scientific computing, and early AI-related tooling. While some of these domains are still smaller, their presence shows that developers are willing to apply Rust to a wide range of challenges. The ecosystem no longer fits a narrow definition, and that flexibility supports long-term growth.

Rust rarely lives alone in real projects

Rust is most often used alongside other programming languages rather than in isolation. JavaScript and TypeScript lead this list, followed by Python, SQL, and shell scripting languages. This reflects how Rust is commonly integrated into existing stacks, powering performance-critical components while working alongside higher-level languages.

The presence of languages like C, C++, Java, and Go further highlights Rust’s role in mixed environments, especially in systems, backend, and infrastructure projects. At the same time, more than one-third of respondents report using Rust on its own, showing that the language is also mature enough to support complete projects end to end.

“Rust is often described as a true all-purpose language that successfully covers a wide range of tasks. The data confirms this, as the top entries among complementary languages ​​are JavaScript/TypeScript and Python. JavaScript/TypeScript holds an exclusive position in the world’s largest runtime, the browser, and this is difficult to challenge. Python, on the other hand, is indispensable in many sectors due to its accessibility and incredibly rich ecosystem. And well, I think SQL falls into this category as well. However, when you consider all the other languages, there’s no reason not to switch to Rust, except perhaps to keep legacy projects alive. I’m curious how this will change in the future. My prediction is that the bars at the bottom of this chart will become much smaller over the years.”

Stefan Baumgartner
Author of TypeScript Cookbook (O’Reilly) – oida.dev

Rust targets production platforms first

Rust projects overwhelmingly target production environments. Linux is by far the most common platform, used by three-quarters of respondents, reflecting Rust’s strong presence in server, cloud, and infrastructure workloads. Windows and macOS also see substantial usage, confirming Rust’s role in cross-platform development. This focus on production and infrastructure aligns with broader industry adoption trends discussed in the LWN analysis of Rust’s role in modern systems software.

Beyond traditional operating systems, Rust continues to expand into specialized environments. WebAssembly and embedded targets are used by a meaningful share of developers, while mobile platforms appear less frequently. These results show that Rust is primarily chosen for reliability and performance in production systems, with growing interest in newer deployment models.

AI adoption in the Rust developer workflow

Artificial intelligence has become a visible part of everyday development work, and Rust developers are no exception. The 2025 survey shows a community that is actively experimenting with AI tools while remaining thoughtful about how these technologies fit into long-term workflows.

How Rust developers feel about AI

Rust developers approach AI with a mix of optimism and caution. One-third of respondents describe themselves as hopeful about AI’s increasing role in society, while others express uncertainty or anxiety. This balance reflects a community that values progress but also cares deeply about correctness, safety, and long-term impact.

Rather than reacting emotionally, many Rust developers appear to be evaluating AI through a practical lens. They are interested in productivity gains, yet remain aware of the limitations and risks. This mindset aligns closely with Rust’s broader culture of deliberate design and explicit trade-offs.

AI tools are already part of everyday development

AI tools became a familiar part of Rust development in 2025. According to the survey, 89% of respondents have tried at least one AI tool, and 78% are actively using AI-powered coding assistants. ChatGPT and GitHub Copilot lead in regular usage, while dedicated AI editors and JetBrains AI Assistant are also widely explored.

Usage patterns show diversity rather than dominance by a single tool. Developers combine general-purpose AI assistants with IDE-integrated solutions, choosing what fits their workflow rather than committing to one approach. This flexibility suggests that AI is becoming another tool in the toolbox, not a replacement for developer judgment.

Regular usage and interest in AI coding agents

AI tools are clearly embedded in day-to-day work. About one-third of Rust developers regularly use ChatGPT, with GitHub Copilot close behind. IDE-integrated assistants are also gaining traction, reflecting a preference for AI support that fits naturally into existing development environments.

Here are the AI coding assistants, agents, and code editors most commonly used for Rust development in 2025:

Looking ahead, interest in AI coding agents is strong but measured. Around one-quarter of respondents say they are very likely to try coding agents in the next year, while others remain unsure or cautious. This split highlights a familiar Rust pattern: curiosity paired with a desire for control, transparency, and reliability.

Overall, the data suggests that Rust developers are not resisting AI, but rather integrating it carefully. They adopt tools that provide real value today, while remaining selective about more autonomous systems. This thoughtful adoption mirrors how the Rust ecosystem itself has evolved – steadily, intentionally, and with a focus on long-term quality.

“Newer models are growing more capable of working in large, complex codebases. Rust’s built-in documentation, expressive type system, and readable compiler errors provide agents the context they need to work effectively. Whether using them for code review, complex refactors, expanding test coverage, or exploring new features, I am excited to see how experimenting with these new tools can help us all ship more robust and resilient software.”

Ben Brandt
Software Engineer at Zed

What 2025 tells us about Rust’s future

Data from the JetBrains Developer Ecosystem Report 2025 points to a strong and stable future for Rust. A growing community of newcomers ensures continued interest, while experienced developers bring production-grade use cases that deepen trust in the language. Expanding adoption across backend services, infrastructure, embedded systems, and emerging AI tooling suggests that Rust’s role will continue to broaden.

Improvements in tooling and workflows further support long-term adoption. As Rust becomes easier to learn and more comfortable to use at scale, it is well-positioned to remain relevant as industry needs evolve. Rust’s trajectory reflects steady growth built on reliability and thoughtful design, rather than short-term trends.

A huge thank you to the Rust experts who contributed their expertise, helping us turn these numbers into a much more meaningful story!

The PyCharm team loves being part of the global Python community. From PyCon US to EuroPython to every PyCon in between, we enjoy the atmosphere at conferences, as well as meeting people who are as passionate about Python as we are. This includes everyone: professional Python developers, data scientists, Python hobbyists and students.

However, we know that being able to attend a Python conference in person is not something that everyone can do, either because they don’t have a local conference, or cannot travel to one. So within the PyCharm team we started thinking: what if we could bring the five-star experience of Python conferences to everyone? What if everyone could have the experience of learning from professional speakers, accessing great networking opportunities, hearing from various voices from across the community, and – most importantly – having fun, no matter where they are in the world?

Python is for Everyone – Announcing Python Unplugged on PyTV!

After almost a year of planning, we’re proud to announce we’ll be hosting the first ever PyTV – a free online conference for everyone!

Join us on March 4th 2026, for an unforgettable, non-stop event, streamed from our studio in Amsterdam. We’ll be joined live by 15 well-known and beloved speakers from Python communities around the globe, including Carol Willing, Deb Nicholson, Sheena O’Connell, Paul Everitt, Marlene Mhangami, and Carlton Gibson. They’ll be speaking about topics such as core Python, AI, community, web development and data science. 

You can get involved in the fun as well! Throughout the livestream, you can join our chat on Discord, where you can interact with other participants and our speakers. We’ve also prepared games and quizzes, with fabulous prizes up for grabs! You might even be able to get your hands on some of the super cool conference swag that we designed specifically for this event.

What are you waiting for? Sign up here. 

If you are local to Amsterdam, you can also sign up for the PyLadies Amsterdam meetup. It will be held on the same day as the conference, and will give you a chance to meet some of the PyTV speakers in person.

AI models and coding assistants have become essential tools for developers. Today, developers rely on large language models (LLMs) to accelerate coding, improve code quality, and reduce repetitive work across the entire development lifecycle. From intelligent code completion to refactoring, debugging, and documentation, AI-powered tools are now embedded directly into daily workflows.

Drawing on insights from the latest JetBrains Developer Ecosystem Report 2025, this guide compares the top large language models (LLMs) used for programming. It focuses on how leading LLMs balance accuracy, speed, security, cost, and IDE integration, helping developers and teams choose the right model for their specific needs.

Throughout the article, we also highlight how tools like JetBrains AI Assistant bring these models directly into professional development environments, backed by real-world usage data from the report.

Please note that the models listed in the article reflect those available during the research period, and may not reflect the most recent versions.

Table of contents

• What are AI models for coding?
• How developers choose between AI models
• Top AI models in 2025
• Evaluation criteria for AI coding assistants
• Open-source vs. proprietary models
• Enterprise readiness and security
• How to select the right AI coding model for you
• FAQ
• Conclusion

What are AI models for coding?

AI models for coding are large language models (LLMs) trained on vast collections of source code, technical documentation, and natural language text. Their purpose is to understand programming intent and generate relevant, context-aware responses that assist developers during software creation. Unlike traditional static tools, these models can reason about code structure, explain logic, and adapt to different programming languages and frameworks.

The best LLMs for programming support a wide range of everyday development tasks, most typically being used for code completion, refactoring, debugging, documentation writing, and test creation. By delegating such repetitive or boilerplate-related tasks to an LLM, developers can turn their attention to more complex problem-solving and system design tasks.

Most developers interact with AI coding tools through IDE integrations, browser tools, or APIs. This is where IDE-based assistants, such as JetBrains AI Assistant, are particularly valuable, as they operate directly within the development context, using project structure, files, and language semantics to improve accuracy and relevance.

The use of AI coding tools is influenced by several critical factors, including accuracy, latency, cost efficiency, and data privacy. According to the JetBrains Developer Ecosystem Report 2025, AI adoption was increasingly widespread, with up to 85% of developers regularly using AI tools for coding and development in 2025.

As AI capabilities expand, developers face an important challenge: selecting those AI models that best fit their workflow. The next section discusses how developers can evaluate the various options and make the best decision for their needs.

How developers choose between AI models

Developers’ adoption of AI coding tools in 2025 was driven by how well an AI model integrated into real-world workflows and delivered consistent output. This often goes beyond technical specs alone and involves various practical and trust-based factors. 

The top concern identified in the JetBrains Developer Ecosystem Report 2025 was code quality. IDE integration was another major priority. AI tools for developers that work seamlessly inside familiar environments, such as JetBrains IDEs, are far more likely to be adopted than standalone interfaces. Pricing and licensing also mattered for developers, especially for individual developers and small teams who need predictable or affordable access.

For professional teams, data privacy and security increasingly shape decision-making around AI model selection. The ability to control how prompts and code are processed, whether models can be deployed locally, and how data is retained or logged are all critical considerations. Customization options, including fine-tuning and contextual prompts, are also becoming more relevant as teams seek domain-specific optimization.

Overall, insights from the report indicated a clear divide. Individual developer AI preferences prioritized usability, responsiveness, and cost efficiency. But for organizations, the principal focus areas were compliance, governance, and long-term scalability.

Key selection factors for AI coding assistants

This table summarizes the core criteria developers use for quick comparison.

With these criteria in mind, the next section explores the top AI models developers used in 2025 and how they compare in practice.

Top AI models used in 2025

The JetBrains Developer Ecosystem Report 2025 showed that developers did not rely on a single LLM. Instead, they used a small set of the best AI models for coding, depending on accuracy needs, workflow integration, cost constraints, and data-handling requirements.

Based on developer survey data, the report identified the following AI models in 2025 as the most commonly used and trusted for coding tasks. It forms the basis of an AI coding assistants comparison guide that is grounded in real-world adoption rather than theoretical benchmarks:

GPT models (OpenAI): Models like GPT-5 and GPT-5.1 were widely used and recognized as some of the best LLMs for programming in day-to-day development, particularly for code generation, refactoring, and explanation tasks. These models were incorporated in daily workflows due to their consistent output quality and large context windows. Their trade-off is cost, especially for teams with heavy usage.

Claude models (Anthropic): Claude 3.7 Sonnet was commonly chosen by developers working with large files, monorepos, or documentation-heavy projects. It was frequently cited among top AI code assistants for its ability to reason over long inputs and maintain structure in explanations and generated code. However, compared to GPT-based tools, it offered fewer native integrations.

Gemini (Google): Gemini 2.5 Pro appeared most often in workflows tied to Google’s ecosystem. Developers reported using it for tasks that combine coding with documentation, search, or collaborative environments. While it performed well in speed and accessibility, it was less flexible for teams that require deep customization or private deployments when evaluating AI models in 2025.

DeepSeek: DeepSeek R1 gained attention among developers seeking lower-cost AI coding assistance or local deployment options. It was increasingly included in AI coding assistant comparisons for teams experimenting with AI at scale while maintaining tighter control over data and infrastructure.

Open-source models: These models, such as Qwen and StarCoder, represented another category of best LLMs for programming for a smaller but growing segment of developers. They are most popular among teams with strong DevOps capabilities or strict data-governance requirements. While they offer maximum control, they also require significant operational effort.

Overall, differences in reasoning accuracy, speed, context length, and IDE integration significantly influenced developer preferences when selecting among the best AI models for coding. For instance, some developers prioritized performance and reasoning depth with GPT-4o or Claude 3.7. Others chose more cost-efficient or private alternatives, such as DeepSeek and open-source models, depending on workflow and organizational constraints.

Capabilities of leading AI models for coding

Pricing and total cost of ownership (TCO) comparison

The next section builds on this by presenting a clear framework for objectively evaluating these models.

Evaluation criteria for AI coding assistants

Selecting an AI coding assistant requires balancing multiple factors rather than optimizing for a single metric, a reality reflected in any meaningful comparison of AI coding assistants. Accuracy, speed, cost, integration, and security all play a role, and their relative importance depends on whether the tool is used for personal productivity, enterprise compliance, or research and experimentation when identifying the best AI for software development.

Developers surveyed in the JetBrains Developer Ecosystem Report 2025 consistently cited code accuracy and IDE integration as top priorities when evaluating LLMs. However, organizational users also emphasized governance, transparency, and scalability as part of a broader AI model assessment.

Core evaluation criteria for AI coding assistants

These criteria underscore a fundamental choice developers must make between open-source and proprietary AI models, discussed in the next section.

Open-source vs. proprietary models

AI coding assistants generally fall into two categories: open-source or locally deployed models and commercial, cloud-managed models. A choice between them affects everything from data handling to performance and maintenance.

The JetBrains Developer Ecosystem Report 2025 showed that most developers rely on cloud-based proprietary AI coding tools, but a growing segment preferred local or private deployments due to security and compliance requirements. This group increasingly turned to local LLMs for coding and leveraged open-source models.

General industry patterns, specifically when it comes to a comparison of AI platforms, suggest there are different reasons behind this choice. Teams that choose open-source AI models for coding often seek transparency, customization, and infrastructure control. Proprietary models, on the other hand, offer faster onboarding, reliability, and vendor-managed updates.

While there is no single “best” option, the selection of either an open-source or proprietary model comes down to organizational priorities such as compliance, scalability, and available DevOps resources. The following comparison table summarizes each type’s advantages, limitations, and best-fit scenarios.

Comparison of open-source and proprietary AI coding models

Now that we have explored the various models open to developers, we will examine enterprise-readiness and security and consider how organizations evaluate governance, compliance, and reliability when adopting AI coding solutions.

Enterprise readiness and security

Enterprise AI coding tools must meet requirements far beyond accuracy or productivity gains. Security, compliance, and governance also play a decisive role.

According to the JetBrains Developer Ecosystem Report 2025, many companies hesitated to adopt AI coding tools due to concerns about data privacy, IP protection, and model transparency.  These need to be addressed to ensure secure AI for developers.

To achieve this, enterprise-ready AI models typically offer flexible deployment, role-based access control, encryption, audit logs, policy enforcement, and AI governance and compliance.

Some tools, such as JetBrains AI Assistant, support both cloud and on-premises integration, which suits teams that need a balance between agility and compliance. The table below also summarizes the capabilities and example tools required to create enterprise-ready LLMs.

Enterprise evaluation matrix for AI coding tools

Now that we understand how to create an enterprise evaluation matrix, the next section will explain how teams can choose the right AI coding model based on their specific needs, balancing control, speed, and compliance.

How to select the right AI coding model for you

The best AI for developers depends on context. They must balance control, cost, integration, and compliance to find the best LLM for team workflows, rather than look for a single winner.

As you have seen, each model is suited to meet specific needs, be they speed, governance, or flexibility. This 8-step selection framework will guide you on how to find the right AI coding model for your requirements when choosing an AI assistant.

Step-by-step selection framework

Summary takeaways

How to choose an AI coding model:

• Need control → local or open-source models
• Need speed → GPT or Claude
• Need compliance → JetBrains AI Assistant
• Focus on collaboration → IDE-integrated tools
• Align your tool choice with your team’s priorities.

Now that you have the right AI coding model, in the next section, we will answer the most common developer questions about AI coding tools.

FAQ

Q: Which AI model was most popular among developers in 2025?
A: GPT-4o, Claude 3.7 Sonnet, and Gemini 2.5 Pro were the most frequently used AI models for coding tasks, according to the JetBrains Developer Ecosystem Report 2025.

Q: Are there free or affordable AI models for coding?
A: Yes. DeepSeek R1 and open-source models like Qwen or StarCoder provide cost-efficient options for developers exploring AI assistance.

Q: Which AI coding tools integrate best with JetBrains IDEs?
A: JetBrains AI Assistant integrates multiple LLMs, including GPT and Claude models, directly into IDE workflows for real-time suggestions and contextual understanding.

Q: Is it safe to use AI coding tools for proprietary projects?
A: Yes, if using tools with strong data privacy policies or local execution options. Many teams adopt private or on-premises models to retain full control of source code.

Q: What’s the difference between cloud and local AI models?
A: Cloud models offer convenience and scalability, while local or self-hosted models provide greater data control and compliance for enterprise use.

Q: Which AI model is best for enterprise environments?
A: Enterprise-ready tools like JetBrains AI Assistant, Claude for Teams, and Harness provide features such as RBAC, audit logs, and SSO for secure governance.

Q: How widely are AI tools adopted among developers?
A: As seen in data shared from the JetBrains Developer Ecosystem Report 2025 earlier, more than two-thirds of professional developers used some form of AI coding assistance, reflecting strong industry-wide adoption.

The next section will summarize the key insights and encourage readers to explore JetBrains AI tools for their own development workflows.

Conclusion

AI coding models have moved from experimentation to everyday development practice. Developers now rely on AI assistants to write, review, and understand code at scale. GPT, Claude, Gemini, and DeepSeek lead the field, while open-source and local options continue to gain traction for privacy and customization.

The JetBrains Developer Ecosystem Report 2025 found that there is no single best AI model for coding. The right choice depended on workflow, team size, and governance requirements.

As AI-assisted development evolves, improvements in reasoning, context length, and IDE integration will further shape how developers build software with AI’s help.

To experience these capabilities firsthand, start exploring AI-powered development today. Learn more about JetBrains AI Assistant, and see how it can enhance your development workflow.

🚀 Executive Summary

TL;DR: A nested .git folder within a Git subdirectory creates ‘phantom submodule’ behavior, preventing the parent repository from tracking individual files and leading to deployment issues. This problem can be resolved by either removing the nested .git folder, formalizing it as a proper Git submodule, or performing a ‘scorched earth’ reset for a guaranteed clean state.

🎯 Key Takeaways

• A ‘phantom submodule’ or ‘Git Nesting Doll’ occurs when a subdirectory contains its own .git folder, causing the parent repository to track it as an empty pointer instead of its actual files.
• Git status will show ‘modified: (new commits)’ for the problematic directory, but files within it cannot be added or committed directly.
• Solutions range from the quick fix of removing the nested .git folder (destructive to inner history) to formalizing it as a proper submodule (preserving history) or a ‘scorched earth’ reset for stubborn cases.

Struggling with a Git subdirectory that won’t track files? Learn why a nested .git folder creates ‘phantom submodule’ behavior and discover three battle-tested methods to fix it, from the quick-and-dirty to the permanent solution.

What in the World Would You Call This? Taming Git’s Phantom Submodules

I’ll never forget it. 3 AM, a Thursday morning, and a ‘critical’ hotfix deployment to production. All the CI checks were green, tests passed, the pipeline glowed with success. We hit the big red button. Ten seconds later, alarms blare. The application on prod-app-01 is crash-looping. The logs scream FileNotFoundException: /etc/app/config/prod-secrets.json. I SSH in, heart pounding, and navigate to the directory. It’s empty. The entire prod-secrets/ directory, which should have been full of config files, was just… gone. After a frantic half-hour, we found the culprit. A junior dev, trying to be helpful, had run git init inside that directory by mistake. Our parent repo saw it, shrugged, and just committed an empty pointer to it instead of the actual files. We’ve all been there, and that phantom commit cost us an hour of downtime and a lot of sweat.

So, What’s Actually Happening Here?

When you see this in your terminal, it’s Git trying to be smart, but in a way that’s incredibly confusing at first glance:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   src/vendor/some-library (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

You see modified: src/vendor/some-library, but you can’t add it, you can’t commit it, and Git won’t show you the files inside. This happens because the some-library directory contains its own .git folder. The parent repository sees that .git folder and says, “Whoa, that’s another repository’s territory. I’m not going to track its individual files. I’ll just track which commit that repository is on.”

It’s treating it like a submodule, but without the proper setup in your .gitmodules file. I call it a “Phantom Submodule” or a “Git Nesting Doll”. It’s a repository within a repository, and it’s a common headache.

Three Ways to Fix This Mess

Depending on your goal and how much you value the history within that nested repo, here are the three paths I usually take, from the quick-and-dirty to the architecturally sound.

Solution 1: The Quick Fix (Just Nuke the .git Folder)

This is the most common solution and, honestly, the one you’ll use 90% of the time. The problem is the nested .git directory. The solution? Get rid of it.

When to use this: You downloaded a library, cloned a project into another, or accidentally ran git init, and you do not care about the git history of the inner folder. You just want its files to be part of your main project.

1. Navigate to your project’s root directory.
2. Simply remove the .git directory from the subdirectory. Be careful with rm -rf!

# The path here is the subdirectory that Git is ignoring
rm -rf ./src/vendor/some-library/.git

1. Now, run git status again. The “submodule” entry will be gone, and Git will suddenly see all the files in that directory as new, untracked files.
2. Add them like you normally would.

git add src/vendor/some-library/
git commit -m "feat: Absorb some-library files into the main repo"

Warning: This is a destructive action for the nested repository. You are permanently deleting its commit history. If you might need that history, do not use this method. Proceed to Solution 2.

Solution 2: The ‘Right’ Way (Embrace the Submodule)

Sometimes, you want to keep the two projects separate. Maybe some-library is an open-source tool you use, and you want to be able to pull updates from its own remote. In this case, you should formalize the relationship by properly adding it as a submodule.

When to use this: The subdirectory is a legitimate, separate project that you want to link to your main project while keeping its history and identity intact.

1. First, remove the “phantom” entry from Git’s index. We need it to stop tracking that path before we can re-add it properly.

# Note the trailing slash is important here
git rm --cached src/vendor/some-library

1. Commit this removal to clean up the state.

git commit -m "chore: Remove incorrect submodule reference"

1. Now, properly add the directory as a submodule. You’ll need the URL of its remote repository.

# git submodule add [repository_url] [path]
git submodule add https://github.com/some-user/some-library.git src/vendor/some-library

This creates a .gitmodules file and correctly registers the submodule. Now you can manage it properly, pulling updates and committing specific versions.

Solution 3: The ‘Scorched Earth’ Reset

I’ve seen situations where the Git index gets so confused that the above methods don’t work cleanly. This is my “when all else fails” approach. It’s brute force, but it’s clean and guaranteed to work.

When to use this: The other methods aren’t working, or you just want to be 100% certain you have a clean slate without any lingering Git weirdness.

1. Move the problematic subdirectory completely out of your project.

mv src/vendor/some-library /tmp/some-library-backup

1. Commit the deletion. Your repository now officially has no knowledge of this folder.

git add src/vendor/
git commit -m "chore: Forcibly remove some-library to fix tracking"

1. Delete the .git folder from your backup copy.

rm -rf /tmp/some-library-backup/.git

1. Move the folder (now clean of its own Git history) back into your project.

mv /tmp/some-library-backup src/vendor/some-library

1. Add and commit the files. They will now be seen as brand new additions.

git add src/vendor/some-library/
git commit -m "feat: Re-add some-library files with correct tracking"

Which One Should You Choose?

Here’s a quick breakdown to help you decide.

At the end of the day, don’t feel bad when you run into this. It’s a rite of passage. It’s a quirk of how a powerful tool like Git works, and understanding why it happens is the key to not letting it derail your 3 AM deployment. Hopefully, this gives you a clear path out of the woods next time you find a phantom submodule lurking in your repository.

👉 Read the original article on TechResolve.blog

☕ Support my work

If this article helped you, you can buy me a coffee:

👉 https://buymeacoffee.com/darianvance