Project timelines are easy to visualize. Balancing workloads within a team? That’s where it gets harder. In real project planning, the challenge isn’t drawing a schedule; it’s ensuring resources aren’t overloaded, assignments don’t conflict, and changes can be reviewed quickly without derailing the plan.

In this webinar, Prabhavathi Kannan showed attendees how pairing the Syncfusion Blazor Gantt Chart with Azure OpenAI creates an intelligent, review‑friendly workload‑balancing experience. The result: less manual effort, more clarity, and faster, better decisions.

If you missed the webinar or would like to review part of it, the recording has been uploaded to our YouTube channel and embedded below.

The hidden challenges

Even when tasks, timelines, and resources look well defined, planners still spend time:

• Identifying resource overallocation.
• Detecting overlapping assignments.
• Understanding true availability.
• Reassigning tasks without breaking dependencies.

As projects scale, small schedule tweaks affect multiple people. Manual review becomes slow and error‑prone. The real bottleneck isn’t visualization, it’s decision efficiency.

A smarter approach: AI‑assisted balancing

Rather than relying solely on manual analysis, let AI analyze current data, suggest optimized task assignments, and present potential changes for quick review. This doesn’t replace human planning; it provides a stronger starting point that reduces repetition and accelerates decision‑making.

Technology stack

• Syncfusion Blazor Gantt Chart: A project planning and management component with a Microsoft Project–like interface for managing tasks, dependencies, and resources. In this session, we used the resource view to organize tasks by resource, making workloads, overlaps, and overallocation easier to review.
• Azure OpenAI: An Azure service that provides access to OpenAI models. In this session, it analyzed tasks, resources, and assignments to suggest workload-balanced reassignments that could be applied to the Gantt Chart.

Prerequisites

• Visual Studio Code (or your preferred editor)
• .NET SDK with Blazor support
• A Syncfusion license key
• An Azure OpenAI resource

What we built

Step 1: Visualize the workload

• Gantt Chart in resource view with overallocation highlighting.
• Immediate insight: some resources had overlapping tasks; others were underutilized.

Step 2: Optimize with AI

• One click: “Optimize resource allocation.”
• Behind the scenes:
  • Collect current tasks, resources, and assignments.
  • Generate a structured, constrained prompt.
  • Send prompt to Azure OpenAI.
  • Receive optimized assignments in JSON.
  • Parse and apply updates to the Gantt Chart.

Step 3: Make results reviewable

• Visually highlight updated taskbars.
• Use color to make changes obvious.
• Provide a clear fallback message for safe, graceful error handling.

Why it works

• Reduced manual effort: AI handles the repetitive overlap scan and first‑pass balancing.
• Faster decisions: Planners start from an optimized baseline, not a blank slate.
• Improved visibility: The Gantt Chart shows both the problem (overallocation) and the solution (rebalanced work).
• Trust through transparency: Visual highlighting makes AI changes explicit and easy to validate.

Implementation highlights

• Data modeling: Clean separation of resources, tasks, and
• Resource view: Workload‑centric visualization for practical planning.
• Prompt design: Controlled, deterministic prompts for predictable outputs.
• JSON contract: Parseable responses for seamless UI updates.
• Service layer: Encapsulated AI logic for reuse and testability.
• UX polish: Custom templates and styling to make changes immediately clear.

The bigger picture: AI in the flow

AI is most effective when embedded directly into workflows, not bolted on. Here, the Gantt Chart is the decision surface, and AI augments it with timely, contextual recommendations.

Time stamps

