All the interesting technology and cool functionality in the world is meaningless if what we build doesn’t solve the problems our users need solved. To do that, we need to create experiences that make it as simple as possible for users get the output they need from our AI features and leverage it in their work.

UX Pattern: Usage Guidance

One of the biggest mistakes we can make when developing AI features is assuming that users know how to use them. As mentioned in the first article of this series: we know how to do things like provide context, specify formatting requirements, break large tasks into smaller ones, and iterate toward better results when using AI—but our users often won’t.

When we place a blank text box in front of a user and tell them to “Ask AI,” we're actually asking them to do a lot of prework before they even get to their main task. So much, in fact, that it may actually create more work for them than just completing the task themselves.

They need to understand what kinds of problems the tool can solve, how specific they should be, what information the AI needs to succeed and how to recognize when a response needs refinement.

Rather than expecting this level of AI-literacy from our users, we can help them by providing examples, templates, suggested prompts and guided workflows that demonstrate what success looks like. And if there’s existing contextual information we can leverage without making the user input it all themselves, all the better.

UX Pattern: Action Buttons

What will your users be doing with the content your AI feature generates? If they run a search or analyze a spreadsheet, what do they do with the results? If they create an image, who are they showing it to? The action itself is just the beginning of the flow for our users, who then need to do something with what they’ve received.

By including action buttons, we can make it as easy as possible to them to leverage the output of our tools in their own work. If they’re not able to act on the content that was created, it’s never going to be of much realistic use to them. And if it’s not immediately clear what they can do with what we’ve created for them, then we need to show them with real-world examples.

Once they have an idea of what they want to do, action buttons can guide them to suggested steps that help make the most of what was generated. But an application that creates content a user isn’t sure how to use is nothing more than a novelty to be used once or twice and then ignored.

UX Pattern: External Integrations

If we want to take this one step further, we can build in direct integrations with their other most-used tools. For example, generating a new document in their word processing software from an AI writing draft, pushing new code to their linked repo, opening a new ticket in their tracking system with findings from a test. The simpler we make it to get information from our tool into the rest of their workflow, the more useful it will be to them.

Can Users Trust the AI Features in Your Software?

AI can generate content, write code, analyze data, automate tasks and empower our users to do incredible work—but only if they’re willing to try it. When everything our AI tools are doing is hidden behind the curtain, it makes users feel like things are happening without their input—which is hard, especially when many of them are already feeling some level of AI skepticism and hesitation.

If we create AI experiences that take away our users’ power, understanding and autonomy, then they’ll never be interested in using what we build because they’ll never feel truly comfortable engaging with it. By focusing on patterns that reinforce those UX priorities of trust, clarity, control, transparency and meaningful benefit, we can set guardrails around our AI features that help make our users feel safe.

The technology is here. The models are already good and they just keep getting better, faster and more efficient. That means that the differentiator for AI-powered software isn’t performance, anymore. It’s the quality of the experiences that we can build around them.

The line between design and development is blurring a little more every day: how users interact with a system, how much information they see, how much control they have and how we earn their trust are now questions that developers have to consider when building AI-powered software—whether your title includes “designer” or not. The technology may be incredible, but for it to be truly successful, users still need to be at the center of everything we build.

LangGraph is a framework for building AI agents and workflows as stateful graphs. Each step in the workflow is represented as a node. Edges define how execution flows between nodes, and state acts as shared memory throughout the graph.

Built on top of LangChain, LangGraph provides explicit and debuggable control over multi-step LLM applications such as chatbots, tool-calling agents and automated pipelines.

In this article, we will use TypeScript to build a simple LangGraph application from scratch and explore the core concepts, APIs and execution model that form the foundation of more advanced agentic workflows.

LangGraph has three building blocks.

1. State
2. Node
3. Edges

State represents data that is shared by every node. A node represents a function that takes a state as input and returns an updated value for the state. Edges are control flow, which can be serial, parallel or conditional.

To understand how graphs work, we’ll start with a simple counter application that does not require a model. This example will introduce the core concepts of state and node, and by the end of the section, you’ll understand how they form the foundation of a graph.

At the end of the article, we will create a FIFA chatbot using an OpenAI model and LangGraph using nodes, states and edges.

What Is a State?

In LangGraph, a state is a data structure that serves as a shared memory layer that connects the graphs. Nodes consume state, produce incremental updates and rely on it for conditional routing.

Every node in the graph depends on the state. Nodes read data from the state and write partial updates back to it. And conditional edges use the state to determine the next path in the workflow.

StateSchema is the contract that defines the structure and behavior of a state in LangGraph. More than just a TypeScript type, it serves as a runtime specification that determines:

• Which fields exist in the state
• Their types and default values (defined with Zod)
• How updates are merged (reducers vs. last-write-wins)
• Which data nodes can read from and write to

You can create a state using the StateSchema as shown below:

counter-state.schema.ts

import { ReducedValue, StateSchema } from "@langchain/langgraph";
import { z } from "zod";

export const CounterStateSchema = new StateSchema({
  count: new ReducedValue(z.number().default(0), {
    inputSchema: z.number(),
    reducer: (current, next) => current + next,
  }),
});

Every key in a StateSchema can be one of the following:

1. Zod Field – A standard state field defined with Zod. Updates follow a last-write-wins strategy, meaning the most recent value replaces the previous one.
2. ReducedValue – A field that updates by combining the new value with the existing value instead of replacing it. In the example above, count is a ReducedValue, so each update is merged with the current count rather than overwriting it.
3. MessageValue – A specialized form of ReducedValue designed for chat applications. Instead of replacing existing messages, new messages are automatically appended to the conversation history.

Once state is defined using the StateSchema, you can work with the three derived types:

1. State – Full object during the execution
2. Update – Partial object a node may return
3. Node – Function signature

counter-state.types.ts

export type CounterState = typeof CounterStateSchema.State;
export type CounterUpdate = typeof CounterStateSchema.Update;
export type CounterNode = typeof CounterStateSchema.Node;

For this example, we will mostly work with the CounterNode. Also, the CounterStateSchema has:

1. Initial value set to 0
2. Each nodes return the updated value
3. Reducer adds current value to the previous value

What Is a Reducer?

Before we move further, let’s discuss the reducer function. It is a simple function that decides how a state field changes when a node returns an update. Multiple nodes can update the same field during a graph execution. Instead of overwriting the existing value, the reducer merges each partial update into the current state.

As nodes returns partial updates, LangGraph would need a rule for conflicting updates. That merge rule is written inside the the reducer function.

reducer: (current, next) => current + next,

The signature of the reducer:

• current – value in state before this update
• next – what the node returned for this field
• return value – new stored value

Use a reducer only when values need to be combined or accumulated. If each update should simply replace the previous value, a standard field is all you need. As shown in below state schema, each time state will be updated with the last returned value from the node.

lastcount-state.schema.ts

export const LastCountStateSchema = new StateSchema({
  count: z.number().default(0),
});

For LastCountState, derived states can be exported as shown below:

lastcount-state.types.ts

export type LastCountState = typeof LastCountStateSchema.State;
export type LastCountUpdate = typeof LastCountStateSchema.Update;
export type LastCountNode = typeof LastCountStateSchema.Node;

So far, we have defined two state schemas and exported their corresponding TypeScript types. The CounterState uses a reducer to accumulate new values with the existing value, while the LastCountState follows a last-write-wins approach and always stores the most recent value. Next, let’s create the nodes that will operate on these states.

Creating Nodes

In LangGraph, a node is the fundamental building block of a graph. It is usually implemented as a function that takes the current state as input, performs some computation or action, and returns a partial update to the state.

Depending on how the state schema is defined, LangGraph either merges the returned update into the existing state using the configured reducer or replaces the current value with the latest one before passing the updated state to the next step in the workflow.

You can create nodes to increment a counter state by 1 and 2 like below:

counter.node.ts

export const incrementNode: CounterNode = () => ({
  count: 1,
});

export const incrementTwiceNode: CounterNode = () => ({
  count: 2,
});

After each node runs, LangGraph:

• Receives the partial state update returned by the node
• Merges the update into the current state using the rules defined in the StateSchema
• Passes the resulting state to the next node, or terminates the graph if execution is complete

For LastCountState, a node can be created as shown below:

export const setOneNode: LastCountNode = () => ({
  count: 1,
});

export const setFiveNode: LastCountNode = () => ({
  count: 5,
});

export const setNineNode: LastCountNode = () => ({
  count: 9,
});

Because LastCountState stores only the latest value, every node overwrites the previous value, and the next node receives the most recent state update.

As we discussed earlier, a node only returns a partial state update. How that update is applied to the state is determined by the StateSchema through its merge strategy (reducers or last-write-wins), not by the node’s implementation.

Also, nodes do not decide where execution goes next; edges do. Nodes only read state and write updates.

There are four types of nodes:

1. Synchronous node – Returns an object immediately
2. Asynchronous node – Returns a promise
3. Stateless node – Ignores the state value and always returns the same value
4. Stateful node – Reads the fields from the state and computes the new value from them

All the nodes we have created so far for both CounterState and LastCountState are synchronous and stateless.

We can create a stateful node on CounterState as shown below:

export const doubleCountNode: CounterNode = (state) => ({
  count: state.count,
});

We have created nodes; now see how they are connected using edges.

Creating an Edge

An edge connects two nodes and determines the control flow by specifying which node executes after the current node completes.

An edge can be of two types:

1. Fixed edge – Always goes to the same next node
2. Conditional edge – Next node depends on state or routing function

To work with nodes and edges, LangGraph provides two special nodes:

1. START – Entry node, and it contains no custom code
2. END – Exit node, and it also contains no custom code

Building the Graph

The LangGraph graph is where you assemble everything. A graph brings together the state schema, nodes and edges into an executable workflow. You create and run a graph following the steps:

• Create a StateGraph using your state schema.
• Add nodes with addNode() to define the tasks in the workflow.
• Connect nodes with addEdge() to specify the execution order.
• Compile the graph using compile() to generate a runnable workflow.
• Invoke the graph with invoke(), which starts execution at START.
• Execute nodes in the order defined by the graph’s edges.
• Apply reducers after each node runs to update the shared state.
• Continue execution until the graph reaches the END node.
• Return the final state as the workflow’s output.

Think of the graph as the orchestrator, the nodes as workers performing tasks, and the state as the shared memory that connects them.

There are three steps to build the graph:

1. Create a StateGraph with your schema
2. Register nodes and edges
3. Call .compile() to get a runnable graph

We can create a graph for CounterState as shown below:

counter.graph.ts

export function buildCounterGraph() {
  return new StateGraph(CounterStateSchema)
    .addNode("increment", incrementNode)
    .addNode("incrementTwice", incrementTwiceNode)
    .addNode("doubleCount", doubleCountNode)
    .addEdge(START, "increment")
    .addEdge("increment", "incrementTwice")
    .addEdge("incrementTwice", "doubleCount")
    .addEdge("doubleCount", END)
    .compile();
}

As you can see:

• addNode() adds a node to the graph. Each node is a step.
• addEdge() is used to add an edge to the graph. Edges know the step by the string name, not the node function name.
• new StateGraph() creates a graph bound to the state schema definition.
• .compile() validates the graph. It checks for:
         a. Is there any path from START to END
         b. Do node name edge exist
         c. Is the schema wired correctly
         d. Then returns a compiled graph

In the same way, you can create a graph for LastCountState:

lastcount.graph.ts

export function buildLastCountGraph() {
  return new StateGraph(LastCountStateSchema)
    .addNode("setOne", setOneNode)
    .addNode("setFive", setFiveNode)
    .addNode("setNine", setNineNode)
    .addEdge(START, "setOne")
    .addEdge("setOne", "setFive")
    .addEdge("setFive", "setNine")
    .addEdge("setNine", END)
    .compile();
}

We use addEdge() to connect nodes and define the execution flow within the graph. Key characteristics of addEdge() are:

• The addEdge(startKey, endKey) creates an unconditional edge.
• Once the startKey node completes, execution always proceeds to the endKey node.
• Possible values of startKey are START or node name or node name [].
• Possible values of endKey are END or node name.

In the count graph, we start at the increment node and create a linear chain to the doubleCount node.

    .addEdge(START, "increment")
    .addEdge("increment", "incrementTwice")
    .addEdge("incrementTwice", "doubleCount")
    .addEdge("doubleCount", END)

This is a linear chain.

Graph Rules to Remember

When building a LangGraph workflow, keep the following rules in mind:

1. Node names must be valid.
   Every node referenced in an edge must either be a registered node name or one of the special nodes: START or END.


2. Use the graph node name, not the function name.
   When creating edges, refer to the string name assigned in addNode(), not the underlying function name.


3. A graph must have a starting path.
   Every runnable graph must contain at least one edge originating from START.


4. A graph must have a termination path.
   Every runnable graph must contain at least one edge leading to END.


5. Unreachable nodes are dead code.
   If a node cannot be reached from START, it will never execute and is effectively dead code within the graph.


6. addEdge() creates unconditional transitions.
   addEdge() does not evaluate the graph state or any conditions. Execution always follows the defined path. If you need conditional routing (for example, “if count > 5 go here, otherwise go there”), use addConditionalEdges(). We’ll explore conditional routing in the next article.

Invoking the Graph

We can invoke the graph using the invoke() method.

const graph = buildCounterGraph();
const result = await graph.invoke({});
console.log(result);

The invoke method returns the final state, and you should see output {count: 6}. There is another method, stream(), to read the state after each node’s execution, and we will cover it in the next article.

In the same way, you can invoke LastCountGraph as shown below:

const graph1 = buildLastCountGraph();
const result1 = await graph1.invoke({});
console.log(result1);

You should get the result {count: 9}.

In this way, you can create a basic LangGraph graph using state, state schema, edges and nodes.

The following diagram brings together all the concepts we have learned so far and illustrates the main building blocks of a LangGraph.

FIFA Chat Example

Now that we’ve covered the core LangGraph concepts, let’s put them into practice by building a chat application that answers questions about the FIFA World Cup.

Let us start by defining the state with MessageValue.

const schema = new StateSchema({ messages: MessagesValue });

Next, create the language model for our FIFA World Cup chatbot using OpenAI’s GPT. Before initializing the model, add your OpenAI API key to the .env file.

const model = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0 });

Next, set the system prompt such that the model only answers about FIFA and does not answer on other topics.

const SYSTEM = `You are a FIFA World Cup expert. ONLY answer questions about the FIFA World Cup (1930–present): winners, hosts, matches, records, players in World Cup context.
For anything else, reply exactly: "I can only help with FIFA World Cup questions."`;

Next, create the node that acts as an agent. It will read messages, call the models and return the model’s new reply. The MessageValue reducer will append the message to the message history.

const agent: typeof schema.Node = async (state) => ({
  messages: [await model.invoke(state.messages)],
});

Next, let’s build the graph. In this example, the graph consists of a single node with an incoming START edge and an outgoing END edge.

const graph = new StateGraph(schema)
  .addNode("agent", agent)
  .addEdge(START, "agent")
  .addEdge("agent", END)
  .compile();

Then, we seed the state with the SystemMessage:

let state: typeof schema.State = { messages: [new SystemMessage(SYSTEM)] };

Finally, inside the loop, we invoke the graph as below:

  state = await graph.invoke({
    ...state,
    messages: [...state.messages, new HumanMessage(question)],
  });

Here we are using schema.state, which is the full state graph read and write. Putting everything together, FIFA Chat Bot should look like below:

import { stdin as input, stdout as output } from "node:process";
import * as readline from "node:readline/promises";

import { HumanMessage, SystemMessage } from "@langchain/core/messages";
import { ChatOpenAI } from "@langchain/openai";
import { END, MessagesValue, START, StateGraph, StateSchema } from "@langchain/langgraph";
import "dotenv/config";

const schema = new StateSchema({ messages: MessagesValue });

const model = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0 });

const SYSTEM = `You are a FIFA World Cup expert. ONLY answer questions about the FIFA World Cup (1930–present): winners, hosts, matches, records, players in World Cup context.
For anything else, reply exactly: "I can only help with FIFA World Cup questions."`;

  const agent: typeof schema.Node = async (state) => ({
    messages: [await model.invoke(state.messages)],
  });

