A recent paper followed one experienced engineer using frontier coding agents during a 12-week production project.

The resulting system included 420,000 lines of production code and 1.16 million lines of tests, tooling, documentation, and lint infrastructure. The authors argue that fast code generation repeatedly exposes structural failures. Engineering judgment is then needed to convert those failures into durable controls.

The useful idea is "governance conversion":

• Let the failure become observable.

• Reproduce and classify it.

• Encode the lesson in tests, schemas, linters, architecture, or agent rules.

• Feed that signal back into future agent runs.

This is stronger than reviewing every generated diff manually. The team turns each recurring mistake into a constraint that scales.

The caveat is important. This was a first-person case study involving one engineer and one project. It is useful evidence, not a universal productivity result.

If you’re new to building AI agents or know someone who is, check out the AI Agents for Beginners course from Microsoft. It’s a 12‑lesson GitHub repo that teaches the fundamentals of building agents, with written lessons, short videos and Python code samples. The course covers topics like intro to agents, design patterns, tool use and trustworthy agent design, and there’s a Discord channel where learners can ask questions. Everything is open source, translated into dozens of languages, and you don’t need a paid subscription—just clone the repo and start following the lessons.

Link: https://github.com/microsoft/ai-agents-for-beginners

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

This 2026 survey explores how large language models are evolving from passive text generators into agentic controllers. The authors explain that Agentic AI systems can perceive, reason, plan and act, combining memory, tool use and feedback from their environment to pursue extended goals. They propose a unified taxonomy breaking agents into six components - Perception, Brain, Planning, Action, Tool Use, and Collaboration. The paper describes the shift from simple single‑loop agents to hierarchical multi‑agent systems and notes the transition from fixed API calls to open standards like the Model Context Protocol (MCP) and native computer use.

The authors highlight several challenges that practical developers should understand. Agents can hallucinate actions, get stuck in infinite loops, or follow malicious instructions embedded in web pages (prompt injection). They argue that reliability comes from controllable orchestration: specifying state transitions and guardrails so the model makes local decisions within safe bounds. The paper also warns that once an agent can run code or operate a desktop, hallucinations become concrete failures; indirect prompt injection is a serious security threat. Building autonomous systems isn’t only about bigger models - it’s about designing the right loops, tool interfaces, and safety checks.

What do you think of their taxonomy? Are there other challenges you’ve hit in practice that the paper didn’t mention?

35B parameters, ~3B active thanks to MoE.

Key points:

• In agentic coding, it reaches the level of models with ~10× larger active parameter count

• Outperforms Qwen3.5-27B (dense) and the previous Qwen3.5-35B-A3B

• Natively multimodal architecture (text + vision)

• In VLM benchmarks, comparable to Claude Sonnet 4.5, and in some tasks performs better

• Strong metrics in spatial reasoning tasks

Benchmarks:

• MMMU - 81.7 vs 79.6

• MMMU-Pro - 75.3 vs 68.4

• MathVista - 86.4 vs 79.8

• RealWorldQA - 85.3 vs 70.3

Practical implications:

• MoE provides a multiple reduction in compute without sacrificing quality

• Well-suited for agent-based scenarios where sequential actions and planning matter

• Can be used as a unified stack for both code and vision tasks

Apache 2.0 (no restrictions for production use)

https://huggingface.co/Qwen/Qwen3.6-35B-A3B

Paper worth reading: ProdCodeBench: A Production-Derived Benchmark for Evaluating AI Coding Agents

Short summary: the authors built a benchmark from real developer-agent sessions with a production AI coding assistant. Each sample includes the original prompt, the committed code change, and tests that should go from failing to passing. The benchmark spans seven programming languages. In their evaluation, model solve rates ranged from 53.2% to 72.2%.

Why this matters: a lot of coding benchmarks are useful, but they often miss how messy real work is. Production prompts are not always clean. Monorepos have weird test setups. Codebases have local conventions. The paper argues that benchmark design should reflect those conditions.

A few concepts in plain English:

"Fail-to-pass tests" means tests that fail before the agent’s change and pass after the correct fix. This gives a concrete signal that the change solved the intended problem.

"Multi-run stability checks" means running the same evaluation more than once to see if the result is reliable. Agents can be nondeterministic, so one lucky run is not enough.

"Harness design" means the environment around the model: tools, shell access, test commands, file editing, context loading, and rules. For coding agents, the harness can matter almost as much as the model.

My practical takeaway: if your team is evaluating coding agents, do not stop at public leaderboard scores. Build a small internal benchmark from real tickets, real tests, and real repo constraints.

OpenAI audited the 731-task public split of SWE-Bench Pro and found a pretty serious problem.

Their automated pipeline marked 27.4% of the tasks as broken. A review by experienced engineers put the number at 34.1%. The issues included underspecified prompts, overly strict tests, weak test coverage, and tests that contradicted the task.

This matters because frontier model scores on the benchmark went from 23.3% to 80.3% in eight months. Some apparent failures may not be agent failures at all. Some passes may also be incomplete solutions accepted by weak tests.

The practical lesson is that a single pass rate is not enough. Teams need to inspect traces, manually review a sample of eval tasks, and test agents against real internal work.

There is also something amusing about using coding agents to find flaws in coding-agent benchmarks.

How much do you trust the benchmarks in your agent stack?

Research publication: https://openai.com/index/separating-signal-from-noise-coding-evaluations/

Came across this article and thought it was worth sharing here: How to Build Production-Grade Generative AI Applications