• [00:00] Welcome and session introduction
• [00:19] The challenge of workload balancing in project planning
• [01:04] Why resource overallocation becomes difficult to manage
• [01:16] Using AI to reduce manual planning effort
• [01:31] Session agenda and workflow overview
• [01:50] Poll: biggest resource management challenge
• [02:40] The AI-assisted workload balancing solution
• [03:42] Overview of the Syncfusion Blazor Gantt Chart workflow
• [04:03] Using Azure OpenAI for workload analysis
• [04:21] How AI-generated reassignment suggestions work
• [04:56] Demo prerequisites and project setup
• [05:43] Three implementation phases overview
• [07:05] Building the workload view
• [07:29] Understanding task, resource, and assignment data
• [08:38] How AI uses project data for balancing decisions
• [09:06] Setting up the page code-behind
• [10:10] Configuring the Gantt Chart in resource view
• [10:28] Enabling overallocation visualization
• [10:49] Mapping task, resource, and assignment data
• [11:16] Configuring labels and grid columns
• [11:53] Adding the Optimize Resource Allocation button
• [12:16] Styling the workload planning interface
• [13:17] Reviewing the initial workload visualization
• [14:08] Identifying overloaded resources visually
• [14:58] Phase 2: Adding AI-assisted reallocation
• [15:23] Creating the Azure OpenAI service
• [16:34] Building the AI request workflow
• [17:04] Returning structured JSON assignment updates
• [17:16] Configuring Azure OpenAI in the application
• [18:03] Building the AI optimization prompt
• [19:09] Handling the Optimize Resource Allocation workflow
• [19:59] Applying AI-generated updates to the Gantt Chart
• [20:29] Connecting the UI to the AI workflow
• [21:48] Running the AI-assisted rebalance demo
• [22:10] Reviewing updated task assignments
• [22:42] Why visual review of AI changes matters
• [23:04] Phase 3: Visualizing AI-generated updates
• [23:32] Adding fallback error handling
• [25:16] Creating custom taskbar templates
• [25:55] Highlighting AI-updated taskbars visually
• [26:45] Reviewing the final, optimized workload result
• [27:22] Benefits of AI-assisted workload balancing
• [27:43] Final audience poll
• [28:24] Session recap and key takeaways
• [29:27] Why AI improves project planning workflows

Q&A

Q: When using apps like Codex instead of the Syncfusion Code Studio, we still have full access to the Syncfusion MCP servers with the correct keys and configuration. True?

A: Yes, users can access Syncfusion MCP servers from compatible AI IDEs with the correct keys and configuration.

Final thoughts

Workload balancing is critical and often time‑consuming. With the right combination of visualization and AI, teams can:

• Detect issues faster.
• Evaluate alternatives quickly.
• Keep delivery on track.

By integrating the Syncfusion Blazor Gantt Chart with Azure OpenAI, you can move beyond static schedules to applications that actively help users plan smarter.

Related links

Interested in exploring the tools covered in this webinar? Check out the following links:

• Blazor Gantt Chart
• Smart Resource Allocation demo

Learn how Progress Telerik UI and Kendo UI tools leverage WebMCP to expose enterprise application functionality directly to AI agents through standardized tools.

For some time, AI agents have tried to use the web the way humans do—by looking at pixels, guessing at buttons and clicking around. It mostly works. Sometimes. Until a label changes, a layout shifts or a modal pops up at the wrong moment. 

There is a better way—one where your application tells the agent exactly what it can do, in a language the agent natively understands. That language is WebMCP. 

With our Q2 2026 release, every Blazor, Angular or React application built on Progress Telerik and Progress Kendo UI will be able to expose its business logic as agent tools—with no rewrites, no API gateways and no screen scraping. And to make adoption effortless, we’re shipping a dedicated Browser Extension in the marketplace that lets you talk to any Telerik or Kendo-powered page out of the box. 

Join us for the Telerik and Kendo UI 2026 Q2 release webinar on June 16 to see firsthand how your UI can become directly usable by AI agents. Save your seat now! 

What Is WebMCP? 

WebMCP is a proposed web standard—incubated by the Google Chrome team and currently shipping behind a flag in Chrome 146—that lets a website publish a structured contract of what it can do to AI agents running in the browser. 

Instead of an agent scraping the DOM and guessing how to submit a form, the page itself says: “Here are my tools. Here is what each one does. Here are the inputs each one needs.” The agent then calls those tools the same way it would call any function. 

There are two ways a page can declare its tools: 

• Imperative API—register tools from JavaScript with navigator.modelContext.registerTool() and unregister them when they no longer apply to the page state. 

• Declarative API—annotate an existing HTML <form> with toolname and tooldescription attributes and the browser automatically turns it into a tool the agent can call. 

The result is a clean separation: humans interact with your UI through clicks; agents interact with the same UI through tool calls. One application. Two audiences. One source of truth. 

Why does this matter? Three reasons that show up immediately: 

• Reliability over hallucination. The agent stops inventing what it thinks should happen and starts calling exactly what your app exposes. That is the difference between a demo and a deployment. 

• Zero backend changes to start. The declarative API turns existing forms into tools just by adding two attributes. Your authentication, validation and business logic stay where they are. 