const graph = new StateGraph(schema)
  .addNode("agent", agent)
  .addEdge(START, "agent")
  .addEdge("agent", END)
  .compile();

let state: typeof schema.State = { messages: [new SystemMessage(SYSTEM)] };

const rl = readline.createInterface({ input, output });

console.log("⚽ FIFA World Cup Chat — type 'exit' to quit\n");

while (true) {
  const question = (await rl.question("You: ")).trim();
  if (!question) continue;
  if (question === "exit" || question === "quit") break;

  state = await graph.invoke({
    ...state,
    messages: [...state.messages, new HumanMessage(question)],
  });

  console.log(`\nAssistant: ${state.messages.at(-1)?.content}\n`);
}

rl.close();

You have created a FIFA chatbot using Graph, which uses nodes, state and edges. In further articles, we go deeper into creating agents using LangGraph. I hope you find this article useful. Thanks for reading.

AI engineering comes with a vocabulary hurdle. LLMs, embeddings, vector databases, RAG, agents, memory, orchestration, evaluation, observability: the terms tend to arrive all at once, and most explanations treat them as a glossary of disconnected definitions. That makes the field feel larger and stranger than it is.

In the first article of this AI Engineering Basics series, we made the case that the full-stack role is expanding rather than being replaced, and that the developers who adapt will treat AI as a new layer of the stack to master. This article builds the mental model for that layer. Every term above has a job; the jobs relate to each other the same way the pieces of a web application do, and once we see the structure, the terms fall into place.

We’ll organize the stack into five layers, and each one maps onto an instinct we already have:

To keep things concrete, we’ll follow a single example throughout: a customer support assistant for TaskFlow, a fictional project management product. By the end, we’ll trace one user request through all five layers.

The Model Layer: LLMs

At the base of the stack sits the large language model (LLM), the component that understands and generates language. Models from providers like OpenAI, Anthropic and Google are available behind ordinary APIs, and calling one looks like calling any other web service. A minimal request for our TaskFlow assistant:

const response = await openai.responses.create({
  model: "gpt-5",
  instructions: "You are a support assistant for TaskFlow.",
  input: "How do I export my project data?",
});

console.log(response.output_text);

We send the user’s input along with instructions that set the assistant’s role, and we get generated text back. There’s no infrastructure to manage and no machine learning background required.

Two properties of this call shape everything else in the stack.

First, the model itself is stateless. It retains nothing between requests, so anything it should know (the conversation so far, the user’s plan, the relevant documentation) must be assembled into each request. Provider APIs can do some of that bookkeeping for us; the OpenAI Responses API, for example, can store conversation state server-side and chain turns with a previous_response_id parameter. The convenience leaves the underlying principle intact, since the full history still gets fed to the model (and billed as input tokens) on each call.

Second, the request has a size limit called the context window, measured in tokens, which caps how much we can include. A model’s knowledge is otherwise frozen at training time, which means our TaskFlow assistant, out of the box, knows nothing about TaskFlow.

The model, in other words, is a powerful runtime with no memory and no knowledge of our product, and the rest of the stack exists to work around those two gaps.

The Knowledge Layer: Embeddings, Vector Databases and RAG

Our assistant needs to answer questions about TaskFlow’s actual documentation, and stuffing every doc into each request would blow through the context window (and the budget). The knowledge layer solves this by finding the few passages that matter for a given question and supplying only those.

The mechanism underneath is the embedding, a representation of text as a vector of numbers. Think of it as a coordinate system for meaning: just as GPS coordinates position a location on a map, an embedding positions a piece of text in a high-dimensional space where distance reflects similarity of meaning. The embeddings for “How do I export my project data?” and “Downloading your projects as CSV” land close together in that space despite sharing almost no words, while a passage about billing lands far away.

Those vectors need a home, which is what a vector database provides. It stores the embeddings for every chunk of our documentation and can answer the question “which stored chunks are closest to this query?” across millions of entries in milliseconds.

Retrieval-Augmented Generation (RAG) is the pattern that ties these pieces to the model. When a user asks a question, the system retrieves the most relevant chunks from the vector database, augments the prompt with them and asks the model to generate an answer grounded in that material. The model still does the writing, but it works from our documentation rather than its training data, which keeps answers current and lets them cite sources. Platforms like Progress Agentic RAG package this whole layer (chunking, embeddings, indexing, retrieval) as a service, and we’ll dig into RAG in a dedicated article later in this series.

The Action Layer: Agents, Tools and Memory

Answering questions only gets our assistant so far. A user who asks “Can you move all my overdue tasks to next sprint?” wants something done, and doing things is the action layer’s job.

We covered the assistant-versus-agent distinction in the first article, so a short recap suffices here. An agent receives a goal rather than a question, plans the steps to reach it, acts, checks the results and adjusts until the task is done.

Tool use is what makes that possible. A tool is an operation we expose to the model with a name, a description, and typed parameters, like move_task(task_id, sprint_id) or get_overdue_tasks(project_id). The model doesn’t execute anything itself; it outputs which tool it wants to call and with what arguments, our code runs the call, and the result goes back into the conversation for the model’s next decision. The Model Context Protocol (MCP) is the emerging standard for wiring these connections consistently.

Memory rounds out the layer, and it splits into two kinds. Short-term memory is the running conversation, resent with each request so the model can follow references like “move those ones too.” Long-term memory persists across sessions in ordinary storage we control: when our assistant remembers that a user prefers two-week sprints, our application saved that fact and retrieved it into the context at the right moment. Memory patterns get their own article later in the series.

The Coordination Layer: Orchestration

A real support interaction rarely fits in one model call. Consider a TaskFlow user reporting a duplicate charge. A production-quality handling of that request might start by classifying the message as a billing issue, retrieving the refund policy and looking up the account’s payment history through a tool. From there, it drafts a response and routes the case to a human when the refund amount exceeds a threshold. Each step might involve a different model call, a different tool or no model at all.

Orchestration is the layer that coordinates these multi-step flows. It carries state from step to step and decides which branch to take based on intermediate results. It also handles the operational details: retrying transient failures, enforcing timeouts, and managing handoffs between models, tools and humans.

If the model layer is a runtime, orchestration is the backend workflow engine wrapped around it, and the discipline it demands is the same one we apply to any distributed system: clear steps, explicit state and predictable failure handling. Frameworks exist to help (LangGraph is a prominent example), though plenty of production systems orchestrate with plain application code.

The Trust Layer: Evaluation and Observability

Everything up to this point gets a system working. The trust layer is what lets us ship it and keep it running, and it’s the part of the stack that teams most often discover too late.

Evaluation answers the question “is this working?” for systems whose outputs aren’t deterministic. A traditional assertion like expect(output).toBe(expected) falls apart when the same input can produce different, equally valid responses. Instead, we build evaluation sets: collections of representative inputs paired with criteria for judging the outputs, whether that judgment comes from string checks, from rules or from another model acting as a grader. Evaluations run whenever we change a prompt, swap a model or adjust retrieval, serving the same role a regression suite serves in conventional software.

Observability answers “what is it doing in production?” For our TaskFlow assistant, that means tracing each request through every layer it touched: the documents retrieval returned, the tools the agent called and what each model call consumed and cost.

Token usage deserves particular attention because it’s both the cost model and an early warning signal. A prompt change that doubles token consumption shows up in the bill before it shows up anywhere else.

Traces also turn debugging from guesswork into inspection, since we can see when retrieval surfaced the wrong document or when a tool returned an error that the model papered over.

This layer is also where governance lives: knowing what our AI systems are doing, proving it and enforcing limits on agent behavior. The AI operations articles later in this series spend most of their time here.

One Request Through the Stack

To pull the layers together, we can follow a single message end to end. A TaskFlow user writes: “I was charged twice for my Pro subscription this month. Can I get a refund?”

1. Orchestration receives the message and classifies it as a billing issue with a refund request.
2. The knowledge layer retrieves TaskFlow’s refund policy and the duplicate-charge troubleshooting guide from the vector database.
3. The action layer calls the get_payment_history tool, confirms the duplicate charge and checks memory for prior billing issues on the account.
4. The model receives the policy, the payment data and the conversation, and drafts a response with a proposed refund.
5. The refund amount falls under the auto-approval threshold, so orchestration executes the create_refund tool call; had it been larger, the flow would have paused for human approval.
6. The trust layer records the full trace: documents retrieved, tools called, tokens spent and the outcome, ready for review and for the next evaluation run.

Notice that no single layer did anything magical. The model wrote text, retrieval found documents and tools touched real systems. Orchestration kept the steps in order while the trust layer recorded it all. The modern AI stack amounts to familiar engineering arranged around one unfamiliar component.

Wrap-up

The vocabulary of AI engineering describes a stack with real structure. Models generate, the knowledge layer grounds them in our data, the action layer lets them do things, orchestration coordinates the steps, and evaluation and observability make the whole thing trustworthy enough to operate.

Each layer maps onto skills full-stack developers already practice, and each one gets a deeper treatment as this series continues, starting with how these pieces are architected into real applications.

For more on the platforms and standards mentioned in this article, check out the following resources:

• Progress AI Engineering Solutions
• Progress Agentic RAG
• Model Context Protocol Documentation

Displaying data to users is common in web applications. One question you may ask, and which doesn’t always have the same answer, is how to choose the right component to do it.

Would it be appropriate to show a table with all the columns? Or would a card gallery like those used in mobile apps be better?

For that reason, in this article we will analyze the components Blazor ListView and Blazor DataGrid from the Progress Telerik UI library, comparing their features. Let’s go!

The Problem of Choosing the Wrong Component

How we choose to display information in our web application depends on several variables:

• The type of user: A user who requires detailed information about an item is not the same as someone who only needs to see general information.
• The amount of fields to display: Quickly viewing information is not the same as analyzing and comparing data.
• The task to perform with the data: You may need to perform complex operations like grouping, applying filters or making comparisons between them, or you may not.

Not being clear about the purpose of using the information could lead to poor user experiences or make it difficult to work with the data.

Getting to Know the Blazor DataGrid Component

The Blazor DataGrid component allows viewing data in a tabular form. The idea of the component is to display many records in a table format with all the necessary tools for a user to analyze them.

It is a quite robust and flexible component, which in its latest versions incorporates AI features for better data understanding. Among its main capabilities we can find:

• Sorting by one or multiple columns
• Filtering on each column
• Grouping by dragging headers
• Paging with traditional pagination or virtual scrolling
• Inline or popup editing of records
• Resizable, reorderable and lockable columns
• Exporting to Excel and PDF
• Single or multiple selection
• Customization using templates
• Drag & drop support
• Smart AI features that work with natural language queries

From the characteristics described, you can notice that we are talking about a component that should be used when users want to see many rows and fields at the same time and be able to manipulate them.

Some ideal use cases for this component are administrative panels, ERPs, support dashboards, internal tools or any interface where data takes priority over aesthetics.

The Blazor ListView Component

The Blazor ListView component can be considered a freer component than the Blazor Grid. Instead of a tabular structure, the data is provided to you as a context that you can render as you wish. This means you can customize the UI to create cards, timelines, custom rows or any Razor structure you want.

Some of the component’s main features include:

• Customizable built-in paging
• On-demand loading
• Handling of CUD operations through built-in commands
• Custom data source operations
• Fully customizable templates

This component is ideal when the data is not tabular or when the layout needs to adapt to multiple screen styles. Some examples of when to use this component are news feeds, visual catalogs, item galleries, among others.

When to Use a Grid vs. a ListView?

In addition to the analysis we’ve done for each component, I’d like to share some comparative points about when to use a Grid and when to use a ListView.

It’s advisable to use a Grid when:

• You need the user to be able to compare values across rows
• Each record has many fields to be analyzed
• Screen space is not an issue
• You require complex operations such as sorting, filtering or grouping
• You need to edit data in bulk
• You need to export table data

On the other hand, it’s advisable to use a ListView when:

• Records have few fields or are ideal for visually rich interfaces
• User interaction involves viewing items one at a time, not analyzing them
• You need full control over the layout of each item
• You are building some type of app that includes a card-like component or similar

Let’s see how both views look in a real example.

Creating a Blazor Project with ListView and Grid

To demonstrate the difference between the two components and see when it’s convenient to use one over the other, let’s create a component that loads 50 orders and allows switching the view between a ListView-style and a Grid-style.

To achieve this, start by creating a project with the Blazor Web App template, selecting Interactive render mode in Server and Interactivity location in Global. Then, you can follow the official installation guide for Telerik UI for Blazor to install the Telerik components in your project.

Defining the App Data Model

Once the Telerik components are installed in the project, the next step will be to create the data model that represents a sales order in the system. For this, we will use a record type as follows:

public record SalesOrder(
    int OrderId,
    string Customer,
    string Product,
    string Category,
    int Quantity,
    decimal UnitPrice,
    DateTime OrderDate,
    string Status)
{
    public decimal Total => Quantity * UnitPrice;
}

Now, let’s create a service that will generate the fictitious orders.

Creating a Data Service

Let’s create a service class that will be used to generate the fictitious orders. For this, let’s add an interface and its corresponding implementation:

public interface ISalesService
{
    IReadOnlyList<SalesOrder> GetOrders();
}

public class SalesService : ISalesService
{
    private static readonly string[] Customers =
    [
        "Contoso", "Fabrikam", "Adventure Works",
        "Northwind Traders", "Telerik"
    ];

    private static readonly (string Product, string Category, decimal Price)[] Catalog =
    [
        ("Laptop Pro 15",      "Electronics", 1299.99m),
        ("Wireless Mouse",     "Electronics",   45.00m),
        ("4K Monitor",         "Electronics",  399.50m),
        ("Mechanical Keyboard","Electronics",  129.99m),
        ("Running Shoes",      "Clothing",      89.95m),
        ("Winter Jacket",      "Clothing",     159.99m),
        ("Organic Coffee",     "Food",          24.50m),
        ("Premium Tea Box",    "Food",          18.75m),
        ("Office Chair",       "Furniture",    249.00m),
        ("Standing Desk",      "Furniture",    599.00m)
    ];

    private static readonly string[] Statuses =
        ["Pending", "Shipped", "Delivered", "Cancelled"];

    public IReadOnlyList<SalesOrder> GetOrders()
    {
        var random = new Random(42);
        var orders = new List<SalesOrder>();

        for (int i = 1; i <= 50; i++)
        {
            var item = Catalog[random.Next(Catalog.Length)];
            orders.Add(new SalesOrder(
                OrderId: 1000 + i,
                Customer: Customers[random.Next(Customers.Length)],
                Product: item.Product,
                Category: item.Category,
                Quantity: random.Next(1, 10),
                UnitPrice: item.Price,
                OrderDate: DateTime.Today.AddDays(-random.Next(0, 60)),
                Status: Statuses[random.Next(Statuses.Length)]
            ));
        }

        return orders;
    }
}

The code is simple, defining arrays with information that will simulate a business dataset, as well as generating 50 orders by randomly combining the arrays.

To be able to inject the service, we will go to Program.cs, where we will add it as Singleton:

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddSingleton<ISalesService, SalesService>();

var app = builder.Build();

With the service ready, we can start with the visual tests.

Preparing the Orders Page

In the Components\Pages folder we will create a new component called SalesOrders.razor, which will look as follows:

@page "/sales-orders"
@using SalesOrderListGridDemo.Services
@using SalesOrderListGridDemo.Models
@rendermode InteractiveServer
@inject ISalesService SalesService

<PageTitle>Sales Orders</PageTitle>

<h1>Sales Orders</h1>

<p>
    Switch between the <strong>ListView</strong> and the
    <strong>DataGrid</strong> using the toggle below.
</p>