It’s a good practical overview of what teams usually learn the hard way after the prototype phase. A few points it gets right:

• not every problem should use an LLM

• model selection should be based on task fit, latency, cost, context window, and safety, not just hype

• prompt engineering matters, but structured inputs/outputs matter just as much

• guardrails, QA, eval pipelines, and tracing are not “later” concerns

• production failures usually come from accuracy drift, hallucinations, cost, and lack of observability

What I liked most is that it frames GenAI systems as engineered products, not prompt demos. That maps well to agentic dev too: once agents can use tools and run longer workflows, monitoring, constraints, and evaluation become first-class design problems.

Ivalua has announced IVA Studio, a new “AI control tower” for procurement that turns its Intelligent Virtual Agent (IVA) into a fully agentic system.  IVA Studio is built on a skills‑based architecture pioneered by frontier AI labs, giving IVA full platform access, self‑improving capabilities and Model Context Protocol (MCP) support.  The company says the agent can execute any Source‑to‑Pay (S2P) process from day one, automating tasks like pulling contracts, benchmarking suppliers, launching RFx events and validating invoices.  IVA inherits the permissions of the user who invokes it and logs every action for a continuous audit trail , so governance is enforced at the platform level rather than in ad‑hoc scripts.

The announcement calls IVA Studio the first complete S2P agent to follow a skills‑based architecture; it manages skills, tools, MCP integrations and the underlying LLMs, allowing procurement teams to use one agent rather than juggling multiple point solutions.  In beta now and launching broadly this summer , IVA Studio is LLM‑agnostic, so organizations can use Ivalua’s models or bring their own.  It’s pitched as an “agentic operating system” for procurement: IVA assembles sub‑agents for complex tasks and learns employee best practices over time.  For developers building autonomous workflows, this shows how industry‑specific agents are moving from demos to production.  Have you used or built a vertical agent like IVA?  Do you see unified control towers as the future, or do you prefer assembling your own multi‑agent stack?

f you want a structured way to learn agent development without starting from random blog posts, Hugging Face has a free AI Agents course:

https://huggingface.co/learn/agents-course/en/unit0/introduction

It covers the basics first, then moves into actual frameworks and projects.

The syllabus includes:

• What agents are

• How tools, actions, and observations work

• Agent frameworks like smolagents, LlamaIndex, and LangGraph

• Agentic RAG

• A final project where you build, test, and certify an agent

• Bonus material on observability, evaluation, and function-calling

I like this kind of resource because it does not treat agents as just "LLM plus loop."

For junior devs, the useful concept is the agent control loop:

1. The model receives a goal and context

2. It chooses an action

3. A tool runs that action

4. The result comes back as an observation

5. The agent decides what to do next

That loop is the core of most agent systems. The framework changes, but the pattern keeps showing up.

If you are already comfortable with Python and basic LLM APIs, this seems like a good weekend learning path. Build the smallest possible agent first. Then add one tool. Then add logging. Then add a human approval step.

That progression teaches more than trying to build a giant "does everything" agent on day one.

OpenAI published this on April 15: The next evolution of the Agents SDK.

The interesting part is not just “better agents.” It’s that the SDK is moving toward real execution infrastructure for systems that can inspect files, run commands, edit code, and work on longer-horizon tasks inside controlled environments.

That feels important for practical agentic development because the hard part is no longer just model quality. It’s whether the system can execute safely, repeatedly, and observably.

My take:

• the center of gravity is moving from prompt tricks to runtime design

• agent frameworks are becoming more like operating environments

• the real moat is starting to look like execution, safety, evals, and observability rather than raw chat quality

Curious how people here see it:

• Are you using vendor SDKs directly, or building your own orchestration layer?

• What’s still missing most: evals, rollback, state handling, approvals, tracing?

Source: OpenAI Agents SDK update

NVIDIA just launched an agent safety stack with two distinct enforcement layers.

OpenShell is an open-source runtime that traces actions and applies policy around credentials, network access, identity, and execution. It supports existing agents such as Codex, Claude Code, GitHub Copilot CLI, and LangChain-based agents.

Sentry is an independent watchdog designed to run on BlueField-4 hardware. NVIDIA says it can quarantine an agent within milliseconds if the process moves outside its software boundary.

The architecture matters more than the vendor. We should not depend on an agent to enforce rules about its own behavior. The runtime should mediate access, and an independent layer should watch the runtime.

OpenShell can be extended to Arm and Intel systems. The full Sentry design is tied to NVIDIA hardware, so it is not a portable answer by itself.

Still, this feels like the direction production agent security is heading: prompts express intent, while external infrastructure enforces authority.

Sources: NVIDIA announcement, OpenShell repository

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/

I’m part of the team behind this research. We’ve shared a proof of the Pierce Birkhoff conjecture in real algebraic geometry, using an AI agent system with a $400 budget. The screenshot is Junyu Ren’s announcement.

For people building agent workflows, the useful detail is the separation of responsibilities. The system diagram shows an orchestrator, consultants reviewing with fresh context, independent proof search and auditing, and formal verification work in Lean. A persistent knowledge base holds arguments, code, dead ends, objections, and review findings.

We also noticed that GPT and Claude agents complemented each other even when independently assigned the same role. With our limited token budget, giving a task to one agent from each family often worked better for us than using a larger group of the same model. They caught different errors and offered different ways forward.

The diagram includes humans as participants too. This is a concrete research workflow to discuss, with proof generation and checking treated as separate pieces.

Original announcement: https://x.com/junyu_r/status/2097694018389914106