• Dynamic control. Tools register and unregister as your UI state changes. A checkout tool is only available when the user is on the checkout page. That is a security boundary, not just a UX nicety. 

New Benefits for Your App’s Users 

Standards are abstract. End-user outcomes are not. Here is what your customers can do once your Telerik or Kendo-powered application speaks WebMCP: 

• Operate dense enterprise data with one sentence. “Filter to all overdue invoices in Q1, group by client and export to Excel.” What used to take seven clicks and a column chooser becomes a single prompt against your Kendo Grid. 

• Stop teaching new hires the UI. Onboarding compresses dramatically because the agent already knows how to use the application. New users describe outcomes; the agent uses the same components they would have used. 

• Move work between systems without integrations. Drag-and-drop has a new sibling: tell-and-confirm. Move a task from one Scheduler to another or replicate a row of a TreeList in another grid without writing a single line of glue code. 

• Bring accessibility forward by default. Voice, natural language and keyboard-first interactions all converge on the same underlying tools. Users who could not navigate a complex grid before suddenly can. 

• Keep humans in control. Every agent action focuses on the real component, highlights what it is about to do and waits for the user where it should. The UI stays the source of truth—the agent just gets there faster. 

One component, two audiences — the same Kendo Grid serves human clicks and agent tool calls. 

Agent-Ready Components by Default 

Telerik and Kendo UI components are not just visual chrome. They encapsulate the real work of an enterprise application—filtering, grouping, virtualizing, exporting, scheduling, validating, charting. Decades of behavior sit behind those APIs. 

That makes them the natural surface for WebMCP. The contract an agent needs to interact with your app already exists—it is the public method surface of the component you are already using. We are exposing it. 

The Q2 2026 ships agent-ready behavior across our flagship components in Preview. A Kendo Grid registers tools like filter_data, group_by, sort_by and export. A Scheduler registers create_event, reschedule and find_availability. A Form registers submit with a fully typed input schema derived from your field definitions. You do not write the tool plumbing—the componentdoes. 

Then the browser-based AI Agent calls the tools and executes the defined logic. Here’s an example of a tool call in our Browser Extension: 

For richer interactions, our imperative wrappers let a component register and tear down tools as its state changes—so a chart only offers drill_down while data is loaded and an editor only offers save_draft while a draft exists. Tools come and go with your UI, which is the trust model enterprises ask for. 

“Flip a property, not rewrite your app. The Telerik and Kendo components you already ship become the agent surface of your application.” 

Of course, you can plug in and customize the tools, adapting their descriptions to suit best your business workflows and scenarios. This helps create an even stronger bridge between the agent and your application. 

The Telerik & Kendo UI Browser Extension 

WebMCP is a powerful primitive but most users today do not have an agentic browser configured. We did not want that to be standing between your application and its first agent-driven workflow. 

That is why, alongside the Q2 2026 release, we are publishing the Telerik & Kendo UI Browser Extension. It is a lightweight companion that brings an agent directly into any page that exposes WebMCP tools—Telerik- and Kendo-powered pages get full first-class treatment.

The Telerik & Kendo UI Browser Extension—available in the marketplace alongside the Q2 2026 release. Image is illustrative; the published version may differ. 

What you get out of the box: 

• Tool discovery for the active tab. Open the extension and see every WebMCP tool the page has registered, with its description and input schema. 

• A chat surface that runs against those tools. Ask the page to do something in plain language; the extension picks the right tool, fills the inputs and calls it. 

• The Blueprint mode enables the user to go to a page, scan the DOM tree and based on the elements the AI sees, it will attempt to map each UI component on the page to a relevant Telerik/Kendo widget. 

• Local-first by design. Your API keys stay in local extension storage. Nothing leaks server-side without your consent. 

• Tools, Usage and Settings tabs. Manage which sites are allowed to register tools, watch how often each tool is called and pick the model that fits the workload. 

If you are building with Telerik and Kendo UI, the extension is the fastest way to demonstrate WebMCP value to your team without setting up a Chrome flag, a Gemini key or a custom agent runtime. Install it, open your existing app and watch the agent use the components you already shipped. 

Availability: Q2 2026 in Preview 

WebMCP itself is still an early-preview standard. Chrome ships it behind a flag, the API surface is still settling and headless agent execution—calling tools without a visible browser tab—is explicitly out of scope today. To enable WebMCP in Chromе, visit chrome://flags/#enable-webmcp-testing and enable the WebMCP for testing. 