<div class="sales-toolbar">
    <TelerikButtonGroup SelectionMode="@ButtonGroupSelectionMode.Single">
        <ButtonGroupToggleButton Selected="@(currentView == ViewMode.ListView)"
                                 SelectedChanged="@(_ => SetView(ViewMode.ListView))">
            ListView
        </ButtonGroupToggleButton>
        <ButtonGroupToggleButton Selected="@(currentView == ViewMode.Grid)"
                                 SelectedChanged="@(_ => SetView(ViewMode.Grid))">
            DataGrid
        </ButtonGroupToggleButton>
    </TelerikButtonGroup>

    <span class="text-muted">@orders.Count orders loaded</span>
</div>

@code {
    private enum ViewMode { ListView, Grid }

    private List<SalesOrder> orders = new();
    private ViewMode currentView = ViewMode.ListView;

    protected override void OnInitialized()
    {
        orders = SalesService.GetOrders().ToList();
    }

    private void SetView(ViewMode view) => currentView = view;
}

In the code of the previous page, you can notice a few things:

• We have created a enum with the options ListView and Grid, which will allow us to switch between views.
• We load the orders into OnInitialized.
• The method SetView allows changing the view.
• We use a Blazor Button Group component, ideal for handling multiple grouped buttons. In this case, we implement it to activate one view or the other through the assignment of a state with Selected. Also, when a button is clicked, SelectedChanged is fired, which invokes the method SetView.

With the options section ready, let’s render the ListView component.

Rendering a Blazor ListView

The next step will be to render the ListView. To do this, we will add a conditional block and use the component TelerikListView:

@if (currentView == ViewMode.ListView)
{
    <TelerikListView Data="@orders"
                     Pageable="true"
                     PageSize="9">
        <Template Context="order">
            <div class="order-card">
                <div class="order-card-header">
                    <span class="order-card-id">#@order.OrderId</span>
                    <span class="status-badge status-@order.Status">@order.Status</span>
                </div>
                <div class="order-card-product">@order.Product</div>
                <div class="order-card-meta">@order.Customer   @order.Category</div>
                <div class="order-card-meta">@order.OrderDate.ToString("MMM dd, yyyy")</div>
                <div class="order-card-footer">
                    <span class="text-muted">@order.Quantity   @order.UnitPrice.ToString("C")</span>
                    <span class="order-total">@order.Total.ToString("C")</span>
                </div>
            </div>
        </Template>
    </TelerikListView>
}

In the previous code, the property Data binds to the service’s list. We configure some additional properties such as paging (Pageable) and number of items per page (PageSize). Also, we use a Template to define a custom view, highlighting only the most important data such as product, customer, category, date, total, etc.

To make the layout look correct, we will add some visual styles in wwwroot/app.css:

.sales-toolbar {
    display: flex;
    align-items: center;
    gap: 1rem;
    margin-bottom: 1rem;
    flex-wrap: wrap;
}

.order-card {
    border: 1px solid #e2e8f0;
    border-radius: 0.5rem;
    padding: 1rem;
    background: #fff;
    box-shadow: 0 1px 2px rgba(0,0,0,0.04);
    display: flex;
    flex-direction: column;
    gap: 0.5rem;
    height: 100%;
}

.order-card-header,
.order-card-footer {
    display: flex;
    justify-content: space-between;
    align-items: center;
}

.order-card-product {
    font-size: 1.1rem;
    font-weight: 600;
    color: #0f172a;
}

.order-card-meta {
    color: #64748b;
    font-size: 0.9rem;
}

.order-total {
    font-weight: 700;
    color: #0f172a;
}

.status-badge {
    display: inline-block;
    padding: 0.15rem 0.6rem;
    border-radius: 999px;
    font-size: 0.75rem;
    font-weight: 600;
    text-transform: uppercase;
}

