|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
Artificial intelligence (AI) makes all code write-only,. It’s too dense to read, and tests define the behaviour and become the documentation. Code is also disposable; it becomes easier to rewrite than to debug. Humans can't review AI-generated code at scale. Intent decouples from implementation; developers should focus on creativity.
By Ben Linders
Read Scheduled AI in practice: turning telemetry into a daily health report on timdeschryver.dev
AI tools are gaining features quickly, including the ability to automate recurring tasks on a set schedule. While this sounded useful at first, I did not have a particular use case in mind to put this into practice.
Then I realized that these tasks are not limited to executing a prompt in isolation. They can also use other tools, which makes it possible to build a more complete workflow that tackles a real task. In my case, I wanted to automate the creation of a daily application health report with a summary of frequent failures, slow requests, and notable exceptions.
To know how my application was doing, I frequently looked at data in Azure Application Insights via the Azure portal when I had some spare time and when I thought about it. Then, during a run, it struck me that this was a perfect use case for a scheduled task. So I decided to immediately try it out. It was quickly set up, and the results were surprisingly good with the first run.
To achieve this, I used a combination of the following tools:
The result is a structured daily report containing only the key numbers I care about. It is a simple example of combining several smaller pieces into one workflow.
Once the telemetry connection is in place, the workflow is useful beyond the scheduled report. I can query the same application health data on demand, ask what changed during a specific time window, or investigate a reported problem by requesting the relevant metrics.
Because the task runs within the context of the application, it can point to the relevant code when it finds a problem. It can even suggest a possible solution.
On their own, none of the pieces are new. We could already query the telemetry via the Azure portal or using the Azure CLI, and we could already paste the results into a chat window to ask for a summary (you can easily copy a trace within Azure using the copy button). The missing piece was the schedule. It allows the task to run automatically on a set schedule. Of course, a schedule can also be created separately in a custom application, but it's nice to have it integrated into the AI tool itself, e.g. in Claude, Codex, or Copilot.
What makes the scheduled task interesting is how the pieces reinforce each other:
The daily application health report is a good example because it brings all three pieces together, and for me, it automates the work I was already doing manually.
The idea is simple: run a prompt on a schedule, grant the agent access to the tools it requires to do its job, and turn this into an actionable report with key insights.
In my case, the prompt is a request to create a daily application health report using the Azure Application Insights telemetry from the last 24 hours. Some tools, including Codex, can schedule the task inside an existing chat so each run can use the previous report as context. A standalone task instead needs to query an explicit baseline window or store the previous result somewhere durable. Comparing reports can be helpful to validate that a bugfix actually improved the situation, or to see if a new deployment caused a regression.
I have been experimenting with the scheduling features in Claude Code Routines and Codex Scheduled tasks. GitHub Copilot also has the same capability with Copilot automations. The names and exact setup differ, but overall they act very similarly.
The task can run locally or in the cloud. A local task is useful when it needs access to existing credentials and configuration, while a cloud task can run when your machine is off. However, a cloud execution requires its own credentials and network access, and this is not always possible yet.
For my use case, the task runs locally. This makes it easy to use the existing Azure CLI login and the local configuration that is already available on my machine.
Creating a new recurring task is straightforward. You can manually create the task, or you can start from a chat window and ask the agent to create the task including the prompt.
Depending on the AI tool, you can configure the schedule using a preset or a product-specific recurrence rule, such as a cron expression. You can also configure the tools it has access to and the model to use.
During the creation of the task, you need to provide the prompt that defines the process the task should perform.
After the task has been created, it can also be run on demand.
Just as with a normal prompt, the prompt is the most important part of the task. It defines what the task does, and does not do. It is important to be explicit about the boundaries of the task, especially when it has access to tools.
You can either write the prompt manually, or you can let the agent write a draft version of the prompt that you can then refine. I prefer the latter, because it is often easier to start from a draft than from scratch. Because the agent already has knowledge of the CLI tools and commands, it often can create a first version of the prompt that is already close to what I want.
The prompt should specify what data the task operates on, and how it should summarize and report the results back to you. As a safety measure, keep in mind that the boundary should be enforced by the task configuration and Azure permissions, not only by the prompt. Use a least-privileged identity and expose only the query tools the report needs. Treat telemetry as untrusted input because fields such as request paths, exception messages, traces, and custom dimensions can contain user-controlled values. The prompt should also require sensitive data to be redacted from every section of the report.
The prompt needs to define how it accesses the telemetry data.
In my case, the data comes from Azure Application Insights.
I'm using the Azure CLI to retrieve the telemetry data.
In all fairness, the exact retrieval method doesn't matter much to me, as long as the task can get the data it needs to do its job. The CLI can either invoke a REST endpoint, or use the monitor app-insights commands to execute a query directly against an Application Insights resource.
Instead of the CLI, you could use the Azure MCP Server tools. I prefer the CLI here because it gives me direct control over the query, and the CLI is already familiar to AI models. When using the MCP server, you will need to grant the agent access to the required MCP tools.
Because the task runs locally, it reuses my existing Azure CLI login. For a cloud setup you will need to provide the right permissions.
When the task has finished, the report appears in the run's chat or session. In Codex, a standalone scheduled task starts a new chat for each run, while a task scheduled inside an existing chat returns to that chat and preserves the previous reports as context. Either way, I can continue the conversation with the AI model, ask follow-up questions, and explore the results further.
Here's the version Claude Code and Codex produced for me.
I hope this example inspires you to think about similar use cases. Integrating existing CLI or MCP tools, and using an LLM to do something with the data/output, can be applied to many other scenarios. The scheduling feature allows you to automate the process and get a report on a regular basis, without having to remember to do it manually.
The use case mentioned in this article applies this to create a daily Application Health Report. The biggest benefit for me is not just the report itself, but the ability to continue the conversation with the AI model. I can ask follow-up questions, explore the results, decide on next steps, and get suggestions to resolve a problem. This can also be automated: the task could produce a proposal for each finding, and even create a pull request for it.
Because this process involves a lot of data, it is a good candidate to use AI to summarize the results. Instead of just data points, the report contains a summary of the most important findings, and it highlights the items that require attention. The report is structured in a way that makes it easy to read and understand, and it provides clear actionable insights.
We use AI here as a tool to highlight existing problems, not as a replacement for our own judgment. The agent does not take full control of the process, but it helps me to focus on the most important issues. The output is a starting point for further investigation, and it helps me prioritize work while I'm still responsible for the next steps.
This automation has already saved me time by helping me notice issues such as excessive logging and slow endpoints, and by letting me track the impact of a bugfix.
Even if you don't create an automation, I want you to take away the idea that you can integrate existing tools into your prompt instead of copy-pasting data from one context to the prompt. In the end, this allows you to create a workflow that is more than just a single prompt, or remove the manual steps entirely.
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
"I hope you can feel heard and respected at the end of the day." - Joshua McDonald
Joshua defines Scrum Master success through the team's comfort with self-organization, respectful pushback, and asking for help when they do not know what they do not know. For him, a successful team is not drama-free because nothing hard happens. It is low-drama because people can raise problems without fear, communicate openly, and keep moving forward even on bumpy roads. Joshua keeps himself honest by reviewing retrospective notes, one-on-one notes, and the commitments he made to follow up. He keeps a running to-do list from Slack messages, meetings, and team conversations so feedback does not disappear after someone shares it. Periodically, he brings past retrospectives back to the team and asks what they accomplished, what changed, and whether anything fell through. That ledger matters because Scrum Masters work through people. If people feel heard and respected, they are more likely to keep working with you, regardless of your title.
Self-reflection Question: What system do you use to make sure team feedback turns into visible follow-up?
Joshua's favorite retrospective format is never using the same format twice. He noticed teams getting bored and agitated when the same sailboat or standard board appeared every sprint. His answer was to personalize retrospectives around team members' interests: a BMW theme for a developer who liked cars, a beach theme after someone's vacation, or a TV-show theme tied to a person's hobby. He uses tools like Mural, Zoom whiteboards, Microsoft Teams, and AI-generated visual themes to make each retro feel like it was designed for someone in the team. The point is not decoration. The point is listening. When people recognize their interests in the retro, they feel seen as people before they reflect on the work.
[The Scrum Master Toolbox Podcast Recommends]
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
[The Scrum Master Toolbox Podcast Recommends]
About Joshua McDonald
Joshua is endlessly curious about better ways of working. He helps teams grow by blending experimentation, creativity, and AI with practical coaching. When a meeting feels routine, he's already testing a new approach to make it more valuable. Energetic and inventive, he turns everyday collaboration into opportunities for team growth.
You can link with Joshua McDonald on LinkedIn.
Our free, browser-based Code Editor now keeps working when your internet connection doesn’t. If your connection breaks in the middle of a lesson or a project, you can carry on writing and running your code without disruption, even if the page is reloaded.
An unstable internet connection is a minor annoyance when you’re reading a web page, but it’s a much bigger problem when you’re 20 minutes into creating a program.
Until now, losing your connection while using the Code Editor could mean losing your work: if you refreshed the page at the wrong moment, you might have seen a blank screen or a browser error instead of your program.
When we wanted to understand better what learners and educators around the world need from the Code Editor, we carried out research in countries including India, Kenya, and South Africa. One topic we explored was the availability and reliability of internet connections in metropolitan and rural areas. While it was no surprise that internet access is often slow, unreliable, or expensive in rural areas, we learned that issues related to electricity supply, such as load-shedding and brownouts, are also prevalent in metropolitan areas. All this shapes what is realistically possible in a programming activity using an online editor.
And connectivity issues can occur in any school computing lab where 30 learners are all accessing the same WiFi at once, or for a Code Club running off a mobile hotspot in a community centre, or for someone finishing their homework on patchy mobile data.
That’s why it became a priority for us to improve the Code Editor’s offline support by making it resilient to disconnection.
As we describe in our recently shared draft principles for safe and responsible education technology, one of our commitments is to design for diverse needs, abilities, and contexts — including not to assume constant internet connectivity. This Code Editor update is a small, practical piece of that commitment.
The Code Editor was built with resilience in mind from the start, for example running code in your browser rather than on a server, and saving your project locally on your device as you go.
Our recent additions ensure that once you’ve opened the Code Editor while online, your browser holds on to even more of the parts you need to keep coding without a connection. Now if you go offline midway through using the Editor:
This update is built on a service worker, a script your internet browser runs in the background. When you first load the Code Editor, the service worker stores the files the Editor needs in your browser’s cache. If the network connection then breaks, the service worker serves those stored files instead of trying and failing to fetch them. When you come back online, it automatically refreshes the cache so you’re not left running old files.
The Code Editor isn’t a full offline app that you install. It’s a browser-based app that we have now upgraded to better cope with losing its internet connection, which means:
We’ll keep working to extend what parts of the Editor work offline.
The Code Editor works in your browser with no setup and will always be free for educators and learners. We hope this update makes it more useful for people in lots of different settings.
The update is one of those features some people will never notice, which is rather the point: it should feel like nothing went wrong. If your connection is unreliable and you try out the updated Code Editor, we’d love you to tell us whether or not it works well for you.
We would like to thank Cisco for the generous funding that made this work possible.
The post Keep coding when your internet drops: Offline support in the Code Editor appeared first on Raspberry Pi Foundation.
Sessions now support rewinding conversation history and tracked file changes. Enable file-change tracking when creating a session, then rewind to a previous checkpoint to discard later turns and restore file state. (#2321)
Log in
const session = await client.createSession({ enableFileChangeTracking: true });
const rewindPoints = await session.rpc.rewind.listRewindPoints();
await session.rpc.rewind.rewind({ rewindPointId: rewindPoints[0].rewindPointId });session = await client.create_session(enable_file_change_tracking=True)
rewind_points = await session.rpc.rewind.list_rewind_points()
await session.rpc.rewind.rewind(rewind_point_id=rewind_points[0].rewind_point_id)session, _ := client.CreateSession(ctx, &copilot.SessionOptions{EnableFileChangeTracking: true})
points, _ := session.RPC.Rewind.ListRewindPoints(ctx)
_ = session.RPC.Rewind.Rewind(ctx, &copilot.RewindRequest{RewindPointId: points[0].RewindPointId})var session = await client.CreateSessionAsync(new SessionOptions { EnableFileChangeTracking = true });
var points = await session.Rpc.Rewind.ListRewindPointsAsync();
await session.Rpc.Rewind.RewindAsync(new RewindRequest { RewindPointId = points[0].RewindPointId });SessionOptions options = new SessionOptions().setEnableFileChangeTracking(true);
var session = client.createSession(options).get();
var points = session.getRpc().getRewind().listRewindPoints().get();
session.getRpc().getRewind().rewind(new RewindRequest().setRewindPointId(points.get(0).getRewindPointId())).get();let session = client.create_session(SessionOptions { enable_file_change_tracking: Some(true), ..Default::default() }).await?;
let points = session.rpc.rewind.list_rewind_points().await?;
session.rpc.rewind.rewind(RewindRequest { rewind_point_id: points[0].rewind_point_id.clone() }).await?;The Java SDK now supports an in-process connection mode on linux-x64 that loads the Copilot runtime as a native library via JNA — no separate CLI child process required. Add the copilot-sdk-java-runtime classifier JAR for your platform alongside the core SDK JAR. (#2301)
CopilotClientOptions options = new CopilotClientOptions()
.setConnection(RuntimeConnection.forInProcess());
CopilotClient client = new CopilotClient(options);
client.start().get();Permission handlers can now attach decisionContext so the runtime can attribute whether a decision came from a person, host policy, or an automated recommendation. This is additive for all SDKs. Note for Rust: PermissionResult::Decision changed from a tuple variant to a struct variant — callers that construct or match it directly must migrate. (#2294)
return createAttributedPermissionResult("allow_once", { source: "user" });return copilot.create_attributed_permission_result("allow_once", context)return copilot.NewAttributedPermissionResult("allow_once", context)return new PermissionDecision { Result = "allow_once", DecisionContext = context };return PermissionRequestResult.approveOnce().setDecisionContext(context);return PermissionResult::Decision { decision: PermissionDecision::ApproveOnce, context: Some(ctx) };Hosts can now register a trusted set of host-bundled plugin directories that are loaded before any session is created, distinct from user-managed --plugin-dir directories. (#2330)
Node extensions can now pass an env option to joinSession() listing the sensitive environment variable names they need. The CLI prompts the user for approval; if granted, the variables are written into the extension process before joinSession() resolves. (#2348)
await joinSession({ env: ["MY_SECRET_TOKEN", "API_KEY"] });argsSchema supportFactoryMeta now exposes an optional argsSchema field so factory authors can declare the argument shape their factory expects. The CLI validates call arguments against the schema before starting a run, surfacing malformed calls early without consuming credits. (#2315)
session.defineFactory("my-factory", { argsSchema: { type: "object", properties: { query: { type: "string" } } } }, async (ctx) => { /* ... */ });Client is dropped (#2292)FactoryResult/FactoryArguments now typed as JsonValue, ctx.agent() forwards reasoningEffort and contextTier, resume error union trimmed to real codes (#2309)@lutzroeder made their first contribution in #2330@aymenfurter made their first contribution in #2294@lukehoban made their first contribution in #2292Generated by Release Changelog Generator · sonnet46 37.7 AIC · ⌖ 5.53 AIC · ⊞ 8.1K
Felix Rieseberg came to computing through poetry, and that background gives him a unique lens for explaining language models. A longtime engineer, Felix now gets to watch AI evolve from the inside. In this episode, Scott and Felix explore why language models are surprisingly easy to understand despite feeling magical, what it's like to train a model from noise to coherence, and the bigger philosophical questions about intelligence that AI keeps surfacing. You can learn how AI really works by making your own in a weekend with his free site below.