We are matching that posture. Our Q2 2026 release ships WebMCP support in Preview across the Telerik and Kendo UI products: 
 
- Telerik UI for Blazor 
- Kendo UI for Angular 
- KendoReact 

We also ship a new Browser Extension in the marketplace: Telerik & KendoUI.  

“Preview” means production-quality engineering with an explicit signal that the underlying contract may evolve as the standard matures. We will move with it. 

If your team has an agent strategy on the 2026 roadmap, this is the moment to wire up a pilot. Pick one workflow—a complex form, a reporting grid, a scheduling view—turn on WebMCP, install the extension and watch how your users interact with it within a week. 

Explore the WebMCP Value 

WebMCP is not a UI revolution. It is a contract revolution—between the apps you build and the agents your users are bringing to them. The applications that publish that contract first will be the ones that feel obviously modern in 2026 and 2027. 

The Telerik and Kendo UI components are now designed to put you on the right side of that line without rewriting what already works. Your components remain the same. Your customers gain a new way to use them. Your team ships once and serves two audiences. 

Download and test the Q2 2026, install the Browser Extension from the marketplace and tell us what your users do with it. We are designing this with you, not for you. 

For further information about the setup, check the Product documentation: 
- Telerik UI for Blazor 
- Kendo UI for Angular 
- KendoReact 

Video: The Power of Kendo and Telerik Apps Through the WebMCP Lens 

Operations Hub: End-user can cut a multi-step logistics workflow—filter delayed shipments, map them, hand the data to the warehouse team and total the exposure—from minutes of clicking down to one sentence. 
 
Telerik and Kendo UI Workflows Powered by WebMCP 

Finance Performance: End-user can turn a quarterly review from question to scheduled meeting in seconds—surface under-performers, generate PDFs and book the follow-up without leaving the dashboard. 

AI Agent-Ready Dashboard powered by Telerik and Kendo UI with WebMCP 

Don’t forget to leave us a comment below, share your view or ask any question. 

Terraform is a proven infrastructure as code tool with a large provider and module ecosystem. Many teams choose Pulumi when they want to keep that infrastructure as code model, but write and maintain infrastructure with general-purpose programming languages, familiar package managers, IDEs, testing, and software engineering patterns, while still understanding the refactoring tradeoffs in Terraform’s own module refactoring guidance.

Why choose Pulumi over Terraform? Pulumi’s language SDKs let teams define cloud infrastructure in TypeScript, Python, Go, C#, Java, or YAML while adding first-class workflows for refactoring with Pulumi aliases, secrets, protect, retainOnDelete, deleteBeforeReplace, replaceOnChanges, provider resources, Pulumi stacks, testing, and incremental migration with pulumi import. Pulumi does not remove every hard problem in cloud infrastructure, but it gives teams stronger tools for many day-to-day pain points.

Executive summary

Pulumi is often a better fit when infrastructure code needs to behave like application code: reviewed, tested, packaged, refactored, and shared across teams. The biggest advantages show up when teams need safer refactors, encrypted secret values, reusable components, clearer provider resources, and guardrails around destructive changes.

The tradeoff is important: Pulumi is still an infrastructure as code engine. Provider bugs, cloud API eventual consistency, drift, preview-time unknowns, and poorly designed abstractions still require engineering discipline. The advantage is not magic. The advantage is a stronger programming model and a more familiar developer workflow.

Use programming languages and familiar tools

Terraform modules are powerful, but larger HCL codebases can require teams to maintain separate conventions for composition, validation, and reuse. Pulumi lets infrastructure teams use the features of whichever supported programming language they choose, such as classes, functions, types, loops, package managers, linters, and test frameworks.

For example, a platform team can wrap a standard storage pattern in a ComponentResource and share it like any other TypeScript abstraction:

import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

interface WorkQueueArgs {
 visibilityTimeoutSeconds: number;
}

class WorkQueue extends pulumi.ComponentResource {
 public readonly queueUrl: pulumi.Output<string>;

 constructor(name: string, args: WorkQueueArgs, opts?: pulumi.ComponentResourceOptions) {
 super("platform:queue:WorkQueue", name, {}, opts);

 const queue = new aws.sqs.Queue(`${name}-queue`, {
 visibilityTimeoutSeconds: args.visibilityTimeoutSeconds,
 }, { parent: this });

 this.queueUrl = queue.url;
 this.registerOutputs({ queueUrl: this.queueUrl });
 }
}