.status-Pending   { background: #fef3c7; color: #92400e; }
.status-Shipped   { background: #dbeafe; color: #1e40af; }
.status-Delivered { background: #dcfce7; color: #166534; }
.status-Cancelled { background: #fee2e2; color: #991b1b; }

When running the application, we can see the layout we created using the ListView:

In the image above, you can notice that there is no comparison between orders; rather, there is navigation between the list items. If users wanted to group items, filter them or perform complex operations, this would not be the right component. Let’s now see how to implement a Grid.

Adding a Grid Component to the App

Let’s see how a Grid component looks, completing the else branch of the conditional in the code to add a TelerikGrid:

else
{
    <TelerikGrid Data="@orders"
                 Pageable="true"
                 PageSize="15"
                 Sortable="true"
                 FilterMode="@GridFilterMode.FilterRow"
                 Groupable="true"
                 Resizable="true"
                 Reorderable="true">
        <GridColumns>
            <GridColumn Field="@nameof(SalesOrder.OrderId)" Title="Order #" Width="110px" />
            <GridColumn Field="@nameof(SalesOrder.Customer)" Title="Customer" />
            <GridColumn Field="@nameof(SalesOrder.Product)" Title="Product" />
            <GridColumn Field="@nameof(SalesOrder.Category)" Title="Category" Width="140px" />
            <GridColumn Field="@nameof(SalesOrder.Quantity)" Title="Qty" Width="90px" />
            <GridColumn Field="@nameof(SalesOrder.UnitPrice)" Title="Unit Price" Width="130px" DisplayFormat="{0:C}" />
            <GridColumn Field="@nameof(SalesOrder.Total)" Title="Total" Width="130px" DisplayFormat="{0:C}" />
            <GridColumn Field="@nameof(SalesOrder.OrderDate)" Title="Date" Width="140px" DisplayFormat="{0:d}" />
            <GridColumn Field="@nameof(SalesOrder.Status)" Title="Status" Width="130px" />
        </GridColumns>
    </TelerikGrid>
}

In the previous code we can see the notable difference between the two components:

1. It has parameters like Sortable, Groupable, Resizable, Reorderable, etc., which enable capabilities a user expects in a table-like format.
2. The number of items shown per page is set to 15, because each row takes up less space.
3. If needed, we could customize the columns to display custom content.

When running the application, we will have a result like the following:

In the image above, you can see that we perform operations such as grouping, sorting and filtering rows.

Final Comparison Between Components

Once we have the application assembled and have seen how each component looks, we can reach the following conclusion:

• Use a ListView when you want to treat each record as an individual entity, customizing its visual hierarchy. It is a component intended to be consumed by users.
• Use a DataGrid when you want a spreadsheet-like experience, with operations such as sorting, grouping, filtering, etc. It is a component intended to be operated by users.

Each of the views has a different purpose, although it is possible to combine their use to create mixed experiences.

Conclusion

Throughout this article we have examined the ListView and Grid components from Progress Telerik UI for Blazor. We have discussed the best scenarios for using each of them, as well as the implementation code to use them.

We can conclude that you should use a ListView when the information is intended for end users, requires a high degree of customization and offers a unique exploratory experience.

On the other hand, a DataGrid can be used to display multiple records in a tabular form when operations that enable analysis are needed, such as grouping, sorting, filtering, etc.

Now I invite you to create spectacular experiences using both components. The whole Telerik UI for Blazor library is available in the free 30-day trial, including the ListView and the DataGrid.

Try Now

If you are a financial analyst, your responsibility is to “understand the numbers”—not just in terms of what “the numbers” tell you about the past but what those numbers can tell you about the future. That understanding drives your ability both to make informed decisions yourself and to support others in making informed decisions.

As a financial analyst, you work with a variety of data from multiple sources, some of them external (market information, financial forecasts) and many of them internal (budgets, financial statements and other organization data). Essentially, you turn data into information so that information can drive decisions by becoming business intelligence.

Each of your organization’s applications manages part of your organization’s data and, as a result, can provide data that you need for that process. A data exploration tool, embedded in an application’s user interface or as a standalone tool, can automatically bring together the information for any area of business. That commitment to a set of data can eliminate the time needed to extract, transform and load the data that a more general-purpose financial analysis tool (e.g., Cube) requires. You just open the application and there’s your data, ready for you to work with.

That’s only useful to you, however, if the application’s user interface goes beyond simple transaction management—if the application includes a tool that enables you to work with and explore the data embedded in the application. You need a tool that, among other things, can:

• Work with data from a wide variety of sources
• Handle large amounts of data but remain responsive (you don’t want to have to wait on your data being displayed so that you can work on it)
• Format the data to highlight key issues
• Give you the ability to change the data display as you’re working with the data to support whatever analysis you need
• Integrate support for Large Language Models to let you leverage AI analytics
• Export the data so that you can use it in other tools
• Support looking at the “big picture” while also letting you drill down into the essential detail

And, critically, you need a tool that works “the way you expect” so you don’t have to figure out how to use the tool and can concentrate on the data the grid delivers.

The Progress Telerik and Kendo UI DataGrid does all those things. (See the Blazor DataGrid Demo for example.) Some of those features are available in any implementation of the grid (“works the way you expect,” for instance). Some features will require you to specify to the application’s developers how you want the grid to work.

If, for example, you want the DataGrid to work with a data source that includes lot of rows, you’ll want developers to enable the DataGrid’s “load on demand” feature. Similarly, if you’re going to be working with data that others will be updating, you’ll want your grid to be implemented using observables that let you see those changes as early as possible.

The Initial Display

Typically, for example, you’ll want to have the DataGrid configured so that, as you open the application, the grid retrieves the data that you normally expect to work with. But if you’ll need to look at several different data sources as part of analyzing the data, then you’ll also want to have the DataGrid configured to allow you to dynamically switch to that other data.

For that initial display, you can also have your grid act as a dashboard that highlights cells (or whole rows) that signal key issues. If there are specific values that you want highlighted in the grid, you can have those values built in. But, if you want, you can also have the ability to change the values/thresholds used to highlight the data you’re interested in.

You can, of course, sort the grid’s rows into the order you need. But you can also, at any time, reorder the grid’s columns (or suppress columns) to pull together the data you’re interested right now.

And, also by default, you can filter the grid to show just the rows you need for a particular analysis. You can filter by arbitrary values (e.g., “variances greater than 5%”) or have a checkbox option for specific columns that makes it easier to select the rows you want. The DataGrid’s toolbar also includes a search textbox that you can use to find specific rows.

Supporting Multiple Configurations

That’s already multiple options and, as a result, a lot of opportunities for you to dynamically reconfigure the DataGrid as you’re working with it. Fortunately, you can also have the DataGrid save and restore your configuration settings so that you can quickly switch between different grid configurations as you need them.

AI Support

In the modern world, you’ll also want to decide how much of the grid’s AI support you’ll want to have enabled. The DataGrid gives you multiple ways to access AI processors:

• The AI Toolbar for Data Operations lets you use plain language commands to explore your data through filtering, grouping and sorting
• The AI Toolbar for Highlighting lets you flag rows that meet complicated conditions
• The AI Assistant adds a column to your table with a button that opens an AI prompt window to let you ask any question that makes sense

Grouping and Aggregating Data

The DataGrid also lets you organize rows into meaningful groups. You can, as you’re viewing the data, select the rows that you want to group or drag/drop columns or rows to create the groups you need. (See Grouping options for KendoReact Grid as an example.)

Once you create groups, you can include displays of aggregate values for those groups. But you don’t have to create groups to get aggregate values. You can, as you’re working with the grid, select the rows and columns you want to be included in your aggregated values.

While the DataGrid supports the typical aggregate functions “out of the box” (e.g., count, sum, average, etc.), you can have more sophisticated aggregates integrated into your grids.

Drilling Down

You can also have the DataGrid configured as a hierarchy of high-level sections that you can drill down into to reveal nested, detailed data. You can have your data nested as many levels deep as you need, and each level can have its own, distinct set of columns and aggregates. Effectively, you can expand your high-level rows into a different grid of detail data that reflects your needs at each level.

Exporting Data

The DataGrid also supports exporting data in a variety of formats so you can integrate other tools into your analysis (or you can just copy grid data so you can paste into some other tool).

You’re not limited to copying or exporting all the data in the grid. While you’re working with the grid, you can select the rows and columns you want you want to export into another tool (or just share with others—the grid supports multiple export formats, including PDF). If your application is using the Telerik Chart control you can export your data straight into the chart for visualization.

And, if you are using the DataGrid to facilitate selecting the data to export into some other tool, the grid supports a “high density” mode that packs more data on the screen. (See the Kendo UI for Angular Grid Grouping Display Modes page for example.)

As an analyst, you can’t really have too much data—provided, of course, your tools let you review and explore that data effectively. The Telerik DataGrid gives you a customizable window into the data for any application, turning the application itself into a tool for analyzing its own data. That enables you to create the business intelligence that drives better decisions, which is, after all, the purpose of being a financial analyst.

Check out the Telerik DevCraft suite of products to learn about the DataGrid in your favorite .NET or JavaScript flavor. And you can try out the whole suite free for 30 days.

Try Telerik DevCraft

Let’s face it: as users, we tend to be impatient when an application doesn’t respond quickly. It’s very easy to assume that the app has frozen or isn’t working when it doesn’t give us any kind of feedback.

Imagine you have an application with a menu that displays a list connected to a backend. If the backend takes time to respond and we don’t indicate to the user that data is loading, they will most likely think: “This app doesn’t work.”

As developers, it’s important to prevent this from happening. There are different ways to visually communicate that data is loading, and one of my favorites is using skeletons. These allow us to gently indicate to the user that the app is performing an action, even if the content isn’t ready yet.

In this article, we’ll learn what a Skeleton is, in which scenarios it is most useful, and how to implement the Skeleton component designed by Progress Telerik UI for .NET MAUI.

What Is a Skeleton?

Image generated using AI for illustrative purposes

A skeleton is a visual element used to indicate that content is loading. Basically, it appears on the screen as blocks (usually gray) placed in the same positions where the actual elements will be displayed once the data is available and the effect disappears.

Its purpose is to give users context while the information is loading by showing the structure that the content will have. It also typically includes a subtle animation that communicates the app is still working, even if all that’s visible are gray blocks or rectangles.

This way, instead of showing empty spaces, a traditional loader or, even worse, nothing at all, a skeleton keeps the interface clear and lets the user know that the application is working fine.

✅ When Should You Use Skeletons?

It’s important to see skeletons not just as a visual element to “entertain” users, but as a tool that allows your app to handle loading states in a smoother and more intentional way.

Let’s look at some scenarios where skeletons are especially useful:

When Waiting for API Responses

No matter how optimized your app is, it still depends on backend response times. Skeletons help bridge that gap by showing structure while data is loading. Ideally, you should display the skeleton only while the request is in progress and replace it immediately once the data is available.

Screens with Heavy Images

When loading images that may take time, skeletons are extremely useful to indicate that content is coming, instead of leaving empty or broken-looking spaces.

❌ When Are Skeletons NOT Recommended?

When Data Is Not Actually Loading

Avoid using skeletons just for visual purposes. If there’s no real loading happening, then you don’t need them.

For Instant Loads

If the content appears immediately, adding a skeleton only adds unnecessary complexity and can even hurt the experience.

Very Simple Screens

On screens with minimal content, a skeleton might be overkill. A simple layout or even a simple loading indicator could be enough.

Meet the Telerik Skeleton

Did you know that Progress Telerik provides a Skeleton component for .NET MAUI? Oh yeahh!

Now that you’ve seen how powerful using one can be, let’s quickly go through how to implement it and highlight some of its most important benefits.

Before we dive in, let’s make sure your environment is ready. Just keep these two key points in mind:

• Create a Telerik account: If you don’t have a Telerik account yet, you can create one for free. You’ll get access to a trial license that allows you to explore not only the Skeleton component, but the full set of UI controls available for .NET MAUI.
• Install Telerik UI for .NET MAUI: This is a one-time setup, so you won’t need to repeat it for each component. If you haven’t installed it yet, I’ve included an article that walks you through the process step by step for both Visual Studio and Visual Studio Code.

Adding the Namespace

xmlns:telerik="http://schemas.telerik.com/2022/xaml/maui"

Registering the Component

Go to your MauiProgram.cs file and, inside the CreateMauiApp method, register the Telerik controls using the UseTelerik() extension method.

using Telerik.Maui.Controls.Compatibility;
public static class MauiProgram
{

    public static MauiApp CreateMauiApp()
    {
    var builder = MauiApp.CreateBuilder();
    builder
    .UseTelerik()
    .UseMauiApp<App>()
    .ConfigureFonts(fonts =>
    {
    fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
    });
    return builder.Build();
    
    }
}

How to Use It?

Using it is very simple. You just have to add a tag like the following:

<telerik:RadSkeleton x:Name="skeleton"/>

Skeleton Types in the Telerik UI for .NET MAUI Library

Typically, when creating a skeleton, you need to build the structure from scratch. However, the Telerik UI for .NET MAUI Skeleton component comes with predefined structures (anatomies), which helps you save both time and code. (Honestly, this is gold. A huge win!)

This control offers several built-in structures that you can use to represent different types of content:

➖ Article: Displays a layout with a small image placeholder on the left and multiple text lines on the right, simulating a title and description.

➖ Text: A simple text structure composed of multiple lines, typically used to represent titles and paragraphs.

➖ PersonalCircle: Shows a circular avatar placeholder with text lines next to it, commonly used for user profiles or list items with avatars.

➖ PersonaSquare: Similar to PersonaCircle, but uses a square (with rounded corners) instead of a circular avatar.

➖ Image: Represents a large media placeholder with a single text line below, ideal for image-focused layouts.

➖ Video: Simulates a video layout with a small avatar and text at the top, followed by a large media area and additional text lines below.

➖ Card: Displays a card-style layout with a title at the top, a large image placeholder and text lines at the bottom.

➖ ContentFeed: Mimics a feed-style layout with a header (avatar + one line), a large content block and text lines below, similar to social media posts.

The images of the Skeleton types were generated using AI for better understanding

To use any of these types, you just need to use the SkeletonType property as shown below:

<telerik:RadSkeleton SkeletonType="Article" />

Custom Skeleton View

But … what if you want to create your own skeleton anatomy?

You can do that too! Although the predefined types help you save time and effort, they don’t always fit your design. That’s why Progress Telerik allows you to create a fully custom one.

The idea is very simple: you define your own layout (just like your real UI, but without data) and assign it to the RadSkeleton using the LoadingViewTemplate property.

️ Implementation

First, define your RadSkeleton and assign a custom template to it:

    <telerik:RadSkeleton LoadingViewTemplate="{StaticResource CustomSkeletonView}"  
    Grid.Row="1" 
    x:Name="skeleton"> 
    
    <!-- Your real content goes here -->
    
    </telerik:RadSkeleton>

Then, create the DataTemplate that will represent your skeleton:

<DataTemplate x:Key="CustomSkeletonView">
<Grid RowDefinitions="40, 100, 200"
RowSpacing="10"
Padding="10">

    <HorizontalStackLayout Spacing="10">
    <BoxView WidthRequest="40" HeightRequest="40" CornerRadius="20"/>
    <BoxView WidthRequest="40" HeightRequest="40" CornerRadius="20"/>
    <BoxView WidthRequest="40" HeightRequest="40" CornerRadius="20"/>
    <BoxView WidthRequest="40" HeightRequest="40" CornerRadius="20"/>
    </HorizontalStackLayout>
    <BoxView WidthRequest="200"
    HeightRequest="100"
    HorizontalOptions="Start"
    Grid.Row="1"
    CornerRadius="12"/>
    
    <Grid Grid.Row="2"
    ColumnDefinitions="40, *"
    ColumnSpacing="10">
    <BoxView HeightRequest="40"
    WidthRequest="40"
    CornerRadius="20"
    Grid.Column="0"/>
    
    <VerticalStackLayout Spacing="10" Grid.Column="1">
    <BoxView HeightRequest="20" WidthRequest="120" CornerRadius="6"/>
    <BoxView HeightRequest="20" WidthRequest="180" CornerRadius="6"/>
    </VerticalStackLayout>
    </Grid>
</Grid>
</DataTemplate>

Done!!! We made it! Did you like it?

Conclusion

I hope this article helped you understand what a skeleton is and how it can improve the user experience in your .NET MAUI applications.

From understanding when to use it, to exploring the different types provided by Progress Telerik and finally implementing it in your UI, you’re now ready to apply this knowledge in your own apps. I invite you to explore more about the Telerik Skeleton for .NET MAUI in the following articles:

• https://www.telerik.com/maui-ui/skeleton
• https://www.telerik.com/maui-ui/documentation/controls/skeleton/overview

If you have any questions or would like me to dive deeper into a specific part, feel free to leave a comment, I’ll be happy to help!

See you in the next article! ‍♀️

Ready to Try Telerik UI for .NET MAUI?

Give the Skeleton component plus 70 other .NET MAUI components a try, free for 30 days.

Try Telerik UI for .NET MAUI

Do you ever argue about where to eat? If you’re like me, you can’t think of places half the time, and you just wish someone would pick for you. Well, here you go!

TL;DR

This app will create a random dinner picker from JSON data in Angular using Progress Kendo UI. You can choose from Takeout or Dine-in.

Setup

Create a new Angular app:

ng new angular-dinner-picker

Get a Kendo UI License

Log in to Progress and purchase a Kendo UI for Angular license, or try it for free.

Download the actual key, as you will need it later for deployment.

Install Kendo UI Licensing

npm i -S @progress/kendo-licensing

Then run:

npx kendo-ui-license activate

This will set up Kendo UI on your local machine for this project. Make sure you have a working license at this point, and to follow the correct setup.

Install Packages

ng add @progress/kendo-angular-buttons
ng add @progress/kendo-angular-dropdowns
ng add @progress/kendo-angular-layout

npm i -S npm install @angular/forms @progress/kendo-svg-icons @progress/kendo-theme-default

You may need to also install @angular/localize.

Install Tailwind

Make sure Angular is configured for Tailwind. Follow the Tailwind Guide.

Configure Styles

Make sure your styles are shown in styles.css correctly.

@import '@progress/kendo-theme-default/dist/default-main.css';
@import 'tailwindcss';

Picker Component

Generate a new picker component.

ng g c picker

Model

Create a model at picker.model.ts.

export type RestaurantMode = 'dine-in' | 'takeout';

export type Restaurant = {
  id: number;
  name: string;
  cuisine: string;
  mode: RestaurantMode;
};

export type RestaurantModeFilter = 'all' | RestaurantMode;

Data

You can declare your data in the restaurants.ts. You could obviously get more sophisticated and import data from a database if you like.

import { Restaurant } from "./picker.model";

export const restaurants: Restaurant[] = [
  {
    "id": 1,
    "name": "Monjunis",
    "cuisine": "Italian",
    "mode": "dine-in"
  },
  {
    "id": 2,
    "name": "Strawn's Eat Shop",
    "cuisine": "Southern Diner",
    "mode": "dine-in"
  },
  {
    "id": 3,
    "name": "Country Tavern",
    "cuisine": "BBQ",
    "mode": "dine-in"
  },
  
  ...
  
];

I used my city’s info so I can actually use the app! You can customize this and deploy it separately for different situations or cities!

Picker Class

Create the picker classes at picker.ts.

import { ChangeDetectionStrategy, Component } from '@angular/core';
import { FormsModule } from '@angular/forms';

import { ButtonsModule } from '@progress/kendo-angular-buttons';
import { DropDownsModule } from '@progress/kendo-angular-dropdowns';

import { restaurants } from './restaurants';
import { Restaurant, RestaurantModeFilter } from './picker.model';

type ModeOption = {
  label: string;
  value: RestaurantModeFilter;
};

@Component({
  selector: 'app-picker',
  standalone: true,
  imports: [
    FormsModule,
    ButtonsModule,
    DropDownsModule
  ],
  templateUrl: './picker.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class Picker {
  readonly restaurants = restaurants;

  readonly modeOptions: ModeOption[] = [
    {
      label: 'Any',
      value: 'all'
    },
    {
      label: 'Dine-in',
      value: 'dine-in'
    },
    {
      label: 'Takeout',
      value: 'takeout'
    }
  ];

  selectedMode: RestaurantModeFilter = 'all';
  selectedRestaurant: Restaurant | null = null;

  get filteredRestaurants(): Restaurant[] {
    if (this.selectedMode === 'all') {
      return this.restaurants;
    }

    return this.restaurants.filter((restaurant) => restaurant.mode === this.selectedMode);
  }

  pickRestaurant(): void {
    const choices = this.filteredRestaurants;

    if (choices.length === 0) {
      this.selectedRestaurant = null;
      return;
    }

    const pickableChoices =
      this.selectedRestaurant && choices.length > 1
        ? choices.filter((restaurant) => restaurant.id !== this.selectedRestaurant?.id)
        : choices;

    const index = Math.floor(Math.random() * pickableChoices.length);

    this.selectedRestaurant = pickableChoices[index];
  }
}

• Pick the restaurant with pickResaturant() function choosing a random JSON entry from the filtered results.
• We have any, dine-in and takeout.
• We will use the filtered results in the html template from filteredResautrants().

Picker Template

<main
  class="grid min-h-screen place-items-center bg-[radial-gradient(circle_at_top,rgba(255,255,255,0.95),rgba(255,255,255,0)_28%),linear-gradient(180deg,#f7efe7_0%,#eef2f7_100%)] p-4 sm:p-6">
  <section
    class="w-full max-w-sm rounded-4xl border border-slate-300/40 bg-white/92 px-6 py-7 shadow-[0_24px_60px_rgba(15,23,42,0.12)] backdrop-blur-[14px] sm:px-8 sm:py-8">
    <header class="space-y-3 text-center">
      <h1 class="m-0 text-[2.05rem] font-semibold leading-[0.98] tracking-tight text-slate-800 sm:text-[2.3rem]">
        Restaurant Picker
      </h1>

      <p class="mx-auto max-w-64 text-[1rem] leading-7 text-slate-500">
        Pick where to eat without thinking about it.
      </p>
    </header>

    <div class="my-6 h-px bg-slate-200/80"></div>

    <div class="space-y-6">
      <div class="space-y-3 text-center">
        <label for="mode" class="block text-[1.15rem] font-semibold leading-tight text-slate-800">
          What kind?
        </label>

        <kendo-dropdownlist id="mode" class="w-full text-left" [data]="modeOptions" textField="label" valueField="value"
          [valuePrimitive]="true" [(ngModel)]="selectedMode" />
      </div>

      <button kendoButton class="min-h-14 w-full text-base font-semibold" themeColor="primary" size="large"
        rounded="large" [disabled]="filteredRestaurants.length === 0" (click)="pickRestaurant()">
        Pick Restaurant
      </button>

      @if (selectedRestaurant) {
      <section
        class="rounded-[1.75rem] border border-rose-200/80 bg-[linear-gradient(135deg,rgba(255,241,242,0.92),rgba(255,255,255,0.98))] px-6 py-6 shadow-[inset_0_1px_0_rgba(255,255,255,0.7)]"
        aria-live="polite">
        <div class="grid justify-items-center gap-4 text-center">
          <p class="m-0 text-[0.78rem] font-bold uppercase tracking-[0.2em] text-rose-700">Tonight's pick</p>

          <h2
            class="m-0 max-w-[11ch] text-[clamp(1.7rem,4vw,2rem)] font-semibold leading-[1.08] tracking-tight text-slate-900 text-balance">
            {{ selectedRestaurant.name }}
          </h2>

          <div class="grid justify-items-center gap-3">
            <p class="m-0 text-[1rem] leading-6 text-slate-700">
              {{ selectedRestaurant.cuisine }}
            </p>

            <span
              class="inline-flex min-h-10 items-center justify-center rounded-full border border-slate-300/40 bg-white/90 px-5 text-sm font-bold text-slate-900 shadow-[0_6px_18px_rgba(15,23,42,0.06)]">
              {{ selectedRestaurant.mode === 'dine-in' ? 'Dine-in' : 'Takeout' }}
            </span>
          </div>
        </div>
      </section>
      } @else {
      <div
        class="rounded-[1.75rem] border border-dashed border-slate-400/60 bg-slate-50/75 px-5 py-6 text-center text-[0.95rem] leading-6 text-slate-500">
        @if (filteredRestaurants.length === 0) {
        No restaurants found for this option.
        } @else {
        Click the button to pick a restaurant.
        }
      </div>
      }

      <p class="text-center text-[0.82rem] font-semibold text-slate-500">
        {{ filteredRestaurants.length }}
        restaurant{{ filteredRestaurants.length === 1 ? '' : 's' }} available
      </p>
    </div>
  </section>
</main>

Here’s what’s going on above:

• When we run pickRestaurant(), the app displays the filtered items as a signal.
• The kendo-dropdownlist component uses data field for options with label and value matching the drop down.
• We just add kendoButton to our button component to get the look we want. We can use Tailwind with the look!

And it’s that simple!

Repo: GitHub
Demo: Vercel Serverless

You can try all of this yourself with the Kendo UI for Angular trial, free for 30 days.

Try Now

AI tools are strongest when they integrate into the rest of a user’s workflow—referencing internal documents, sending emails, making calendar appointments, drafting and sharing content with coworkers, so on and so forth.

However, most users won’t integrate what they can’t see and understand. If the AI applications we build are going to become part of their daily lives, users need transparency into exactly what they do, what data they have access to and what it will cost them (in both time and money).

The more transparent we can make these features, the less hesitation our users will have adopting them.

UX Pattern: Permissions

The concept of asking for user permissions is certainly not AI-specific, but the stakes can feel a lot higher when you’re asking users for permission to allow AI to act on their behalf.

We need to make it easy for users to see which applications we’ve allowed our tool to access and in what ways, keeping in mind that permissions are often more than just “yes” or “no.”

Can your agent just reference data from this database, or is it allowed to delete tables? Can it only read a user’s emails, or is it allowed to send from their address as well? Can it run scripts? Search local files? Each one of these actions requires direct user sign-off.

Permissions are also not a one-and-done situation. A user might feel comfortable allowing an action to happen once under their direct supervision, but don’t want to allow it permanently. They might give access to a specific folder, but not every folder. They might approve an action, but want to be notified each time it’s taken. Consider what gray zones might exist in your permission structure, and try to accommodate as many options as you can.

Another common sticking point with AI is data collection. Often, it can be helpful to save information from past interactions, but storing this kind of data requires real attention to user permission and data management.

If you want to create a system that can “remember” things, you also need to make sure it can “forget” as well—and that the user can not only see but has final say in what exactly what gets remembered. An ideal permissions flow will not only ask for a user’s approval in the moment, but also create a space where they can see the history of what they’ve given access to and when—and allow them to revoke that access or permission at any time.

UX Pattern: Estimates and Confirmation

This one is pretty simple, so we won’t spend too much time on it, but another crucial aspect of transparency is making sure users know exactly what they’re committing to when they approve an action request. In addition to approving the actual steps and plan (as we discussed earlier in the Trust post), they also need to know how much time it’s going to take and what it will cost them in money or tokens.

Even if we can’t specify an exact amount, providing rough estimates generally gives users enough information to work with—and to potentially revise their request if it’s going to exceed what they’re comfortable with.

UX Pattern: Solo Execution Indicator

Similarly to the marking that denotes which content was AI-generated, it’s also a good idea to have some kind of visual signal for when an AI tool is acting independently. If, for example, you’re going to allow an agent to take control of the user’s browser, then there needs to be a banner, sidebar, outline or some other kind of indication that the user is no longer driving the interaction.

Not only is this a good thing to do just for transparency—so the user understands the current state of the system—but also so they don’t unintentionally interrupt or confuse an ongoing process. It’s an especially important consideration for processes that you know will take an extended period of time, where the user may step away and come back without keeping track of everything that’s happened while they were gone.

Read next: AI UX Patterns to Show Meaningful User Benefit

AI stopped being “the thing that writes your code” a while ago. At this point, it’s showing up at nearly every stage of the job: helping you build the app, automate the parts nobody wants to do by hand and keep an eye on how AI-powered features actually behave once real users touch them.

This month’s updates across Progress Telerik, Kendo UI, Telerik Reporting, Fiddler and Progress AI Observability are a good snapshot of that shift. Here’s what’s new and, more importantly, what it actually lets you do.

But before that … We’re walking through everything below on Progress AI Monthly: Telerik, Kendo UI & More livestream on August 28, 9 a.m. ET. No sign-up, just show up.

YouTube · LinkedIn · Twitch

Build

More AI, Fewer Tokens

Before getting to what’s new, a word on what’s gotten leaner: token consumption is down by up to 45% across our .NET products, with better output quality on top of that, so the same prompt now costs you less and gets you more. Alongside that, the Agentic UI Generator for Telerik UI for Blazor, KendoReact and Kendo UI for Angular is now available as an agent-native skill instead of an externally configured tool, which makes it noticeably easier to deploy in air-gapped and regulated environments.

See the MCP servers page.

Build UI with a Prompt

The Agentic UI Generator now supports Telerik UI for ASP.NET Core. Describe what you need in plain language, and it generates real, framework-aware code that follows the patterns you’d already be using: grids, forms, navigation, layout, the works. That means less time assembling scaffolding and more time on the parts of the app that actually need your judgment.

A few things people are already using it for: business applications, admin portals, customer-facing dashboards, analytics views and data-driven workflows.

See how the ASP.NET Core UI Generator works.

Build Reports with Natural Language

The Telerik Reporting AI Report Generator has already been generating charts and gauges from a plain description of what you want to see. Now that same idea extends to structured report content: tables, lists, crosstabs, summary rows, headers and footers, and grouped structures.

Describe the table you need. For instance, grouped by region, with subtotals. And the Generator builds it, then hands you a preview to check before anything actually lands in the report.

Explore AI-Generated Tables, Lists and Crosstabs.

Build Faster with New Components

Not every update this month is AI-flavored. Some of it is just useful, new UI:

• Telerik UI for Blazor: Expansion Panel
• KendoReact: OTP Input
• Kendo UI for Vue: Barcode, PDF Viewer
• Telerik UI for .NET MAUI: Charts (Preview), Circular Slider
• Telerik UI for WPF: Smart Paste Button, Inline AI Assistant
• Telerik UI for WinForms: Smart Paste Button

Build AI-ready Experiences with the LLM Kit

The LLM Kit isn’t just something you bolt on after the fact to keep tabs on your agents. It’s a set of components for building the AI-powered experience itself. Chat-style interfaces, multi-step agent workflows, tool-call displays, approval steps, citations, checkpoints: the pieces you’d otherwise have to design and build from scratch are already there, ready to wire into your app.

It gives you a real head start on shipping AI features that feel considered rather than bolted on, and, as a side benefit, your users and your team can actually see what the AI is doing along the way.

It’s available now for Telerik UI for Blazor, UI for ASP.NET Core, UI for MVC, Kendo UI for Angular, UI for jQuery and KendoReact.

Automate

Automate Application Upgrades

Nobody enjoys upgrading a codebase, and it’s rarely the highest-value use of anyone’s afternoon. AI-assisted migration is now available for Telerik UI for ASP.NET Core, UI for MVC, UI for WPF, KendoReact and Kendo UI for jQuery through the Upgrade Assistant (part of the MCP engine). It handles the changes it already knows how to make on its own and walks you through the ones that need a human decision, so version bumps stop eating whole sprints.

Automate Reporting Operations with AI Agents

Telerik Report Server now ships with a native MCP Server, so assistants like Copilot, Claude, Cursor and Codex can work directly inside your reporting environment instead of going through a custom integration you’d have to build and maintain. Once you’ve set up a Personal Access Token, agents can:

• Generate reports
• Manage data sources
• Schedule reports
• Handle general reporting-environment admin

See Report Server MCP docs.

Automate Debugging with Fiddler MCP

Debugging gets a lot more useful when your AI assistant can see what actually happened over the wire, not just what the code says should happen. Fiddler MCP connects your coding assistant to real traffic captured in Fiddler Everywhere, actual requests, responses, headers, status codes, so it’s reasoning from evidence instead of guessing. Set it up with one click inside Fiddler Everywhere, then go from “something’s broken” to a fix without leaving your IDE.

Explore Fiddler Everywhere MCP.

Automate Licensing for CI/CD

Automation isn’t only about what your agents do. It’s also about what shouldn’t need a human to manage. Deployment Keys give you a dedicated way to license automated builds and deployments: each key ties to a registered application and the exact Telerik or Kendo products it uses, so tracking, monitoring and reporting on product usage across your CI/CD environments gets a lot less manual.

Observe

Building faster and automating more only gets you so far if you can’t tell what your AI systems are actually doing once they’re live. That’s the part teams tend to underinvest in until something goes wrong.

Learn Why AI Observability Matters

If you want to go deeper on this, join Jeff Fritz and Progress Product Manager Lyubomir Atanasov on August 26 for “AI Observability: When AI Goes Off the Rails.” They’ll walk through some genuinely memorable public AI failures, then run a live Progress AI Observability demo covering agent tracing, drift and hallucination detection, and performance and cost monitoring.

Register for the webinar.

Help Shape the Future of Agentic Development

This is also the thinking behind the Progress Agent Harness Early Access Program: structured, auditable AI workflows, with early adopters getting a direct line to the roadmap. As agents take on more, being able to manage them predictably matters just as much as what they can build.

Join the Agent Harness EAP.

What’s New and Release History

To see everything that’ is new in August 2026 release edition, visit the What’s New in Telerik and Kendo UI page. For a deeper dive into each product, follow the links below.

TL;DR

If your AI trace doesn’t explain decisions, it’s just noise. A span that says your LLM call succeeded in 1.3 seconds confirms the infrastructure worked, but it says nothing about what the model received, what it returned, what tools it called, what that cost or whether the output was correct. Useful AI traces contain the prompt sent, the completion returned, every tool invocation with its inputs and outputs, token counts, estimated cost and a quality signal.

If you’re new to the topic, start with The Six Questions Every AI Trace Should Be Able to Answer for the conceptual foundation. This post picks up where that one leaves off.

This post is an implementation walk-through: it shows how to produce those six trace elements using the Progress AI Observability Platform Python SDK (progress-observability), with the architecture choices and tradeoffs you’d want in production. The platform also supports .NET and JavaScript/TypeScript—see telerik.com/ai-observability-platform—free to start, 5-minute setup.

Problem Statement

Picture this: your dashboard shows HTTP 200, p95 latency looks normal, error rate is zero. Your agent ran 4,000 times this morning. Then a customer emails saying it gave them completely wrong product information. Where do you even start?

When something goes wrong with an AI agent, you need to answer six questions fast. The previous post covers what those questions are and why standard observability can’t address them. Briefly: what context did the agent have, what did tools return, what did the model receive, what did it produce, what did it cost and was the output good.

Standard OpenTelemetry answers none of these. It captures span timing, parent-child relationships and error codes—necessary, but not sufficient for debugging agent behavior.

The gap is significant. A request can return HTTP 200, produce no errors and still have:

• Hallucinated a fact that isn’t in the context
• Called a tool with an argument that returned stale data
• Consumed 10 times the expected tokens due to an oversized system prompt
• Produced a response that passes format validation but fails on quality

Without AI-specific context baked into the trace, every one of these failures is invisible until a user reports it.

This post covers trace design—what to put into a trace and how to instrument it. For a deep dive on detecting agents that silently return wrong answers despite showing HTTP 200, see When Status OK Is Still a Failure. For tracking and optimizing token spend, see AI Cost Visibility Before the Invoice.

Architecture Overview

The Progress Observability Platform sits between your application code and the observability backend. It uses standard OpenTelemetry plumbing but enriches spans at the collector level with AI-specific data: cost calculations, token attribution and tag enrichment.

flowchart LR  
App["Your App\n(Python + SDK)"] -->|"OTel spans\n(OTLP/gRPC)"| Collector["Progress Collector\n(Auth + Cost enrichment)"]  
Collector -->|enriched spans| Backend["Platform Backend\n(Storage + Processing)"]  
Backend --> Dashboard["Platform Dashboard\n(Observations, Costs, Scores)"]

The SDK handles auto-instrumentation. Once initialized, it patches supported libraries—OpenAI, LangChain, Anthropic, LlamaIndex and others—so every LLM call and framework operation creates a span automatically. You don’t touch your LLM client code.

Cost calculation happens in the collector, not in your application. This matters more than it sounds: model providers change pricing with a blog post and a short notice period. If cost logic lives in your app, that’s a code change, a PR, a deploy and potentially a rollout across multiple services. If it lives in the collector, it’s a configuration update in one place.

Trace Hygiene vs. Trace Volume

The AI observability community has a specific name for the gap between having many spans and having useful ones: the trace noise problem.

Standard OpenTelemetry auto-instrumentation was designed to instrument everything. In practice, that means LLM calls appear alongside HTTP client requests, authentication flows, database queries and framework internals. That’s all technically valid telemetry, but none of it is useful when you need to understand why an agent produced a wrong answer.

This shows up repeatedly across AI observability tooling: a single agent trace can contain the real LangChain or LLM spans right next to Microsoft Graph authentication calls, generic HTTP events and other infrastructure telemetry because OTel does not distinguish AI-relevant spans from infrastructure spans by default. The usual fix is some combination of instrumentation-scope blocklists, span filters or name-based selection, but that filtering surface tends to expand as more libraries get added. Across the market, vendors have added span kind filters, annotation-based filtering, name-based span selection and similar narrowing controls precisely because isolating relevant spans from a noisy store is an ongoing operational challenge.

Trace volume is easy to produce. Trace hygiene—capturing the right signals, in the right structure, with the right context—requires deliberate design.

As the companion awareness piece The Six Questions Every AI Trace Should Be Able to Answer describes, trace hygiene rests on five implementation principles: Scope (instrument AI operations, not all infrastructure), Structure (spans that reflect agent logic), Content (prompt and completion text captured), Attribution (tags for filtering) and Quality (evaluation scores tied to traces). The four steps below implement those principles in practice—each one closes a gap that a timing-only OTel span leaves open.

Implementation Walk-through

Step 1: Install and Initialize

pip install progress-observability

Initialize once at the very start of your process, before importing LLM libraries. The SDK patches libraries at initialization time. If you import openai first, those calls won’t be traced.

import os  
from progress.observability import Observability  
  
Observability.instrument(  
  app_name="support-agent",  
  api_key=os.environ["OBSERVABILITY_API_KEY"],  
  trace_content=True, # captures actual prompt and   completion text  
)

trace_content=True is the most important configuration choice here. Without it, you get timing spans with no content—which is fine for production environments with PII concerns, but makes debugging nearly impossible. Use environment variables to toggle this per deployment.

Step 2: Tag Your Traces

Tags let you filter observations in the platform by environment, team, experiment or any dimension that matters. Set global tags at initialization:

Observability.instrument(  
  app_name="support-agent",  
  api_key=os.environ["OBSERVABILITY_API_KEY"],  
  trace_content=True,  
  additional_tags=[  
    "environment:staging",  
    "team:support",  
    "release:2.4.1",  
  ],  
)

For tags that vary per request—tenant ID, experiment variant—use propagate_attributes to scope them to a specific block of code:

from progress.observability import propagate_attributes  
  
async  def handle_request(user_message: str, tenant_id: str):  
  with propagate_attributes(tags=[f"tenant:{tenant_id}", "experiment-prompt-v3"]):  
    # Every span created inside this block inherits these tags
    result =  await run_agent(user_message)  
  return result

Tags from propagate_attributes merge with global tags and are deduplicated automatically. Nesting is supported—tags accumulate from outer to inner context managers.

The practical payoff: when a customer reports an issue, filter by tenant:acme-corp combined with release:2.4.1 and you’ve narrowed a million traces down to the 20that matter.

Step 3: Decorate Your Agent Structure

Auto-instrumentation captures LLM calls, but it doesn’t know your agent’s structure. Without decorators, the trace shows a flat list of LLM calls with no context about which workflow triggered them or why a particular tool was invoked.

The SDK provides four decorator types:

Here’s a complete instrumented agent:

from progress.observability import agent, workflow, tool, taskfrom openai import AsyncOpenAI  
import os  
  
client = AsyncOpenAI()  
  
@task(name="retrieve-context", attributes={"source": "vector-db"})  
async  def retrieve_relevant_docs(query: str) ->  list[str]:  
  """Retrieves relevant documents — span captures latency and custom attributes."""
  results =  await vector_db.search(query, top_k=5)  
  return [r.text for r in results]  
  
@tool(name="fetch-product-info")  
async  def fetch_product(product_id: str) ->  dict:  
  """Tool span captures the product_id input and the dict return value."""  
  return  await product_service.get(product_id)  
  
@workflow(name="answer-product-question", version=2)  
async  def answer_question(user_query: str, product_id: str) ->  str:
  context =  await retrieve_relevant_docs(user_query)
  product =  await fetch_product(product_id)
  context_text =  "\n".join(context)
  messages = [  
    {"role": "system", "content": "You are a helpful product support agent."},  
    {  
      "role": "user",  
      "content": f"Context:\n{context_text}\n\nProduct: {product}\n\nQuestion: {user_query}",  
    },  
  ]  
  
  # Auto-instrumented: span captures model, messages, completion, token counts
  response =  await client.chat.completions.create(  
    model="gpt-4.1-mini",  
    messages=messages,  
  )  
  return response.choices[0].message.content  
  
@agent(name="product-support-agent")  
async  def handle_request(user_message: str, tenant_id: str) ->  str:  
  with propagate_attributes(tags=[f"tenant:{tenant_id}"]):
    product_id = extract_product_id(user_message)  
    return  await answer_question(user_query=user_message, product_id=product_id)

In the platform, this renders as:

agent: product-support-agent  
└── workflow: answer-product-question (v2)  
  ├── task: retrieve-context [source: vector-db]  
  ├── tool: fetch-product-info [input: product_id, output: {...}]  
  └── llm: gpt-4.1-mini [tokens: 847, cost: $0.00042]

That single view replaced hours of log grepping. Without the decorators, this same run would show a flat list of anonymous llm: gpt-4.1-mini spans with no structural context—no way to tell which call is the retrieval prompt and which is the final answer generation. You’d count spans and guess.

Step 4: Shut Down Cleanly

Always flush pending telemetry before the process exits. Without this, buffered spans are lost—especially in scripts, short-lived containers and serverless functions.

import asyncio  
from progress.observability import Observability  
  
async  def main():  
  try:  
    await handle_request(  
      user_message="What's the return policy for order #12345?",  
      tenant_id="acme-corp",  
    )  
  finally:  
    Observability.shutdown()  
  
asyncio.run(main())

In long-running services, hook Observability.shutdown() into your SIGTERM handler or application lifecycle teardown, not into individual request handlers.

Common Pitfalls

Initializing After LLM Imports

This is the most common mistake, and the most disorienting to debug. Your agent runs, returns results, no exceptions anywhere. And zero traces appear in the platform. Not errors, not partial traces: silence.

The SDK patches libraries at the time Observability.instrument() is called. Any library imported before that call won’t be patched.

# Wrong — openai is imported before instrumentation  
import openai  
from progress.observability import Observability  
Observability.instrument(...)  
  
# Correct — instrumentation first  
from progress.observability import Observability  
Observability.instrument(...)  
import openai

Disabling trace_content Globally

Setting trace_content=False everywhere eliminates your ability to debug output quality issues. Use the OBSERVABILITY_TRACE_CONTENT environment variable to control this per deployment without changing code.

# .env.production  
OBSERVABILITY_TRACE_CONTENT=false  
  
# .env.staging  
OBSERVABILITY_TRACE_CONTENT=true

Skipping Decorators

Auto-instrumentation alone gives you a flat trace of LLM calls. Decorators give you structure. Without them, a three-step agent looks like this in the platform:

llm: gpt-4.1-mini [tokens: 312]  
llm: gpt-4.1-mini [tokens: 847]  
llm: gpt-4.1-mini [tokens: 203]

No workflow context, no tool inputs, no parent-child relationships. You’re left counting spans and guessing which one is the retrieval call and which is the final answer.

Missing the Shutdown Call

Short-lived scripts that don’t call Observability.shutdown() frequently lose the last batch of spans. This makes traces appear truncated or missing in the platform. In AWS Lambda and other serverless runtimes, the environment can be frozen or terminated between invocations before the buffer flushes—which means you often lose the most recent trace completely, exactly when you’re trying to debug a one-off failure.

Tradeoffs

Starting fresh? Default to trace_content=True in staging, propagate_attributes for anything multi-tenant and full decorator coverage from day one. These are easy to set up upfront and painful to retrofit when you’re trying to debug something at 2 a.m.

Next Steps

1. Clone the demo first: NickIliev/support-agent-demo is a fully runnable version of the agent from this post. Add your API keys to .env and run python support_agent.py. All six trace elements will appear in your dashboard immediately. This is the fastest way to see a complete, well-instrumented trace before building your own.

2. Instrument one agent: pip install progress-observability, add Observability.instrument() with trace_content=True, apply the decorators from Step 3. You’ll have a working trace in under 15 minutes.

3. Open the Observations view and inspect the span tree. Filter by a tag, drill into a span, verify the exact prompt the model received.

4. Set up one evaluation task to start tracking output quality automatically.

5. Want a guided path from zero? Work through the Log Your First AI Trace quickstart (coming soon) for a structured first-trace experience in 10–15 minutes. In the meantime, the getting started guide covers the same ground—free to start, 5-minute setup.

AI Observability Reading Path

1. The Six Questions Every AI Trace Should Be Able to Answer – Awareness: why AI traces need more than infrastructure observability
2. You are here: What a Useful AI Trace Should Actually Contain (And How to Build One)
3. NickIliev/support-agent-demo – Hands-on demo on GitHub

Blazor has become a serious platform for building modern web applications with .NET. As the framework has matured, commercial UI component libraries have become an important part of the Blazor development experience.

Instead of building every Grid, Chart, Scheduler, Form, Editor, and navigation component from scratch, teams can rely on mature component suites to accelerate development, improve UI quality and reduce long-term maintenance effort. Two of the most common options for Blazor development are Progress Telerik UI for Blazor and Syncfusion Blazor.

Both are mature. Both provide large component collections, commercial support, documentation, examples and tooling for .NET developers. Both can be used to build complex business applications.

The decision is rarely about whether one product is objectively “better.” A more useful question is: “Which library better matches the way your team builds, maintains, upgrades and scales Blazor applications over time?”

At a high level, Syncfusion Blazor is attractive for teams that want a very broad component catalog, access to many specialized controls and a Community License for qualifying users. Telerik UI for Blazor is a strong fit for teams that value a cohesive developer experience, predictable APIs, strong theming workflows, product polish, support reputation and long-term maintainability.

This comparison looks at both products through practical evaluation criteria: onboarding, component coverage, grid capabilities, theming, accessibility, performance, support, AI readiness and long-term project fit.

Quick Decision Summary

Choose Telerik UI for Blazor if…

• You are building a long-lived application that will be maintained for several years.
• Multiple developers or product teams will contribute to the same UI codebase.
• You value predictable APIs and standardized implementation patterns.
• You need strong theming, design-token management or designer-developer collaboration.
• You care about upgrade experience, support quality and long-term maintainability.
• You want a component suite that is easy for both developers and AI coding assistants to reason about.

Key Differences at a Glance

What Most Teams Eventually Optimize For

When teams first compare component libraries, they usually start with feature lists.

That makes sense. Component count, available controls, Grid features, Scheduler options, chart types, templates, exporting and documentation examples are easy to compare.

But once a Blazor application moves into production, different questions become more important:

• How easy is the application to maintain?
• Can new developers understand the UI code quickly?
• Are component APIs predictable?
• How painful are upgrades?
• Can we apply the same branding across multiple applications?
• Can designers and developers work from the same design system?
• How reliable is support when something breaks?
• Can AI coding assistants generate correct and maintainable UI code?

This is where the distinction between breadth and cohesion matters.

Syncfusion has a strong case when a team wants access to a broad collection of components, related document libraries and specialized controls. Telerik has a very strong case when a team wants a more unified development model, mature theming workflows and a polished component experience across the core UI scenarios that most business applications depend on.

Neither priority is wrong. The better choice depends on what your team values most.

Time to First Value

Feature comparisons are useful, but the first developer experience is usually more practical:

• How do I install the package?
• How do I configure licensing?
• How do I set up NuGet access?
• How do I create the first Blazor project?
• How quickly can I render a real component?
• How many manual steps are required before I can start evaluating the library?

This is where time to first value becomes important.

Time to First Value: Telerik UI for Blazor

Telerik puts a strong emphasis on guided onboarding. The product experience includes getting-started documentation, templates, licensing guidance, CLI-based workflows and integration with Telerik tooling.

Telerik focuses heavily on onboarding and guided setup, and this includes:

• Structured getting-started documentation
• Starter project guidance
• Project templates and configuration assistance
• Consistent setup patterns across components

The Telerik CLI can help reduce setup friction by assisting with project creation, package configuration, licensing-related setup, templates and related tooling.

This matters because early evaluation is not only about installing a NuGet package. It is about reducing the number of small setup decisions that slow teams down before they can assess the actual components.

The setup becomes as simple as:

For larger teams, this kind of guided setup can be useful because new developers do not need to rediscover the same configuration steps independently.

Time to First Value: Syncfusion Blazor

Syncfusion also has a strong onboarding story. Its ecosystem includes product documentation, sample applications and a large collection of examples. The Syncfusion Blazor samples repository describes demos for Blazor Server and Blazor WebAssembly apps, including project files targeting modern .NET versions.

That breadth of examples can be valuable when a developer is looking for a specific scenario or specialized component behavior.

Time-to-First-Value Takeaway

For a small proof of concept, both products can get developers started quickly.

The advantage of Telerik UI is more about guided setup and a cohesive path from installation to production-style usage. Syncfusion’s advantage is the large ecosystem of samples.

Component Coverage

Component count is one of the most visible comparison points.

Syncfusion Blazor is known for broad component coverage. Its Community License page describes access to 145+ Blazor components for eligible users and organizations. Syncfusion’s broader product line also includes UI components, document SDKs and standalone UI SDKs under the Community License description.

That breadth is a legitimate advantage. Teams that need niche controls, document processing capabilities, PDF-related libraries, Office document support or specialized UI scenarios may find Syncfusion difficult to overlook.

Telerik UI for Blazor takes a somewhat different approach. It provides a large suite of core Blazor components, but its strongest value proposition is not simply the number of controls. Telerik UI is strongest when the application depends heavily on polished core components such as Grid, Charts, Scheduler, Forms, Inputs, Editors, Layout, Navigation, Upload and theming.

For many business applications, both libraries cover the essential requirements. The practical difference is often not “Does a component exist?” but:

• How predictable is it to configure?
• Does it follow familiar patterns from other components in the same suite?
• Does documentation match real development scenarios?
• Is the component easy to theme and maintain?
• Does it fit into a shared UI platform?

Component Coverage Takeaway

Syncfusion has the advantage in overall breadth and specialized coverage.

Telerik has the advantage when teams want a cohesive suite focused on core business application scenarios, polished UI behavior and maintainable implementation patterns.

The Grid: The Component That Often Decides the Evaluation

If one component influences UI library decisions more than any other, it is usually the grid.

Business applications spend a large amount of time displaying, filtering, grouping, sorting, editing, exporting and analyzing data. For many teams, the grid is not just one component. It is the center of the application.

Both Telerik UI for Blazor and Syncfusion Blazor provide capable Grid components with support for common business scenarios such as:

• Sorting
• Filtering
• Grouping
• Paging
• Virtualization
• Inline editing
• Batch editing
• Templates
• Aggregates
• Exporting
• Hierarchical data
• Large dataset scenarios

Both vendors can support serious data-heavy applications. In practice, grid performance depends not only on the component itself but also on data access strategy, rendering mode, server communication, virtualization configuration and application architecture.

Telerik UI for Blazor Grid

The Telerik UI for Blazor Grid is strongest when teams care about a polished and predictable implementation model.

The main advantages are not only feature availability, but how the Grid fits into the broader development experience:

• Predictable configuration patterns
• Strong template support
• Familiar event and data-binding approaches
• Alignment with the rest of the Telerik component suite
• Accessibility-specific documentation
• A mature experience for common business data scenarios

Telerik Grid accessibility is WCAG 2.2 AA and Section 508 compliant, follows WAI-ARIA best practices for keyboard navigation and is tested with popular screen readers. That is a concrete point worth considering for teams building applications with formal accessibility requirements.

Syncfusion Blazor Grid

The Syncfusion Grid is also highly capable and has a broad feature surface. It is particularly attractive when teams need extensive configuration options or specialized behaviors.

Syncfusion’s Grid supports accessibility standards including ADA, Section 508, WCAG 2.2 and ARIA roles, with details on screen reader support, RTL support, color contrast, mobile device support, keyboard navigation and Axe-core validation.

Grid Takeaway

Both Grids are mature and capable.

Syncfusion’s Grid stands out for broad functionality and configurability. The Telerik Grid stands out for a polished developer experience, accessibility documentation and a usage model that tends to fit well into long-lived applications with multiple contributors.

If your evaluation is based on a specific Grid feature, test that feature in both products. If your evaluation is based on long-term maintainability, onboarding, accessibility and shared implementation patterns, Telerik deserves stronger consideration.

Scheduler, Charts and Dashboards

After the Grid, Scheduler and Charts are often among the most important components in business applications.

Scheduler

Both Telerik and Syncfusion support common scheduling scenarios such as:

• Day, week and month views
• Recurring events
• Resource grouping
• Drag-and-drop editing
• Custom templates
• Business calendar scenarios

Syncfusion is attractive when the team wants broad scenario coverage and many examples.

Telerik is attractive when the Blazor Scheduler needs to feel like part of the same UI platform as the Grid, Forms, Inputs, Dialogs, Charts and navigation components.

Charts and Dashboards

Both libraries provide charting capabilities suitable for dashboards, reporting UIs, KPI tracking, analytics screens and business intelligence-style interfaces.

The distinction is less about whether common chart types exist and more about the surrounding workflow:

• How easily can charts be themed?
• Can they follow the same visual system as the rest of the app?
• Can multiple teams reuse the same design language?
• Can dashboard screens stay visually aligned over time?

This is where the Telerik theming story becomes especially relevant.

Theming and Design-System Governance

Theming is often underestimated during evaluations.

At the start of a project, teams usually focus on functionality. Later, especially in long-lived applications, theming becomes a product and architecture concern.

Questions start to appear:

• Can we align components with our brand?
• Can designers and developers collaborate without translating everything manually?
• Can we reuse themes across multiple applications?
• Can we manage design tokens centrally?
• Can we support light and dark modes?
• Can we avoid one-off CSS overrides that become hard to maintain?
• Can we update the visual language without rewriting large parts of the UI?

This is one of Progress Telerik UI’s clearest differentiators.

Progress Telerik ThemeBuilder

Progress Telerik ThemeBuilder is a SaaS tool that enables teams to create custom themes and preview how they affect component appearance. It can generate a CSS file that can be used in a Blazor app instead of a built-in theme.

ThemeBuilder also supports capabilities that matter in design-system driven organizations, including:

• Atomic customization
• CSS/SASS variables
• Custom HTML support
• Figma integration
• Theme modes and built-in themes
• Custom fonts and iconography
• Project sharing
• Version control
• Collaboration and user access rights

This is more than visual customization. It helps teams create a shared styling workflow between design and engineering.

For organizations with multiple product teams, this can reduce duplicated CSS work, prevent visual drift between applications and make brand updates easier to manage.

Syncfusion Customization

Syncfusion also provides styling and customization options. For many teams, those capabilities will be enough.

However, if centralized design-system governance is a major requirement, Progress Telerik ThemeBuilder gives it a particularly strong position.

Theming Takeaway

Both libraries can be customized.

Telerik has a clearer advantage when teams need design tokens, Figma-related workflows, centralized branding, visual governance and reusable themes across multiple applications.

Blazor App Accessibility

Accessibility should be part of any serious UI library evaluation.

Teams building applications for public sector, healthcare, finance, education, government or large internal platforms often need to consider:

• WCAG
• Section 508
• Keyboard navigation
• Screen reader support
• WAI-ARIA roles and attributes
• Color contrast
• Accessible interaction alternatives
• Accessibility conformance documentation

Telerik Accessibility

Telerik UI for Blazor provides an accessibility compliance table that lists WCAG 2.2 compliance levels for individual components. Progress Telerik also provides an Accessibility Conformance Report through VPAT.

For the Grid specifically, Telerik documents WCAG 2.2 AA and Section 508 compliance, WAI-ARIA best practices, keyboard navigation, and screen reader testing.

Syncfusion Accessibility

Syncfusion documents accessibility support for Blazor components, including WAI-ARIA, WCAG 2.2, Section 508, keyboard navigation, screen reader support, RTL support and color contrast considerations.

Syncfusion’s DataGrid accessibility documentation also provides a detailed view of supported standards and limitations for complex interactions.

Accessibility Takeaway

Both vendors take accessibility seriously and provide documentation around standards and component behavior.

The Telerik component-level compliance table and documented Grid compliance are helpful for teams that need formal accessibility evidence. Syncfusion also provides broad accessibility documentation, including detailed DataGrid accessibility coverage.

For accessibility-sensitive applications, the best approach is to test the exact components and configurations your application will use.

Support, Documentation and Learning Resources

Support quality is hard to capture in a comparison table, but it often becomes critical after adoption.

During a trial, teams should evaluate:

• How quickly developers find answers in documentation
• Whether examples match real scenarios
• How clear upgrade notes are
• How support handles complex issues
• Whether feedback and bug reports are visible
• Whether the vendor provides practical guidance beyond simple demos

Telerik UI for Blazor Support

Progress Telerik has a long-standing reputation in the ecosystem for polished components, detailed documentation, active forums, feedback channels and strong support. That reputation is one of the reasons Telerik UI is often favored by teams building long-lived applications.

This should still be validated during evaluation. The best support test is not reading a marketing page. It is submitting realistic trial questions and measuring how useful the answers are.

Syncfusion Blazor Support

Syncfusion also provides commercial support, documentation, samples and a large knowledge base. Its broad ecosystem can be helpful when developers are searching for examples across many controls and scenarios.

Syncfusion’s large sample repository is especially useful when teams want to inspect working examples and compare usage across components.

Support Takeaway

Both vendors provide serious support and learning resources.

Telerik UI is often especially attractive for teams that prioritize product polish, support confidence and long-term UI quality. Syncfusion is strong for teams that value broad documentation coverage, many samples and a large ecosystem.

Product Quality, Stability and Upgrade Experience

Product quality is more than whether a component works in a demo.

For long-lived applications, quality usually means:

• Stable APIs
• Clear documentation
• Predictable behavior
• Accessibility guidance
• Reliable release notes
• Manageable upgrades
• Good support for modern .NET versions
• Transparent handling of bug fixes and breaking changes
• Similar concepts across related components

This is where the Telerik UI value proposition becomes stronger. Its advantage is not only that the components are polished, but that the suite tends to feel like a coherent product rather than a collection of unrelated controls.

That can reduce cognitive load for teams. Developers who learn common Telerik concepts in one component often find similar ideas elsewhere in the suite.

Syncfusion’s broader catalog is valuable, but naturally creates a larger surface area to learn, test and govern. That tradeoff may be completely acceptable if the team needs the additional breadth.

Upgrade Experience Takeaway

For short-lived apps, upgrade experience may not matter much.

For applications expected to live for several years, upgrade predictability and maintainable implementation patterns become important. Telerik UI is particularly compelling for teams that prioritize those concerns.

AI Readiness and Agentic Development

A few years ago, component library evaluations focused primarily on features, performance and support. Today, many teams are adding another criterion to their evaluation:

How well does the platform integrate with AI-assisted development workflows?

The discussion is no longer limited to AI-powered components. Developers increasingly expect AI tools that can help generate interfaces, configure components, validate code, enforce design-system rules and accelerate application development.

Progress Telerik AI Approach

Progress Telerik has invested in AI-assisted development across several areas of the product ecosystem, combining UI components, AI-powered tooling and agentic workflows into a more complete development experience.

The foundation of this effort is the Telerik AI Coding Assistant, which integrates directly into developer workflows through IDE-based experiences, GitHub Copilot extensions, and MCP-based tooling. The assistant can help generate Telerik UI for Blazor code, configure components, scaffold common scenarios, generate sample data and provide implementation guidance using Telerik-specific knowledge rather than generic web examples.

Beyond code generation, Progress Telerik has introduced an Agentic UI Generator that uses a collection of specialized assistants working together through an MCP-based architecture. Rather than generating isolated snippets, it can help create complete pages, dashboards, layouts and component configurations while following Telerik component patterns and design-system guidance.

The platform includes specialized assistants for:

• Page and UI generation
• Component selection and configuration
• Layout creation
• Styling and theming
• Icons and visual assets
• Accessibility guidance
• Validation and quality checks
• Project onboarding and setup workflows

These capabilities are orchestrated through the Agentic UI Generator, allowing developers to work at a higher level of abstraction when creating Blazor applications.

Telerik AI Plugins, MCP and Development Tools

One notable aspect of the Telerik AI strategy is the focus on developer tools rather than only AI-enabled components.

The Telerik MCP-based tooling includes plugin capabilities for:


This allows AI tools to work with Telerik-specific knowledge instead of relying solely on generic LLM training data, which can help reduce incorrect component usage and configuration errors.

In addition, Telerik provides AI-enhanced capabilities within its component ecosystem, including AI-powered chat experiences, semantic search scenarios, AI-assisted data operations, AI integrations within Grid and Editor components, WebMCP support, and integration scenarios involving technologies such as A2UI, AG-UI and Microsoft Agent Framework.

Syncfusion AI Position

Syncfusion is also actively investing in AI-based developer experiences and provides AI-related features, assistants and tooling across its ecosystem. Like Progress Telerik, Syncfusion is exploring AI-assisted development workflows and has published AI-related resources and component skills for developers working with its platform.

One of Syncfusion’s broader advantages remains the size of its overall ecosystem, which includes a large collection of UI components, document processing libraries and developer tools that can participate in AI-assisted workflows.

AI Readiness Takeaway

Which platform has the stronger AI story? Today, both Progress Telerik and Syncfusion are investing in AI.

The difference is less about whether AI capabilities exist and more about where the investment is focused.

Syncfusion’s strength comes from the breadth of its ecosystem and the large number of controls, libraries, and scenarios available to developers.

Telerik UI’s strength comes from providing an increasingly connected AI development experience that spans:

• AI Coding Assistant
• Agentic UI Generator
• MCP-based development tooling
• Specialized AI assistants
• Validation workflows
• Accessibility guidance
• Design-system alignment
• AI-enhanced components and features

For teams looking beyond AI-powered controls and toward AI-assisted UI development, Telerik currently offers one of the more comprehensive AI stories available in the Blazor ecosystem. The combination of UI generation, component-aware assistants, validation tooling, theming guidance and MCP integration makes the AI capabilities feel like part of the overall developer workflow rather than a collection of isolated features.

Where Telerik Has a Clear Advantage

Telerik is strongest when the team cares less about maximizing the catalog and more about building a maintainable UI platform.

Telerik is particularly compelling when:

• The application will live for several years.
• Multiple developers or product teams will work in the same codebase.
• The Grid, Forms, Charts, Scheduler and layout components need to feel cohesive.
• Design-system governance matters.
• The team wants strong theming workflows through ThemeBuilder.
• Accessibility evidence is important.
• Support confidence is a major factor.
• AI-assisted development is becoming part of the engineering workflow.

The clearest Telerik differentiator is ThemeBuilder. Its support for visual customization, variables, Figma integration, theme modes, custom fonts, project sharing, version control and collaboration makes it especially useful for teams that need a structured design-to-development workflow.

Pros and Cons

Telerik UI for Blazor

Syncfusion Blazor

Decision Framework

Telerik UI for Blazor is likely the better fit if…

1. The application will be maintained for several years.
2. Multiple developers or teams will contribute to the UI.
3. You need a shared design system.
4. The Grid is central to your application.
5. Accessibility documentation is important.
6. You want a polished and cohesive development experience.
7. Support confidence is part of the buying decision.
8. You expect AI-assisted development to become more important.
9. You value maintainability more than raw component count.

Syncfusion Blazor is likely the better fit if…

1. You need the large component catalog.
2. You need niche components.
3. The Community License applies to you.
4. Your team is comfortable managing a larger API surface.
5. Your evaluation is primarily driven by breadth and feature availability.

Final Verdict

If your primary goal is maximizing the number of available controls, accessing specialized components, benefiting from a Community License, Syncfusion Blazor is difficult to overlook.

If your priority is building a long-lived Blazor application with a cohesive developer experience, strong theming, accessibility documentation, support confidence, predictable implementation patterns and maintainable UI architecture, Telerik UI for Blazor offers a very compelling value proposition.

The choice comes down to what your team wants to optimize for. Feature breadth matters during evaluation. Maintainability matters in production.

For teams building applications that need to scale across developers, products, themes, accessibility requirements, and future AI-assisted workflows, Telerik UI for Blazor stands out as the stronger long-term choice—not because Syncfusion is weak, but because Telerik UI for Blazor’s strengths align especially well with the needs of structured, design-system driven, maintainable Blazor development.

Try Telerik UI for Blazor

The full-stack developer role has never stood still. Many of us started out rendering pages on the server, then learned to build single-page applications when the frontend exploded in complexity.

We picked up REST and GraphQL as APIs became products of their own. And we absorbed containers, CI/CD and cloud deployments when “you build it, you run it” became the norm. Each shift added a new layer to the job, and each time the developers who adapted came out ahead.

AI is the next in this series of shifts, but it’s different in an important way. Previous shifts changed how we build applications. This one also changes who (or what) uses them. The applications we build today are increasingly used not just by people clicking through a UI, but by AI assistants acting on a person’s behalf and by autonomous agents completing entire workflows on their own.

That’s the core idea behind this series, AI Engineering Basics: From Full-stack Developer to AI Engineer. AI isn’t replacing application development. It’s changing what applications are, who consumes them and what we as developers are responsible for. In this first article, we’ll look at how the full-stack role is evolving, clarify the difference between AI-powered apps, assistants and agents, and map out the skills that matter next.

AI-Powered Applications Are Becoming the Default

Not long ago, adding AI to an application meant one of two things: a recommendation engine built by a specialized machine learning team, or a chatbot bolted onto the corner of the screen. That has changed quickly.

With large language models (LLMs) available behind simple APIs from providers like OpenAI, Anthropic and Google, intelligent features are now something any full-stack developer can ship.

An AI-powered application is one where a model participates in the application’s core functionality rather than sitting off to the side. Some familiar examples:

• Conversational interfaces that let users ask questions in natural language instead of navigating menus and filters.
• Retrieval-augmented features that ground model responses in the company’s actual documentation, data or policies (a pattern known as RAG, or Retrieval-Augmented Generation, which we’ll cover in depth later in this series).
• Intelligent workflows that summarize, classify, extract or generate content as part of an existing process, like triaging support tickets or drafting a first pass of a report.
• Adaptive interfaces that reshape what’s on screen based on what the user is trying to accomplish.

The 2025 Stack Overflow Developer Survey found that 84% of developers are using or planning to use AI tools in their workflow. The same transformation is happening to the applications we ship. Users who talk to ChatGPT every day increasingly expect the software they use at work to understand natural language, remember context and do more of the work for them.

For full-stack developers, this is good news. The skills required to build these features (API integration, state management, data modeling, UX judgment) are the skills we already have. What’s new is the layer of model-related decisions sitting on top, and that’s what the rest of this series is about.

Assistants vs. Agents

Two terms come up constantly in this space, and they’re often used interchangeably when they shouldn’t be: assistants and agents.

An AI assistant helps a human do their work, one exchange at a time. The human asks, the assistant responds, and the human decides what happens next. A chat interface that answers questions about your product documentation is an assistant. So is the autocomplete in your editor. The defining trait is that a person stays in the loop for every meaningful step.

An autonomous agent is given a goal rather than a question. It plans the steps needed to reach that goal, uses tools to act (calling APIs, querying databases, updating records), evaluates the results and adjusts until the task is done. The human sets the objective and reviews the outcome, but the intermediate steps happen without them.

The table below summarizes how the two compare:

In practice, the line between the two blurs. Many products start as assistants and gain agent-like capabilities over time, like a support assistant that first only answers questions, then later gains the ability to issue refunds within a set limit.

Understanding where a feature sits on this spectrum matters, because the engineering demands (tooling, permissions, oversight, error handling) grow significantly as autonomy increases.

Our Users Are No Longer Only Human

The bigger shift, and the one this series is named after, is about who we build for. For the entire history of web development, we’ve built applications with one type of consumer in mind: a person looking at a screen. That assumption no longer holds. The applications we build now have three distinct types of consumers:

1. Humans, interacting through the UI the way they always have.
2. AI assistants, acting on a human’s behalf: answering questions about the app’s data, filling in forms or navigating flows for a user.
3. Autonomous agents, completing tasks end to end: an agent might book the meeting, file the expense report or reorder the inventory without a person touching the interface at all.

This changes how we design applications in concrete ways. A dropdown menu is self-explanatory to a human, but an agent needs to know what the options mean and what selecting one will do. A multistep wizard guides a person nicely, but an agent would rather skip the screens entirely and perform the operation directly. In other words, agents care less about our UI than about the capability behind it.

That’s the thinking behind structured actions: taking an operation that currently lives inside click handlers and form submissions and exposing it as a clearly defined, callable action with a name, a description and typed parameters. The description matters as much as the types, because it’s how a model decides when the action applies and what its limits are.

A structured action for a refund flow might look like this:

{
  "name": "create_refund",
  "description": "Issue a refund for a customer order. Refunds over $500 require human approval.",
  "parameters": {
    "order_id": { "type": "string", "description": "The order to refund" },
    "amount": { "type": "number", "description": "Refund amount in USD" },
    "reason": { "type": "string", "description": "Why the refund is being issued" }
  }
}

Nothing about this schema is unfamiliar. It’s the same discipline we already apply to good API design, applied to a new consumer.

Notice too that the description encodes a boundary (refunds over $500 require human approval), which points at the other half of designing for agents: permissions. An agent operating with a user’s full credentials is a serious liability, so autonomous consumers need scoped access and explicit limits on what they can and cannot do.

Standards are also emerging to make these connections consistent, most notably the Model Context Protocol (MCP), which gives models a standardized way to discover and use tools and data sources. We’ll dedicate a full article to MCP later in this series.

From Full-Stack Developer to AI Engineer

Where does all of this leave the full-stack developer? The answer isn’t a career change. It’s an expanded surface area, the same way frontend developers absorbed build tooling and backend developers absorbed infrastructure. The AI Engineer is a full-stack developer who has added a set of model-related responsibilities to their existing ones.

The encouraging part is that most of these responsibilities build on skills full-stack developers already have:

Notice what’s missing from all of this: training models, designing neural network architectures or anything that requires a research background. AI Engineering is an integration discipline. The models are built by someone else, and our job is to build reliable, trustworthy applications around them.

What’s Ahead in This Series

This article is the starting point for a series that will take these ideas from concepts to working systems. Upcoming articles will cover five broad areas:

• AI foundations: The modern AI stack (LLMs, embeddings, vector databases, RAG, agents, orchestration), how AI-powered applications are architected and why prompt engineering alone isn’t enough.
• AI-powered applications: Designing AI-native user experiences, building agent-ready interfaces and patterns for human-agent collaboration.
• Agent engineering: What makes an application agentic, giving agents tools, memory patterns, planning and reasoning, and single-agent vs. multi-agent systems.
• AI operations: Why most AI demos fail in production, understanding token costs, evaluation, observability, security and governance.
• AI-powered development: How coding assistants and agents are changing the way we build software itself.

Wrap-up

The full-stack role isn’t going anywhere, but it is expanding again.

The applications we build are gaining intelligent features as a baseline expectation, and they’re gaining new consumers: assistants acting on behalf of our users and agents acting on their own. Developers who treat AI as a new layer of the stack to master, the same way we once mastered the frontend, the API layer and the cloud, will be well positioned for what comes next.

You don’t need to become a machine learning researcher to make this transition. You need to understand how models behave, how to connect them to your data and your actions safely and how to apply the engineering judgment you already have to a new class of systems. That’s what this series is here to help with, one topic at a time.

For more on how Progress is approaching AI-powered application and agent development, check out the following resources:

• Progress AI Engineering Solutions
• Progress Software: AI-Powered Applications
• Progress Agentic RAG

JavaScript gets a new language standard every year. Some editions introduce syntax that changes how programs are written or how they perform. The ECMAScript 2026 (ES17) version brings a handful of useful features which we will look at. These features add focused APIs for tasks that JavaScript developers already handle with small helpers, repeated checks or easy-to-miss workarounds.

In this article, I will focus on additions that can remove code, make intent clearer or prevent subtle errors.

Runtime support: These APIs did not arrive in every runtime at the same time. Check the Browser compatibility table on each linked MDN page for the browsers and runtimes you support. Use a tested fallback when an API is unavailable.

Image generated with AI

Build a Map as Values Arrive

In my article about array grouping, I showed a simple way to group related things using Object.groupBy() and Map.groupBy(). Both methods begin with a collection that already exists, but what if you want to do the same for streaming data?

For example, this code groups employees from an asynchronous stream:

const employeesByDepartment = new Map();

for await (const employee of employeeStream) {
  if (!employeesByDepartment.has(employee.department)) {
    employeesByDepartment.set(employee.department, []);
  }

  employeesByDepartment
    .get(employee.department)
    .push(employee);
}

There is nothing complicated here, but the has(), set() and get() sequence is boilerplate code around the operation we actually care about—adding a new employee to a department.

ECMAScript 2026 adds Map.prototype.getOrInsert() and Map.prototype.getOrInsertComputed(). These methods return the value corresponding to the specified key. If not present, it inserts a new entry with the key and a given default value, and returns the inserted value.

You should use getOrInsertComputed() whenever the default should be created lazily, particularly when creating it is expensive, has side effects or allocates a mutable object such as an array. With the computed version, the code from before becomes:

const employeesByDepartment = new Map();

for await (const employee of employeeStream) {
  employeesByDepartment
    .getOrInsertComputed(employee.department, () => [])
    .push(employee);
}

The result is simple and compact.

Collect an Asynchronous Iterable into an Array

An asynchronous generator is a useful way to hide pagination. Its caller can consume one sequence without knowing where one response page ends and the next begins. For example:

async function* fetchAllIssues(url) {
  while (url) {
    const response = await fetch(url);

    if (!response.ok) {
      throw new Error(`Request failed: ${response.status}`);
    }

    const page = await response.json();

    yield* page.items;
    url = page.next;
  }
}

To collect every result into an array, you would normally write a loop:

const issues = [];

for await (const issue of fetchAllIssues("/api/issues")) {
  issues.push(issue);
}

The Array.fromAsync() method can be used to perform that collection directly:

const issues = await Array.fromAsync(
  fetchAllIssues("/api/issues"),
);

Isn’t that shorter and simpler?

Despite its name, the method also accepts synchronous iterables and array-like objects. It awaits values from those sources one at a time.

Array.fromAsync() also accepts a mapping function, and the runtime waits for the mapped result before reading the next value. For example, the same code can be adjusted to return only the issue title using the map function:

const issueTitles = await Array.fromAsync(
  fetchAllIssues("/api/issues"),
  (issue) => issue.title,
);

Given that example, it might be misleading to think that Array.fromAsync() runs independent operations concurrently. For example:

// The requests start one after another.
const sequential = await Array.fromAsync(urls, fetchJson);

// All requests are initiated before any of them is awaited.
const concurrent = await Promise.all(urls.map(fetchJson));

You should use Promise.all() when independent operations can run at the same time. And reach for Array.fromAsync() when the source or mapping step may be asynchronous, and you want lazy, ordered consumption. Also remember what the method returns—an array containing every result. Keep the for await...of loop when you want to process a large stream incrementally and avoid collecting a stream that may never end.

Combine Iterables into One Lazy Sequence

Sometimes several iterable sources should behave like one continuous sequence. Suppose an application checks its built-in routes first, then registered routes by plugins and finally a catch-all route. You could spread everything into a new array, but that would eagerly consume each iterable and allocate another collection.

A generator can keep the sequence lazy:

function* allRoutes() {
  yield* builtInRoutes;
  yield* pluginRoutes;
  yield fallbackRoute;
}

Iterator.concat(), on the other hand, expresses the same operation without the custom generator:

const allRoutes = Iterator.concat(
  builtInRoutes,
  pluginRoutes,
  [fallbackRoute],
);

The result yields the built-in routes first, followed by the plugin routes and then the fallback. Values are pulled only as the consumer advances the iterator; Iterator.concat() does not collect them into a new array first. Each argument must be an iterable object, which is why the example wraps fallbackRoute in an array.

The Iterator.concat()method works with synchronous iterables only. It does not combine asynchronous iterables.

Preserve Large Integers in JSON

Chat platforms often hand out snowflake IDs as part of a message or other kinds of data. These are commonly 64-bit integers and can exceed Number.MAX_SAFE_INTEGER, so parsing them as JSON numbers can silently lose precision. Consider this response:

const payload = `{
  "messageId": 1183028002140618753,
  "channel": "general"
}`;

const event = JSON.parse(payload);

console.log(event.messageId);
// 1183028002140618800

The logged value isn’t the value in the JSON text.

ECMAScript 2026 gives the JSON.parse() reviver function a third argument, named context. When the value is an unmodified primitive from the parser, context.source contains the original JSON text. We can use that to parse and convert the text to the proper type, in this case BigInt.

Here’s the sample from earlier, rewritten using the reviver function:

const event = JSON.parse(
  payload,
  (key, value, context) => {
    if (key === "messageId") {
      return BigInt(context.source);
    }

    return value;
  },
);

console.log(event.messageId);
// 1183028002140618753n

By the time the reviver receives value, the Number has already lost precision. However, context.source lets the code ignore that damaged value and build a BigInt from the original digits instead.

Serialization has the opposite problem: JSON.stringify() throws when it reaches a BigInt, unless you handle the value. The new JSON.rawJSON() method lets a replacer function for JSON.stringify provide valid JSON text for a primitive value. The JSON.rawJSON() method creates a “raw JSON” object containing JSON text.

Here’s an example using JSON.stringify() and JSON.rawJSON() together:

const json = JSON.stringify(
  event,
  (key, value) =>
    typeof value === "bigint"
      ? JSON.rawJSON(value.toString())
      : value,
);

console.log(json);
// {"messageId":1183028002140618753,"channel":"general"}

Used together, the two APIs let this program recover the original digits as a BigInt and serialize those digits back into JSON without rounding them.

Using those APIs doesn’t mean you should turn every integer into a BigInt. A count, price and database identifier may all appear as JSON numbers, but they do not necessarily belong in the same underlying JavaScript type. That said, it is important to remember that the parser exposes context.source only for unmodified primitive values, and JSON.rawJSON() accepts only valid JSON text representing a primitive value.

Convert Bytes to and from Base64 or Hex

Binary data has often taken an unnecessary detour through strings. Converting to and from bytes wasn’t a natural interface in the language. I think Bun was the first JS runtime I used that had a built-in API for converting bytes to various data types. Fortunately, the 2026 ECMAScript standard release brings the following functions for converting bytes:

• Uint8Array.prototype.toBase64
• Uint8Array.prototype.toHex
• Uint8Array.prototype.setFromHex and its static form Uint8Array.fromHex
• Uint8Array.prototype.setFromBase64 and its static form Uint8Array.fromBase64

How are they useful, you may ask?

Imagine you want to create a URL-safe token. The code might look like this:

const bytes = crypto.getRandomValues(new Uint8Array(32));

const token = btoa(String.fromCharCode(...bytes))
  .replaceAll("+", "-")
  .replaceAll("/", "_")
  .replace(/=+$/, "");

The program starts with bytes, turns them into a temporary string, encodes that string and then adjusts the alphabet and padding. It works, but none of those intermediate steps express the real task: encode these bytes as base64url.

We can use the Uint8Array.prototype.toBase64() method to do the conversion instead:

const bytes = crypto.getRandomValues(new Uint8Array(32));

const token = bytes.toBase64({
  alphabet: "base64url",
  omitPadding: true,
});

The reverse conversion is also as simple as:

const decoded = Uint8Array.fromBase64(token, {
  alphabet: "base64url",
});

The setFromBase64() and setFromHex() methods write into an existing array and return an object with read and written counts. Unlike fromBase64() and fromHex(), they are useful when you need to control memory allocation, decode into a preallocated buffer or track how much input fits. See the docs for Uint8Array.fromBase64() to learn about the available input options and runtime support.

These methods do not replace TextEncoder or TextDecoder. Use those APIs to convert between text and bytes; use the new Uint8Array methods to convert between bytes and base64 or hexadecimal representations.

Recognize Error Objects Across Realms

The instanceof Error looks like the obvious way to check if an object is an Error. It stops being reliable when the value comes from another JavaScript realm, e.g., an iframe or the Node.js vm context. Each realm has its own Error constructor, so a genuine error from another realm can fail an instanceof check.

Try this in the browser console:

const iframe = document.createElement("iframe");
document.body.append(iframe);

const otherError = new iframe.contentWindow.Error("Failure");

console.log(otherError instanceof Error);
// false

This may not surprise many experienced JavaScript programmers who have been deceived by some JavaScript quirkiness.

The solution is to use the new Error.isError(). Error.isError() performs a built-in check by testing for the internal [[ErrorData]] slot instead of relying on the current realm’s prototype chain. This makes it analogous to Array.isArray() as a reliable cross-realm check.

If you append console.log(Error.isError(otherError)) to the previous code snippet you ran in your browser console, you should see the correct result.

The method is also useful in a catch block because JavaScript allows any value to be thrown:

try {
  await runPlugin();
} catch (value) {
  const error = Error.isError(value)
    ? value
    : new Error(String(value), { cause: value });

  reportError(error);
}

You should use Error.isError() when you need to know whether a value is a real Error object. It deliberately does not treat a plain object with name and message properties as one.

Sum Floating-point Values More Accurately

A straightforward reduce() can lose information while adding floating-point values, and the failure mode is sneakier than you’d expect, because the result doesn’t always look obviously wrong. Consider a motion-sensor library that applies a large per-device calibration offset, adds a small reading, then removes the offset again:

const readings = [1e16, 3.5, -1e16];

const total = readings.reduce(
  (sum, value) => sum + value,
  0,
);

console.log(total);
// 4

The correct answer is 3.5—that’s the actual reading once the offset cancels out. Near 1e16, adjacent representable numbers are two units apart. The exact value 1e16 + 3.5 therefore rounds to 1e16 + 4, and subtracting the offset leaves 4 instead of 3.5. The result isn’t a crash but a plausible-looking wrong number, which is what makes this type of bug easy to miss in code review.

That’s where Math.sumPrecise() comes in. It uses a more accurate summation algorithm, so switching from .reduce() to Math.sumPrecise() gets you the correct answer.

Here’s an accurate way to rewrite it:

const total = Math.sumPrecise(readings);

console.log(total);
// 3.5

The Math.sumPrecise() method accepts an iterable of numbers. It does not coerce strings or BigInt values into numbers. An empty iterable, or one containing only -0, returns -0. The name deserves one warning though, because Precise does not mean decimal arithmetic precision. This familiar result does not change:

console.log(Math.sumPrecise([0.1, 0.2]));
// 0.30000000000000004

Both inputs are already binary floating-point approximations. Math.sumPrecise() reduces the additional error introduced while summing them; it does not change how JavaScript represents numbers. That makes it useful for numerical aggregation, but not a complete solution for money. Use an appropriate decimal type or an integer representation for financial values.

That’s a Wrap

The useful part of the ECMAScript 2026 standard is not a dramatic change to the language. It is that several common use cases now have direct names: get a Map value or create it, preserve the original digits from JSON, encode bytes without pretending they are text, collect an asynchronous sequence, recognize a real Error, sum numbers with less loss and join iterables lazily. None of these APIs will transform an application on its own. They can, however, replace code that is easy to repeat (boilerplate code), easy to get slightly wrong or harder to understand than the operation it performs.

That is why JavaScript has become nicer to use!

Make sure to check runtime support before using these additions in production. The standard defines the language, but every runtime follows its own release schedule. You can get the source code for some of the examples on GitHub.

Further Reading

• ECMAScript 2026 language specification
• TC39 finished proposals at the ECMAScript 2026 cutoff

In this post, I want to talk about a choice most teams are making without realizing it: delegating work to AI agents when they should be automating it deterministically, and the financial cliff that choice creates.

Image generated with AI

We are leaving the golden age of cheap tokens. The era where companies handed AI a blank check and called it innovation is ending. Reports across the industry tell the same story: budgets consumed in months instead of years, teams scrambling to explain runaway costs and executives quietly asking whether the return ever justified the spending. AI agents, the ones that loop, retry, reason and call themselves back, turned out to be remarkably efficient at one thing: burning through tokens.

We talk about the current AI cycle resembling a bubble. And although it has not fully burst yet, the air is leaving. What remains will be expensive. The professionals who built their entire workflow on token-hungry agents will be the first to feel the squeeze.

The Difference Nobody Talks About

There is a fundamental distinction between the two approaches that the industry keeps conflating into a single term.

An AI agent is a system that receives a goal, reasons about it, makes decisions at runtime and consumes tokens with every step. It is powerful. It is also unpredictable in cost because you are paying for the machine to think every time it runs.

Deterministic automation is a system that analyzes a known structure, applies fixed rules and produces a predictable output, without tokens or runtime reasoning. That will reduce the surprises on your invoice.

Both use intelligence. One front-loads it. The intelligence lives in the design, not in the execution. I call it deterministic AI: a system shaped by years of architectural thinking, where the machine does not need to reason because the reasoning already happened when you built it.

The most intelligent system is the one that does not need to think at runtime.

What I Built Instead

I spent years building a platform that generates entire SaaS applications from a data structure. Not a prototype, and not a scaffold. A complete, production-grade system: backend in .NET, frontend in React, data-first, mobile-first, unit test coverage on both sides, observability baked in with Prometheus, Loki and Tempo, and ready-made Grafana dashboard templates. Roughly 60 files per entity, generated deterministically from the shape of your data.

When a client asked me for a Micro CRM to be delivered overnight, I did not open an AI chat and start prompting. I ran my automation. In under eight hours, including three hours of database design, I made it myself. It was done. Backend, frontend, tests, monitoring. Everything in less than eight hours.

And with zero tokens consumed. (That also cuts unpredictable costs.) The result was identical to what I would have delivered if I had spent a week writing it by hand, because the automation encodes years of decisions I already made.

This is not anti-AI. This is anti-waste.

Where AI Still Earns Its Place

I am not arguing against AI. I use it. But I use it surgically, not as a crutch.

My automation already had a structure designed around C# interfaces, built specifically so that an AI model could understand and navigate the codebase. When I needed to expand unit test coverage, I pointed an AI coding assistant at the existing tests and had it generate new ones that followed the same patterns. I ran it for about six hours over two days. The cost was around $20 in tokens.

Twenty dollars. A manageable, traceable cost for a well-scoped task. But here is the part that matters: I had set a spending limit. Without it, that same task could have spiraled into hundreds, maybe thousands. And that, I believe, is exactly where companies bleeding money on AI are failing: not in choosing to use it, but in using it without boundaries.

I also explored running a custom LLM locally using Ollama and integrating it with my coding environment. It offers unlimited token usage at zero marginal cost, but it demands serious hardware: a GPU with at least 16 or 20 GB of VRAM. For teams that can invest in the infrastructure, it is a path worth exploring, one that decouples your productivity from someone else’s pricing model. Here is a tutorial about my journey implementing custom LLM on Cursor.

Use AI where it multiplies your intelligence. Automate where it would only repeat it.

Build the Machine That Does Not Need the Machine

There is a deeper lesson here, and it goes beyond cost optimization.

If your entire delivery pipeline depends on an external AI service to function, you have a single point of failure priced by someone else. Token prices go up. APIs go down. Models get deprecated. Rate limits tighten. And when any of that happens, your ability to deliver stops with it.

Deterministic automation is yours. You own it. It runs on your terms. It does not get more expensive overnight. And it does not hallucinate.

The architect who invests in automation today is building a shelter for when the token economy changes, and it will change. The one who delegates everything to agents is building on rented land.

Automate with AI. But never depend on AI to execute.

Conclusion

We are at an inflection point. The decisions architects and developers make right now, about what to automate deterministically and what to delegate to AI agents, will define the resilience and economics of their products for years to come.

The question is not whether AI is useful. It is. The question is whether you are building something that survives when the cost of thinking doubles.

So before you spin up another agent, ask yourself: could this be a machine that already knows the answer?

Have you ever heard of Pan de Jamón? I hadn’t—until I met Mike, one of the best developers I ever worked with.

This isn’t a “here’s what bread taught me about life” post. It’s an observation that might bring some light to an AI outlook that can feel pretty dark sometimes.

What made Mike stand out wasn’t only his personality or skillset. It was that he went home and baked Venezuelan Christmas bread.

Ode to the Hobbyist

And it wasn’t only Mike. Most developers I remember, I remember by their hobby.

Just off the top of my mind:

• The genius printing parts on a 3D printer he built himself
• The audiophile building a sound system for a perfect pitch
• The home-automation engineer who wired his house with PLCs
• The architect drilling a water well in his own backyard
• The rotary-engine-obsessed designer with a Mazda RX-7
• The 3D specialist restoring a surf van with his son

None of this is on their LinkedIn profile. None of it pays. And it’s the most interesting thing about them.

I’ve spent a long time in enterprise software, working with developers who write code that runs critical infrastructure.

The pattern is so consistent it stopped being a pattern and started looking like a characteristic: The best developers I’ve worked with don’t stop building when they close the laptop. They go home and make something else—bread, sound, water, vans. They just stop getting paid for it.

What Agents Don’t Have

We live in interesting times. Agents are now colleagues that cooperate in writing our code. And companies are considering, or actively pursuing, what that means for headcount. More and more developers are asking: “Will there be a job for me? How do I compete?”

But here’s what agents don’t do. They don’t drive home and pick up a task that’s not on a kanban board. They don’t lose a Saturday to a bad weld or experiment with different kinds of dough and oven temperatures. They don’t bake a loaf that fails three weekends in a row and quietly absorb the lesson that some processes can’t be hurried, no matter how clever the idea. They don’t ferment, restore, dig, solder, role-play or rebuild.

Agents have no Saturday. They have no irrational, over-obsessed curiosity we call a hobby.

Hobbies are unpressured, unstructured, unscheduled—messy mindbenders. That’s what agents miss. And this unpaid labor is where a lot of real learning happens. The kind that doesn’t show up in the sprint demo, but shows up in great architecture decisions, clever unit tests and surprising solutions.

Don’t Give Up on Your Hobbies

If you’re a developer wondering what to do with the noise about AI replacing you, here’s an honest answer: Look beyond the code. Lean harder into the things you make that nobody pays you for.

Your hobby isn’t a side-quest to the main game of being a developer. It’s not only about balance, self-care or free time. It’s where you keep growing the part of yourself that an agent can’t copy. Where character is formed. Where unconstrained thinking is allowed and you explore solutions only you have to justify.

That wonderful waste of a Saturday is the perspective that breaks through on a mundane Monday morning.

The coffee chat “what did you do over the weekend?” might be the context that wins over the agent whose most coffee-related moment is running a brew command in the terminal.

So bake the bread. Dig the well. Restore the van. Roll the dice.

Keep building without getting paid. That’s the work that keeps you irreplaceable.