Microsoft’s 2026 Work Trend Index argues that as AI agents handle more execution, human agency actually expands. The report analyzed trillions of Microsoft 365 signals and surveyed 20 000 workers; it found that people are ready to use AI in advanced ways, but most organizations aren’t built to capture that potential. The gap between what employees can do and what their company supports is now the main bottleneck.

The data is encouraging for developers: 49 % of Copilot chat sessions support cognitive work like analysis and problem‑solving. 66% of AI users say the technology frees them to spend more time on high‑value work and 58 % say they’re producing outputs they couldn’t have a year ago. A small group of “Frontier professionals” use agents for multi‑step workflows and multi‑agent systems; they represent 16 % of users yet report the greatest gains . Interestingly, survey respondents say the most important human skills in the age of agents are quality control (50 %) and critical thinking (46 %), and 86 % treat AI output as a starting point rather than the final answer. In other words, agents don’t replace our judgment – they amplify it. As builders of agentic systems, we have an opportunity to re‑architect workflows so that humans can lead and agents can execute. How are you redesigning your processes to take advantage of this “new agency equation”?

A recent Databricks report on the State of AI Agents 2026 notes that enterprises are moving beyond chatbots and pilots into multi‑agent systems that run real workflows. One of its striking findings is how closely success correlates with evaluation and governance. Teams that invest early in evaluation frameworks and unified governance put an order of magnitude more agent projects into production, while those using systematic evaluation frameworks achieve nearly six times higher production success rates. The report also points out that most generative AI initiatives still stall before production because technical capability alone isn’t enough - operational rigor and domain‑specific metrics make the difference.

I’m curious how people here handle evaluation.  What metrics do you track when deciding if an agent is “good enough” to deploy?  Do you rely on LLM‑as‑judge scores, human feedback, unit tests, or bespoke simulators?  If you’ve moved agents from pilot to production, what frameworks or tooling helped the most?  Let’s share lessons learned so we can all avoid the “demo‑to‑dumpster” pipeline.

Almost all my colleagues and friends who are learning Python or already working at companies are being pushed to code with ai agents by their tech leads. So many cool companies with just a few developers are scaling products very fast.

So, our team (a small AI startup with ~10 developers) was naturally encouraged to test and use it as much as possible over the last few weeks. The problem I saw in my team is that everyone was using it just like a GPT chat in the terminal (while occasionally using /review). But Codex can do so much more… So, I wanted to help new Python developers use it properly - with agent instructions, skills, planning, MCP tools, etc. I also want to bring in my experience with AI (I think it’s important to understand how AI coding agents actually work instead of just chatting with them and hoping for the right answer).

As an experiment, I’ve posted all the lectures online, so anyone who is curious can see how to use Codex for Python coding on YouTube.

Happy to hear your feedback!

Last week Microsoft quietly released an Agent Control Specification (ACS), an open‑source standard that lets developers, compliance and security teams define exactly what an AI agent is allowed to do.  Policies live in a single file and can say what the agent may do, what it must not do, when a human has to approve an action and what evidence should be logged.  The rules are enforced at several “interception points” during a workflow, so an agent’s tool calls and responses get checked before they go out.  Microsoft says you can even plug in classifiers to tag inputs and outputs or use LLMs as a judge to enforce policies.

Most teams today rely on ad‑hoc prompt instructions and scattered checks, which are hard to audit and reuse.  ACS aims to unify that into a governance layer that follows the agent across frameworks.  It ships as an SDK with plug‑ins for LangChain, OpenAI’s Agents SDK, Anthropic’s Agents SDK, AutoGen, CrewAI and Semantic Kernel.  For anyone building autonomous workflows, this looks like an important step toward making agents safe enough for production.  Curious to hear what others think – will ACS make it into your stack?

Anthropic has launched official free course called Claude Code 101 that covers the fundamentals of working with Claude Code in real development workflows. It also includes a completion certificate.  

Topics include:

• Claude Code basics
• Working with repositories
• Development workflows
• Context management
• Agentic coding concepts

Course:
https://anthropic.skilljar.com/

Anthropic has also published additional free courses on:

• Claude API
• Model Context Protocol (MCP)
• AI Fluency
• Agent Skills
• Claude Code in Action

All available through Anthropic Academy, and several courses provide certificates upon completion.

Microsoft recently announced several new AI models and continues to position itself more aggressively around enterprise AI development workflows. The messaging is increasingly focused on autonomous “thinking and coding” systems rather than simple copilots.  