const jobs = new WorkQueue("image-jobs", {
 visibilityTimeoutSeconds: 60,
});

Refactor infrastructure without surprise replacement

Renaming a resource, moving it into a component, or reorganizing a project should not automatically mean replacing production infrastructure. Pulumi aliases let you tell Pulumi how a resource used to be addressed, so refactors can preserve resource identity when the old and new resources represent the same cloud object.

const queue = new aws.sqs.Queue("app-jobs", {
 visibilityTimeoutSeconds: 60,
}, {
 aliases: [{ name: "jobs" }],
});

Aliases are not a substitute for review. They work when the old identity is modeled correctly, including details such as name, parent, type, project, and stack when those changed.

Handle secrets with encrypted configuration and secret outputs

Secrets are one of the most common places where infrastructure workflows become risky. Terraform has sensitive values and backend guidance, but teams still need to understand how plans, state, outputs, and backend access interact. Pulumi treats secrets as first-class values, encrypts them in state, and preserves secrecy as values flow through outputs.

const config = new pulumi.Config();
const dbPassword = config.requireSecret("dbPassword");

const passwordParameter = new aws.ssm.Parameter("db-password", {
 type: "SecureString",
 value: dbPassword,
});

This improves the default experience, but it’s not runtime isolation. In the TypeScript SDK, config.requireSecret("dbPassword") retrieves secret configuration, and your program can still access the decrypted value while it runs, so reviews, least privilege, and secret-provider choices still matter. If a value starts as a plain input instead of coming from requireSecret, pulumi.secret(...) can mark it as secret.

Add safer lifecycle controls for destructive changes

Infrastructure mistakes are expensive when they replace or delete stateful resources. Pulumi gives teams explicit resource options for safety-sensitive intent, such as protect, retainOnDelete, deleteBeforeReplace, and replaceOnChanges.

const database = new aws.rds.Instance("orders-db", {
 instanceClass: "db.t4g.micro",
 allocatedStorage: 20,
 engine: "postgres",
 username: "app",
 password: dbPassword,
}, {
 protect: true,
 retainOnDelete: true,
});

These controls are guardrails, not guarantees. Provider bugs, cloud API eventual consistency, and replacement behavior still require preview review and operational judgment. replaceOnChanges applies to custom resources only, not component resources.

Model environments with stacks

Terraform workspaces can represent environments, but many teams eventually need stronger boundaries for configuration, secrets, history, and cross-environment outputs. Pulumi stacks make environment boundaries explicit and pair them with per-stack config and outputs.

const networking = new pulumi.StackReference("acme/networking/prod");
const vpcId = networking.requireOutput("vpcId");

const appSecurityGroup = new aws.ec2.SecurityGroup("app-sg", {
 vpcId,
 ingress: [{
 protocol: "tcp",
 fromPort: 443,
 toPort: 443,
 cidrBlocks: ["10.0.0.0/8"],
 }],
 egress: [{
 protocol: "-1",
 fromPort: 0,
 toPort: 0,
 cidrBlocks: ["0.0.0.0/0"],
 }],
});

Cross-stack references are cleaner than sharing an entire remote state file, but they are still dependencies. Keep stack outputs intentional and avoid turning one stack into a global variable bag.

Test infrastructure with normal language tooling

Because Pulumi programs are real programs, infrastructure testing can use familiar test runners and assertions. Teams can test component defaults, naming conventions, required tags, and policy assumptions before a deployment reaches production.

pulumi.runtime.setMocks({
 newResource: (args) => ({
 id: `${args.name}_id`,
 state: args.inputs,
 }),
 call: (args) => args.inputs,
});

Testing does not replace previews. It catches a different class of problems: broken abstractions, missing required inputs, invalid defaults, and regressions in shared components.

Wire providers explicitly

Provider configuration is another place where explicit code can reduce ambiguity. In Terraform, provider inheritance and aliases are often managed across module boundaries. In Pulumi, provider resources are normal resources that can be passed through resource options, which makes multi-region or multi-account deployments easier to follow in code review.

const west = new aws.Provider("west", {
 region: "us-west-2",
});

const east = new aws.Provider("east", {
 region: "us-east-1",
});

const primary = new aws.sqs.Queue("primary-jobs", {}, {
 provider: west,
});

const replica = new aws.sqs.Queue("replica-jobs", {}, {
 provider: east,
});

The provider object does not remove provider versioning or schema-change risk, but it makes provider wiring visible in the same language and review flow as the rest of the program.

Import and migrate incrementally

Teams rarely get to rebuild infrastructure from scratch. Pulumi supports incremental adoption with pulumi import, generated code, and Terraform interoperability paths. That makes it possible to start with one resource, one component, or one stack instead of forcing a big-bang migration.

Pulumi also supports interoperability paths for teams that need to bring existing Terraform assets forward over time, including Terraform provider access and migration workflows. That makes migration an engineering sequence, not an all-or-nothing rewrite.

const importedRepository = new aws.ecr.Repository("app", {
 name: "existing-app-repo",
}, {
 import: "existing-app-repo",
});

The CLI flow can also generate declarations with pulumi import. Generated code is a starting point, not a finished architecture. Review names, options, providers, secrets, and component boundaries before treating imported resources as production-ready Pulumi code.

What Pulumi does not magically fix

Pulumi does not eliminate cloud API eventual consistency. A deployment can finish successfully while downstream reads, controllers, or other operators still see stale state for a short window. That is a property of the cloud control plane, not of the IaC tool.

Pulumi also does not eliminate provider bugs or drift. If a provider has a schema issue, a bad default, or a flaky update path, Pulumi still has to ride that provider behavior. Likewise, if something changes outside Pulumi, you still need to detect it and reconcile it with refresh or another drift-management process.

Pulumi does not eliminate preview-time unknowns either. Some values are not known until deployment, so the plan can still contain uncertainty. Bad project decomposition and side-effect-heavy deployment code remain risks too, which is why testing, clear stack boundaries, and disciplined component design still matter.

OpenTofu compatibility caveat

OpenTofu users face many of the same infrastructure-as-code concerns around state, providers, drift, secrets, lifecycle behavior, and migration planning. This post stays Terraform-focused because that is where most teams begin the Pulumi comparison, but the same Pulumi capabilities are relevant when evaluating OpenTofu alternatives or hybrid migration paths.

Pulumi can also work with Terraform provider ecosystems, including long-tail providers that may not have a native Pulumi package yet. Treat that as an interoperability path, not a promise that every Terraform or OpenTofu workflow maps one-for-one without design work.

Get started with Pulumi

If your team is evaluating infrastructure as code options, start with the workflow that creates the most leverage: write infrastructure in the language your team already uses, test shared components, protect critical resources, and migrate one stack at a time.

To go deeper, get started with Pulumi or read the Terraform migration guide.

What's Changed

• .NET: Persist ForeachExecutor iteration state across checkpoints by @peibekwe in #6051
• .NET: Remove responses experimental flag from FoundryAgent et.al. by @westey-m in #6121
• .NET: Add MCP-based skills support (skill-md type) by @semenshi in #6108
• .NET: [BREAKING] Remove Support for Code-Gen in Declarative Workflows by @peibekwe in #6095
• feat(a2a): add A2AAgentSession with reference_task_ids and input-required support by @giles17 in #5980
• .NET: Add Foundry Toolbox MCP skills discovery sample by @semenshi in #6134
• .NET: Fix render dupe and text input clear bugs, and improve guardrail error messaging by @westey-m in #6136
• .NET: Add missing projects to solution for release by @peibekwe in #6157
• .NET: Support ClaimsIdentity-based scoping of agent sessions by @lokitoth in #5696
• .NET: feat: Bring Handoff Orchestration to parity with Python by @lokitoth in #6138
• .NET: [Breaking] Refactor AgentFileSkillsSource for depth-based discovery and predicate filters by @semenshi in #6109
• .NET: Updating version for dotnet release 1.8.0 by @peibekwe in #6161

Full Changelog: dotnet-1.7.0...dotnet-1.8.0

Back for its 9th year, Maker Faire Long Island is settling in to its new home on the SUNY Stonybrook campus. This year’s event “Maker Faire Long Island is where creativity becomes something visitors can see, touch, build and experience,” said Lisa Rodriguez, Co-Producer of Maker Faire Long Island and Director of Digital Marketing for […]

The post Maker Faire Long Island #9: Saturday, June 6th appeared first on Make: DIY Projects and Ideas for Makers.