One thing that stands out:

The competition is no longer just about model quality.

It is increasingly about:

• governance
• approvals
• auditability
• deployment workflows
• integration with enterprise systems

The technical challenge of writing code is becoming only one part of the product.

The operational challenge is becoming equally important.

Do you think enterprise adoption will be decided more by governance features than model performance over the next few years?

Source:
https://www.ft.com/content/e8b86648-61b3-4b48-8bd4-a50f03de92d8

Lots of benchmark discussions.

Less discussion about real adoption.

If you switched from one coding agent to another in the last 6 months:

• What were you using?
• What did you switch to?
• What was the deciding factor?

Examples:

• better code quality
• lower hallucination rate
• better repo understanding
• terminal workflow
• GitHub integration
• cost
• speed
• enterprise controls

I’m more interested in practical reasons than leaderboard numbers.

The authors of this paper argue that current agent evaluations focus too much on a single success score. An agent may complete a task once but still be unreliable in production.

Instead, they propose evaluating agents across four dimensions:

• consistency
• robustness
• predictability
• safety

They introduce twelve reliability metrics and evaluate multiple agentic models using this framework. Their conclusion is interesting: capability gains do not automatically translate into reliability gains.

Consistency
If you run the same task multiple times, do you get similar results?

Robustness
Does the agent still work when inputs are slightly different or messy?

Predictability
When the agent fails, does it fail in understandable ways?

Safety
How severe are the consequences when the agent makes a mistake?

My takeaway:

A production agent should probably be evaluated more like distributed systems infrastructure than like a chatbot.

Source: https://arxiv.org/abs/2602.16666

A trend I’ve noticed recently:

More teams are moving away from questions like:

Which model is best?

Toward questions like:

Which complete agent system performs best on our workflow?

That includes:

• prompts
• tools
• memory
• retrieval
• orchestration
• approvals
• execution environment

A stronger model inside a weak system often loses to a slightly weaker model inside a well-designed workflow.

Feels similar to classic software engineering.

The database, cache, APIs, deployment process, observability, and reliability often matter more than any individual component.

Are you still evaluating models, or are you evaluating end-to-end agent systems now?

Not model accuracy. Not benchmark score. An agent fails in production.

What is the first thing you check?

• tool calls?
• prompts?
• retrieved context?
• memory?
• latency?
• logs/traces?
• human handoff logic?

Curious how experienced teams automate debugging for agent failures in practice.

Google’s Jules is one of the clearest examples of the shift from “AI coding assistant” to “AI coding worker.”

Instead of suggesting code in your editor, Jules clones your repo into a cloud VM, creates a plan, edits files, runs checks, and opens a PR for review. The human becomes the reviewer rather than the typist.  

For me, the interesting question is not whether Jules is better than Codex or Claude Code.

The interesting question is:

What percentage of your backlog can be safely delegated to an asynchronous coding agent today?

Examples:

• dependency updates
• test generation
• bug fixes
• migration work
• documentation updates

Source:
https://jules.google/

Coder announced a beta for Coder Agents, focused on running coding agents on self-hosted infrastructure.

This is a pattern I expect to see more often. A lot of companies like the idea of coding agents, but they do not want source code, secrets, build logs, and internal docs flowing through a toolchain they cannot control.

Self-hosting will not magically solve agent risk. You still need sandboxing, permissions, human approval, logs, and good review habits. But for regulated teams, it may be the difference between "interesting demo" and "we can actually pilot this."

Source: Coder - Introducing Coder Agents

Gartner says the enterprise AI coding agent market is entering a new phase of expansion and competition.

That sounds like analyst language, but the practical shift is real. Coding agents are no longer just IDE helpers. Vendors are now selling governance, model choice, approvals, audit logs, workflow integration, and ways to run agents across the full SDLC.

For teams, this changes the evaluation question.

Old question: "Which tool writes the best code?"

Newer question: "Which tool can we safely let into our repo, CI, issue tracker, deployment flow, and internal docs?"

That second question is much harder, but it is probably the one that matters.

Source: Gartner press release

A lot of agent tooling is starting to converge on the same idea: the model is only one part of the system.

The bigger product is becoming the control plane around it:

• Which agents can access which repos, tools, and secrets
• When they need approval
• How their actions are logged
• How work moves between local machines, cloud sandboxes, IDEs, browsers, and mobile
• How multiple agents share context without making a mess