Greg Wilson has noticed that lots of folks are using dodgy metrics to figure out if AI tools are worth their costs.

Would you measure lines of code generated, or tickets closed? Or would you send out a survey asking whether developers feel more productive? Each of those approaches is flawed in a different way;

He lists lots of common metrics, and why they are flawed. Sadly he doesn’t give any suggestions on what would be better. In my view, since we cannot measure productivity, any metrics are weak evidence at the best of times.

I do somewhat use one of his flawed measures: “Asking Developers If They Feel More Productive”. While I acknowledge the problems he gives with this measure, I find that in an environment where decent measures are hard to find, even such a dim light is the best we have. In this situation these kinds of qualitative metrics may not be conclusive, but they are useful.

 ❄                ❄                ❄                ❄                ❄

Benedict Evans observes that extensive automation didn’t mean the demise of professions in the past.

we spent a century automating accounting: we built calculating machines, punch cards, mainframes, data processing, databases, PCs, spreadsheets, ERPs, cloud… in fact, we built half of the tech industry around automating this. Yet the number of accountants kept going up.

He goes into the myriad of problems that exist when we’re trying to forecast the impact of a technology on jobs. There’s the much-talked-about Jevons paradox - once something becomes cheaper, people do it more, which can increase demand. Often this leads to the nature of jobs changing, even if it’s called the same thing.

Accountants today aren’t doing exactly the same work that they did in 1970 or 1980 ‘but more’ - they’re still called ‘accountants’ but the job is different. New technology often starts out being used for ‘the old thing but more’, but it rarely ends up like that.

Technologies often affect whole businesses - consider the impact of the internet on news publishing. Did anyone observing the rise of smart phones in the early 2000s realize that a consequence of this would change the economics of taxis due to the rise of ride-sharing apps? The conclusion is that it is, at the very least, almost impossible to forecast the impact of AI on our work.

 ❄                ❄                ❄                ❄                ❄

Stephen O’Grady looks at how closed and open models have performed on benchmarks over time.

Closed models are setting the pace of innovation, and constantly breaking new ground from a capabilities standpoint. Open models are chasing them, and the cycle times seem to be getting shorter. There are no clear capability moats, and what is frontier today is table stakes tomorrow.

It tooks 13-18 months for open models to catch up to GPT-4 on these benchmarks, but only 2-7 months to catch up to GPT-4o.

There’s a bunch of caveats to this analysis, that he lists, but it’s a worthwhile survey of how various kinds of models perform against the various measures we are trying to assess them with.

 ❄                ❄                ❄                ❄                ❄

One of the starkest examples of sloppy AI use is hallucinated citations - a give-away of both usage of LLMs and carelessness driving them. GPTZero is a company that makes tools to detect AI writing. I’ve no insight as to whether their tool is effective or not, but they do publish investigations of AI usage, and have published several articles highlighting hallucinated citations. One post focuses on Ernst & Young Canada’s report on cyber threats to loyalty systems and found that more than half its references were hallucinations. The post uses a lot of extremely annoying animations in how it presents its information (breaking Safari’s reader mode in the process). But the harm that these kind of AI generated reports can do goes further than just some misled humans:

Publishing a report online is essentially a form of data injection into the pool of knowledge that is the internet. When the report includes fake information (either vibed citations or false claims) it can “poison the well” by misleading future researchers, especially if the report is published by a well-known consulting firm and hosted on a high-traffic website.

 ❄                ❄                ❄                ❄                ❄

As LLMs get more capable in programming, we are rightly worried that people will use them attack software systems. But these models can also be used for defense, allowing teams to find bugs before attackers do. Some folks from Mozilla posted an article on how they’ve used AI model to identify and fix an unprecedented number of latent security bugs in Firefox.

Just a few months ago, AI-generated security bug reports to open source projects were mostly known for being unwanted slop. Dealing with reports that look plausibly correct but are wrong imposes an asymmetric cost on project maintainers: it’s cheap and easy to prompt an LLM to find a “problem” in code, but slow and expensive to respond to it.

It is difficult to overstate how much this dynamic changed for us over a few short months. This was due to a combination of two main factors. First, the models got a lot more capable. Second, we dramatically improved our techniques for harnessing these models — steering them, scaling them, and stacking them to generate large amounts of signal and filter out the noise.