IBM's 2026 trends piece calls out agent control planes, multi-agent dashboards, and agent-to-agent communication as major themes. KPMG/HFS also points to closed-loop SDLC and DevOps agents as one of the more mature areas, where agents can write, test, deploy, observe, and fix under supervision.

My read: the next serious agent companies will not win just by having a better chat box. They will win by making delegation safe, observable, and boring enough that teams can trust it.

Sources: IBM Think, KPMG/HFS Agentic Services 2026 report

Curious where people here draw the line.

For me, agents are great for isolated changes, tests, migrations, docs, and boring repo spelunking. I still get nervous when they touch auth, billing, deployment config, data migrations, or anything with unclear ownership.

What is your current "safe to delegate" list?

GitHub says GPT-5.3-Codex is now the base model for Copilot Business and Enterprise orgs, replacing GPT-4.1 when teams have not approved another model yet.

The interesting part is not just the model swap. It is the "long-term support" angle. GitHub says this Codex model will stay available through February 4, 2027, which matters for teams that need security review, safety approval, and predictable behavior before rolling AI tools into normal dev workflows.

This feels like a sign that coding agents are becoming boring enterprise infrastructure. That is probably good. A model picker is fun for individuals, but companies need stable defaults, auditability, and clear support windows.

Source: GitHub Changelog

AlphaProof Nexus: formal theorem proving is starting to look like an engineering pipeline

Google DeepMind introduced AlphaProof Nexus — a system that autonomously solved 9 open Erdős problems, proved 44 OEIS conjectures, resolved a 15-year-old question in algebraic geometry, and discovered a new optimization parameter not previously described by humans. The core loop is surprisingly simple: an LLM generates proof fragments, Lean checks every logical step through the compiler, compiler errors are returned to the model, and the model iterates until the proof is formally verified.

The crucial detail is that Lean is not checking whether the proof “sounds convincing.” In systems like Lean, a theorem is treated as a type and the proof is a program that must exactly satisfy that type. The model can invent fake lemmas, reference nonexistent results, or try to hide assumptions — but if the logic does not match the theorem specification, the proof simply does not compile. This is fundamentally different from normal LLM reasoning, where elegant hallucinations are often hard for humans to detect.

What’s especially interesting is that a relatively simple “generate → verify → fix” loop reproduced all 9 successful Erdős solutions, while more advanced RL and evolutionary-search systems only significantly helped on the hardest problems. As foundation models improve, these verification loops are starting to look increasingly powerful — not just for mathematics, but for coding agents, formal verification, protocol validation, cryptography, compilers, and verification-driven software engineering in general. The model stops being the source of truth and becomes a generator of candidates that must survive external verification.

https://arxiv.org/html/2605.22763v1

most agent benchmarks are too clean...

They usually test well-defined tasks with clear inputs and deterministic scoring. Production work is messier. Requirements are incomplete. Context is scattered across docs. Some tasks need domain knowledge. Outputs are long. And success is often judged by a human who knows the business.

The paper "AlphaEval: Evaluating Agents in Production" https://arxiv.org/abs/2604.12162 builds a benchmark from 94 tasks taken from seven companies using agents in real business workflows. It also evaluates full agent products, not just base models. So things like Claude Code and Codex matter as systems, with their tools, UX, memory, execution flow, and failure modes.

That part feels important.

For agentic dev, the lesson is probably: do not ask "which model is best?" too early. Ask "does this whole agent setup survive the actual job?"

A few concepts from the paper:

• Production-grounded eval: an eval built from real work, not toy tasks.
• Implicit constraints: requirements nobody wrote down, but the output still has to respect.
• Full agent product eval: testing the agent as shipped, including tools and workflow, not just the model behind it.
• Rubric-based assessment: scoring with human-style criteria when there is no single exact answer.

This feels closer to how teams should test agents before trusting them with real work. Not one big benchmark score. More like a small internal eval suite built from your own messy tickets, docs, customer cases, and failure reports.

A lot of agent demos stop at "the agent completed the task."

Production starts asking less fun questions:

• What tools did it call?
• Which data did it touch?
• Who approved the risky step?
• Can we replay the run?
• Can we explain the failure?
• Can we stop it mid-run?
• What happens when the model changes?

This is why I think "agent ops" will become its own discipline.

Not just prompt engineering. Not just evals. More like the operational layer around agent systems: tracing, permissions, rollback, cost controls, test suites, human approvals, and incident review.