During 2025, there were 17-31 security bugs fixed each month. In April 2026, they fixed 423.

 ❄                ❄                ❄                ❄                ❄

Pavel Voronin riffs on Unmesh Joshi’s post on What is Code. He observes that cruft in a codebase (technical debt) has always added friction to software development. But the consequences of this cruft are compounded when LLMs are using existing code as context for future work.

In a degraded codebase, the model does not see “technical debt” as debt. It sees examples. It sees precedent. It sees a style to continue.

LLMs multiply what’s currently happening. I hear reports that good code might take the place of much of what’s put in markdown, because LLMs will imitate what’s already in the code base. But bad code multiplies too. Inevitably he introduces another variation of rampant debt metaphors:

Cognitive debt accumulates when a team uses abstractions it no longer understands. Generative debt accumulates when a codebase contains confused concepts that models are likely to continue.

Cognitive debt is about what the team no longer understands. Generative debt is about what the model is now likely to reproduce.

 ❄                ❄                ❄                ❄                ❄

Jason Koebler, from the very worthwhile 404 media, has written a plaintive essay on how AI-generated slop is driving us crazy. Not just because its filling the web with this slop, but also because how it’s making us humans react to slop and the threat of slop. We review our own writing and notice: it’s not just reading AI slop that hurts us, it’s the risk that we write something that looks like AI slop. If I use phrasing that AI copied from me, does it seem like I’m copying AI? This has led to the appearance of “humanizers” - AI tools that make our writing look less like AI.

Humanizers add typos, randomly replaces words, removes “AI tells,” and sometimes inserts random characters.

It’s another step on the way to the Zombie internet:

I called it the Zombie Internet because the truth is that large parts of the internet are not just bots talking to bots or bots talking to people. It’s people talking to bots, people talking to people, people creating “AI agents” and then instructing them to interact with people. […] It’s my email inbox, in which I used to occasionally get poorly-formatted, poorly written, extremely long emails from delusional people who were positive the CIA had imprisoned them in a virtual torture chamber using undisclosed secret technology but where I now get well-formatted, passably written, extremely long emails from delusional people who are positive they have proven AI sentience and have the AI transcripts to prove it.

 ❄                ❄                ❄                ❄                ❄

Andy Osmani points out that spawning lots of agents is like launching a bunch of parallel processes that all rely on a single orchestrating thread - yourself.

Python has the Global Interpreter Lock (GIL). You can spawn as many threads as you want but only one executes python bytecode at a time because they must acquire the lock. You are the GIL of your AI agents. They all can run at once. But when any of their work needs genuine understanding of the architecture or resolving merge conflicts, that work has to acquire the lock. There is one lock. You hold it.

This means you must design the workflow with the agents with that GIL in mind. You shouldn’t launch more agents than you can properly review. It’s handy to separate background tasks that can be offloaded to an agent from complex tasks that require applied attention. Don’t use that precious brain for things that the machine can verify itself. [And I’d add - do get the machine to build tools that ease human verification. For example, it’s better to surface test case data in tables rather than buried in assert statements.]

Spawning agents is not the skill. Anyone can run 20.

The real skill is designing the system around the one serial resource that cannot be cloned or parallelized. That resource is your attention.

 ❄                ❄                ❄                ❄                ❄

Jamie Hurst is a Principal Engineer at booking.com, where he works in developer experience with a focus on AI tooling. He’s written realistically about the gains and losses of using LLMs in this work.

The cost of building has collapsed, but the cost of aligning organisationally has not. If anything, it’s gone up. When three different teams can each produce a working solution to the same problem in the time it used to take to write a proposal, the bottleneck moves from engineering to coordination.

He thinks he’s able to do more as a senior engineer, but is concerned about how sustainable it is, both for him personally and for the organization he works for. He’s able to shape directions for multiple workstreams at once, in a way that he couldn’t three years ago. But one loss is that he doesn’t have enough time for mentoring, which will exact a toll on his employer in the longer term. He also finds he doesn’t have enough time to think.

The productivity gains from AI got captured by output volume rather than output quality. The org’s expectations rose to absorb the speed-up, and the slack that used to exist between tasks, the unstructured time where strategic thinking actually happens, got eaten first because it’s invisible on a dashboard. I’m at a point in my career where thinking is supposed to be most of the job, and most of it now happens on holiday because the working week doesn’t accommodate it.