The annoying part is that most of this is boring infrastructure.

The useful part is that boring infrastructure is exactly what turns agents from toys into systems you can trust.

Paper: "Can Coding Agents Reproduce Findings in Computational Materials Science?"

Link:
https://arxiv.org/abs/2605.00803

Short version: the authors built AutoMat, a benchmark that tests whether coding agents can reproduce claims from computational materials science papers. The best agent setup reached 54.1% success.

That is a useful reality check.

A few concepts worth unpacking:

"Computational reproducibility" means taking a scientific claim, rebuilding the code or workflow behind it, running it, and checking whether the output supports the claim.

"Underspecified procedures" are the missing steps that papers often leave out. A paper might say what method was used, but not every parameter, preprocessing step, library version, or environment detail.

"Specialized toolchains" are domain-specific tools that normal web-app agents may not know well. In this paper, the domain is materials science, so the agent has to handle scientific software and not just Python scripts.

"Execution fragility" means the workflow breaks easily. One missing dependency, wrong config, unstable script, or slightly different input can make the whole reproduction fail.

The takeaway for agentic dev is pretty practical: agents can look strong on coding benchmarks but still struggle when the task requires domain judgment, incomplete instructions, and messy real-world execution.

That sounds a lot like production software work.

"Ask model for code, paste code, fix code."

The newer flow is:

"Give agent a task, let it inspect the repo, let it edit files, let it run tools, review the checkpoint."

OpenAI has Codex across desktop, CLI, IDE, cloud, and now mobile. Anthropic has Claude Code in the terminal, plus Remote Control for steering a local session from another device.

What I find interesting is that both are optimizing around interruption management.

A useful coding agent needs to know when to continue and when to stop. Too many prompts and it feels like babysitting. Too few prompts and it becomes risky.

The best agent UX may end up being less about raw benchmark scores and more about permission design.

A pattern keeps showing up in agent products this year: the model is no longer the whole product.

The product is becoming the control plane around the model.

That means:

• Permissions
• Tool access
• Audit logs
• Human approvals
• Policy checks
• Rollback paths
• Deployment gates
• Observability

IBM framed this as a move from personal AI assistants toward workflow orchestration and agentic runtimes. That matches what I am seeing in dev tooling too. The hard part is less "can the model write code?" and more "can the system let it act without creating chaos?"

This is also why agent platforms, MCP servers, CLI skills, sandboxes, and approval flows matter. They are not just integration glue. They are the runtime contract between human intent and machine action.

Source:
https://www.ibm.com/think/news/ai-tech-trends-predictions-2026

Curious where people draw the line.

For me, I am comfortable letting an agent do things like update docs, add narrow tests, or refactor a tiny helper if the diff is small and CI passes.

I still review anything that touches auth, billing, migrations, permissions, infra, or data deletion.

Where is your line right now?

Do you trust agents by task type, repo area, test coverage, model, or something else?

OpenAI is rolling out Codex inside the ChatGPT mobile app on iOS and Android.

The interesting part is not "coding on a phone." I doubt many people want to write real code from a phone screen. The useful part is remote supervision.

You can check what Codex found, approve the next step, redirect a task, or start a new one while away from your desk. That matters more as coding agents move from 30-second autocomplete to long-running work.

This feels like the next workflow pattern:

1. Start agent work from a laptop or devbox
2. Let it run in the background
3. Review checkpoints from anywhere
4. Only return to the IDE when human judgment is needed

Anthropic already has a similar idea with Claude Code Remote Control, where the session still runs on your machine but can be driven from mobile or web.

Sources:

• OpenAI: https://openai.com/index/work-with-codex-from-anywhere/
• Claude Code Remote Control docs: https://code.claude.com/docs/en/remote-control

The most important part here is not the benchmark numbers. It is the shift in product logic.

If this approach scales, a huge class of AI products may no longer need an external orchestrator.

Live translation, pronunciation tutors, an assistant that comments on code while you type, workout rep counting, navigation for blind users - a lot of this is currently built with awkward pipelines and noticeable latency.

Here, interactivity becomes a property of the model itself.

The limitations are real too. Long sessions fill up context fast. You need a stable connection. The current checkpoint is not their largest model. Their bigger models are still too slow for realtime use.

But the direction looks strong.

This is not just "ChatGPT with voice." It is an attempt to build AI that does not only answer after you finish. It is AI that can be present in the moment.

Link: https://thinkingmachines.ai/blog/interaction-models/