Often agentic loops are especially applicable in diverse domains. In healthcare, a patient chart review requires querying multiple systems, cross-referencing drug interactions, and reasoning across clinical history. In legal work, a contract review needs case law search, clause comparison, and conflict detection — not to mention that you may want to bring in significant client context. The loop exists because these problems are hard to solve with workflow-based designs.

Independent of workflow vs. agentic approach, scenario-based evals are the right approach for domain-specific applications. Each scenario is a specific input — a patient chart, a contract, a claims record — paired with an expert-defined expected outcome. Did the agent identify the medication interaction? Did it flag the indemnification clause? Did it reach the correct coverage classification? Did it ask the right questions and not ask ones it already had access to through context?

Why standard evals break for loops

Workflow-based implementations could test each step in isolation: given this input, does it produce the correct output to pass forward? In agentic loops, that no longer holds. The agent has autonomy over sequencing, and the order of operations may vary across sessions. Tool calls may fail or return unexpected results that the agent reasons past without flagging. An output-only eval catches none of it.

The non-determinism problem in domain evals

Here is where it gets genuinely hard. Evals are specific to a given scenario, but the agent’s path through that scenario is not fixed. Different sessions may pull different chunks from the retrieval system. The conversation may branch differently. The agent may reach the right conclusion through a different sequence of tool calls.

The way to handle this is to separate what you are actually testing. For the output layer, test the conclusion: did the agent identify the issue that matters? For the trajectory layer, test the key decision points: did it retrieve the document that contains the interaction? Did it call the drug lookup tool? Did it pass the correct patient ID? Trajectory evals do not require the agent to take an identical path every time. They require that the path passed through the checkpoints that justify the conclusion.

A case where the agent arrived at the right answer but skipped a critical tool call should not pass. That is not a correct evaluation. It is a lucky guess that will fail on the next prompt change.

How to start building this

You do not need a complete scenario library to get started.

• Start with production failures. Any trace where the agent reached a wrong conclusion, missed an issue, or called the wrong tool is a scenario waiting to be labeled. Get a domain expert to define correct behavior for that case and add it to the set. Five real failures are worth more than fifty synthetic happy-path cases.
• Write trajectory checkpoints, not just output assertions. For each scenario, identify the one or two tool calls or retrieval steps that are load-bearing. Test that those happened correctly and with the right parameters.
• Make “correct” explicit. Not a matching string, but a rubric: what must the output include, what must it not include, what tool calls must appear in the trace.
• Run evals on every significant change. Every prompt update, model upgrade, or tool integration should trigger a full scenario run. If scores drop, you do not ship.

The judge is itself a component to evaluate

Using LLM-as-judge to score outputs at scale is essential, but treat the judge as a component in your eval system, not a fixed oracle. Like every other component, it can drift. After a model update, your judge’s behavior may shift in ways you have not noticed. Build a calibration set for the judge: a sample of cases with human expert labels. Run the judge against them periodically and watch for divergence. When judge scores and expert scores disagree consistently, that is a signal. Either the judge has drifted, or your calibration set no longer reflects the scenarios the agent actually handles.

Treating the judge as infallible leads to calibration debt that accumulates invisibly and surfaces as production failures nobody predicted.

Reading list

• AI Agent Evaluations: A Developer’s Practical Guide (MLflow, 2025/2026) — Good on what specifically changes when you move from LLM to agent evals. The 75% judge-human agreement threshold as a recalibration trigger is a practical heuristic worth adopting. Apache-licensed tooling, no paywall.
• Evaluations for the Agentic World (QuantumBlack, January 2026) — Two detailed client case studies in regulated industries, a European telco and a European bank, covering trajectory validation, SME review as an eval layer, and continuous quality monitoring. The most concrete multi-agent eval case studies available in a public piece.
• A Pragmatic Guide to LLM Evals for Devs (Pragmatic Engineer, 2025) — The best starting point for teams new to systematic evals. Covers why LLM non-determinism breaks traditional testing and how to build a minimal eval suite that actually catches regressions. The golden dataset construction section is directly applicable to domain-specific scenario libraries.
• A Methodical Approach to Agent Evaluation (Google Cloud, November 2025) — The cleanest structural framework I have found: three pillars covering final output quality, trajectory analysis, and trust/safety. Worth reading specifically for the section on building a golden dataset when you do not yet have one. The Vertex AI mention at the end is a brief plug; the framework itself is tool-agnostic.
• Awesome-Evals (BenchFlow, GitHub) — A curated library of papers, blog posts, tools, and benchmarks organized by topic. Useful if you want to go deeper on any specific area: tool-calling evals, LLM-as-judge calibration, multi-agent evaluation. The “non-BS” framing in the description is accurate.

Wikis and similar systems — Confluence, Notion, and the rest — are orthogonal to the system itself. Pages fall behind quickly, because updating them is secondary labor. In a traditional SDLC, this isn’t the end of the world. Humans can just ignore out-of-date documentation, and rely on the bits they know to be reliable, filling in the gaps by asking their manager or emailing the product team. An agent won’t do that! A copy and paste from outdated docs will be treated as 100% true by an agent.

Ultimately, this is less a model problem than a documentation and memory problem.

The repository as the system of record

One solution to this problem is to make the repository the system of record. Requirements and rationales live alongside the modules they describe, and git history and PR comments explain what changed along the way. Jira and Confluence shift from being the source of truth to useful reports generated from what lives in the repo.

Several forces stack in favor of this locality, especially with agents in the loop. The simplest is colocation: docs that live next to src/billing/ change when billing changes. Local docs aren’t orthogonal to the work the way wiki articles are. And because they ride the same branches, the honesty machinery you already run (pull requests, human and agent review, CI checks, linters) can govern documentation too.

Locality also changes what a diagram is worth. A box-and-arrow PNG in Confluence is opaque to an agent, but a Mermaid flowchart beside the service entrypoint shows up in the diff and can be read by the tools. Underneath all of this is a question of what the artifact is optimized for. When agents and engineers reason about a change, the question is usually what a module does and what must not break, not where the payments wiki lives. A repository is organized around that question; a topical wiki fights it.

Karpathy’s markdown library: compile, don’t chunk

We’re not the only ones thinking this way. Andrej Karpathy recently described an approach to building an LLM knowledge base that bypasses classic RAG for many real workloads. You dump raw material into a folder, let an agent compile it into interlinked Markdown, and run periodic lint passes so the library stays consistent. At team scale he argued structured text plus indices beats opaque embedding search that returns plausible fragments with weak provenance.

That pattern rhymes with system documentation too. You already have the raw material of a knowledge base scattered everywhere: git history, tickets, Slack threads, and code. You’re just not compiling it into agent-readable truth that lives beside the work. Karpathy’s point is that the model can be your librarian. Once the pattern is established, summaries, cross-links, and cleanup become ongoing maintenance, done entirely agentically, rather than a one-time migration project. This doesn’t mean vector databases are dead; it means the interesting bet for many product engineering teams is versioned Markdown in git, maintained with the same habits as code.

What you should do Monday

We are intentionally not prescribing a full-on “move your tickets into git” or “replace Jira with YAML tasks” project. Ticket workflow is a separate fight, and many teams are not ready for it. This thesis calls for different experiments around documentation and shared memory.

Try this: pick one bounded subsystem and require that its functional and architectural documentation live in Markdown/Mermaid stored alongside the code. Treat wiki pages as deprecated for that slice. Then add a lightweight gate that makes drift visible: a CI check that fails when certain paths change but their docs don’t, or an agent lint step that compares README claims to test names and public API surfaces.

Run a Karpathy-style compile pass to flesh out this new library: export related decisions from Slack into a raw/ folder, then run a bounded agent job to produce interlinked docs/ with backlinks. Review the agent’s work and tweak based on what it missed or under/overemphasized. Measure whether onboarding and agent sessions get faster, more accurate, or just plain easier.

Whatever experiment you run, teams will have to adjust. This change lands differently on each side of the house. Product leaders will need to build fluency with repo-resident artifacts (reading a spec in git, commenting on a PR). For engineering leaders, the change means owning freshness: if agents read the repo, stale local docs are now a production risk, not a technical-writing nuisance.

None of this requires replacing the wiki overnight. Plenty of orgs will keep it as the official face for auditors and executives, and that’s not wrong. Different consumers need different views. The bet worth running in 2026 is smaller: for the teams shipping with agents, stop asking them to treat a parallel documentation universe as true. Put truth beside the implementation, let git govern change, and let agents help maintain the library the same way we finally learned to let CI maintain tests.

Further Reading

• LLM Wiki (Karpathy’s own gist) – Andrej Karpathy, ~Apr 2026. His three-layer pattern: raw/ (immutable sources) → wiki/ (LLM-generated interlinked Markdown) → a schema file (he names CLAUDE.md / AGENTS.md), with ingest/query/lint ops and the LLM as “compiler.” This is the thesis in his own words and uses the raw/ folder the draft references.
• Stop Writing Passive Documentation (DDS) – Alper Kinali, Apr 2026. “Passive documentation… is a critical point of failure”; agents “lack context, they hallucinate.” Near-verbatim support.
• Docs as Code — Write the Docs – canonical reference. Authoritative definition: version control, PR review, CI gating, block a merge that lacks docs.
• Mermaid — Introduction – Mermaid project, maintained. Explicitly positions itself against “Doc-Rot”; text-defined, version-controllable diagrams vs. opaque binaries.
• Is RAG Dead? Context Engineering & Semantic Layers – Steve Hedden, TDS, Oct 21 2025. Backs “structured context beats embedding search.”
• Docs for Developers (book) – Bhatti, Corleissen, Lambourne, Nunez, Waterhouse; Apress, 2021.
• Why we use “docs as code” — GOV.UK – Jen Lambourne, GDS, Aug 25 2017.
• Squarespace’s docs-as-code journey – Squarespace Eng, 2025.

Almost every CTO or VPE we talk to is asking some version of the same question: “Are we picking the right tools, building out the right workflows, and putting our people in the right places?” In other words: how should engineering teams actually operate now, with agents writing most of the code?

Teams are landing in pretty different places. Some are pushing toward full autonomy with minimal human review. Others are keeping tight control, using AI more as a reviewer or assistant. Most are somewhere in the middle.

But which workflow you pick isn’t really the challenge. The inputs are.

The bottleneck has moved. Writing code is getting cheaper, but building reliable systems requires more than just code. Specs, tests, and review are now the limiting factors, and agents amplify whatever you feed them. Strong inputs get strong results. Weak ones fail faster, at scale, and with less visibility into why.

One theme for the second half of 2026: engineering leaders need much better visibility into what other teams are actually doing. Too much of this is still being figured out in private, and some of the public conversation is noise.

What’s actually working

From what we’re seeing across teams and practitioner write-ups, a few patterns are emerging. Not as a single “right way,” but as things that consistently hold up.

Front-load the thinking: spec, tests, then code

The teams getting reliable output are putting more effort into shaping the problem up front (acceptance criteria, edge cases, tests) before letting agents implement. The shift is subtle but important: less time writing code, more time defining what “correct” looks like.

Parallelize aggressively, but with boundaries

Running multiple agents in parallel is becoming common: one exploring, one implementing, one cleaning up. (Stripe built a harness that ships >1,000 agent-driven PRs per week. ) But the teams doing this well isolate each agent in its own worktree, container, or sandbox, so mistakes don’t cascade. Parallelism helps, but only if it’s contained.

Where this breaks

A few failure modes show up just as consistently.

Tests written after the fact

This is amplification working against you. When you ask an agent to write tests after the implementation, the existing code becomes the spec. Agents don’t push back. They complete the task you gave them, even if the task is wrong. The result: tests that lock in whatever’s broken. Discipline matters more with agents, not less: tests first, then implementation.

Context can be a liability

Many teams are leaning on rules files (CLAUDE. md, AGENTS. md) to guide behavior. But they go stale quickly. Codebases evolve, and these files rarely keep up. Without regular review, they can make things worse, with agents following outdated or rigid instructions. Structure is necessary for good results, but bad structure gets amplified.

What actually changes for teams

Coding agents don’t remove the need for senior engineering judgment. They concentrate it. The work shifts toward defining problems clearly, validating outputs, and keeping the whole system reliable. Teams with weak specs, inconsistent tests, or overloaded review processes feel more pain, not less. Teams with strong fundamentals move faster.

The work moves up the stack, and the pressure moves with it. And the systems you build around the agents matter more than the agents themselves.

Reading list

• Embracing the parallel coding agent lifestyle – by Simon Willison. Concrete patterns for running several coding agents at once. Covers worktrees and Docker for isolation, what kinds of work to delegate to parallel sessions, and what to supervise more tightly.
• How Stripe built “minions” – by Steve Kaliski via Lenny’s Newsletter. Inside Stripe’s production agent harness shipping ~1,300 PRs/week from Slack reactions. Covers the harness layers, how they handle code review at that scale, and what they had to build vs. adopt off-the-shelf.
• Why Testing After with AI Is Even Worse – by Matti Bar-Zeev. Why asking an agent to write tests after the implementation produces tests that validate existing bugs instead of catching them. Makes the case for TDD with agents, not against it.
• How System Prompts Define Agent Behavior – by Srihari Sriraman and Drew Breunig (nilenso). A close read of system prompts across Claude Code, Cursor, Codex, Gemini, and others. Shows the same model producing dramatically different workflows depending on the prompt wrapped around it.
• Your CLAUDE. md Is Making Your Agent Dumber – by Cordero Core. Recent research finding that LLM-generated CLAUDE. md / AGENTS. md files actively decrease agent success rates compared to having no context file at all. Practical guidance on what to do about it.
• Ralph Wiggum as a “Software Engineer” – by Geoffrey Huntley. Walks through “Ralph,” a bash-loop technique for autonomous coding agents. Concrete on what kinds of projects it suits and where senior engineering judgment stays non-negotiable.

CPOs, VPs of Product, and CTOs are experiencing a common challenge: while agentic coding tools accelerate product development, they also introduce new friction between product and engineering. A product manager (PM) creates a spec that tells engineering what they want built, and then one of two things happens:

• The engineer appropriately asks the agentic coding tool what questions it has. The agent immediately surfaces 15 questions, 12 of which need input from product. You have a cycle time hit and more context switching.
• The engineer doesn’t surface the questions and builds it anyway. After PR reviews and QA, they realize the implementation does the wrong thing.

One theme for the first half of 2026: product and engineering leaders need to reduce this new friction.

What changed

A PM’s spec has two audiences.

First, people:

• Reviewers (customers, leadership, other PMs) who need to confirm the product intent.
• Engineers who need to reason about tradeoffs, durability, and how it fits the architecture.

Second, agents:

• The agentic coding tool that will try to execute what you wrote, literally, at speed.

So what do we do?

PMs should use codebase-aware tools before handoff

I would highly recommend that product leaders and product managers try out the new Claude Desktop app, which bundles Claude, Claude Cowork, and Claude Code into a more PM-friendly interface. You can use it for a LOT more product needs than creating specs – see the additional reading below.

To get your PMs onboard, consider using the tool to ask:

“What does the product do today in scenario X?”

If you have Claude Desktop connected to your code, it often can answer those types of questions. It also will provide you the answer to:

“Given this draft spec, what questions do we need to answer before someone starts work?”

This helps PMs clarify ambiguity so you avoid the new friction points.

It’s time to change the default from “PMs don’t have visibility into the repo.” That policy actively works against speed and alignment. By giving the AI tooling access to the code base, PMs are empowered with insight while maintaining the separation of responsibilities with engineering.

Side note: Markdown is quickly becoming the shared format for specs because it’s easy to diff, easy to reuse, and plays nicely with repos and agent workflows. Pick a Markdown editor you like (Obsidian is a good choice) and make it part of the standard toolkit.

PRDs and Tickets => Specs

You may want to start calling PRDs / Tickets or other definitions of what’s to be built “specs” internally, not because PRD is wrong, but because it communicates a shift: the output is meant to be fed into an agentic coding tool w/ more specifics.

The upcoming virtual mini-conference and the additional reading has lots of help on this front, for example – acceptance criteria and edge cases are critical.

AI supports PMs but does not replace their judgment; it should enhance decision-making efficiency. Use AI to accelerate drafting, decomposition, and edge case discovery. But the final tradeoffs, priorities, and product decisions still belong to the PM. And us engineers still get to rely on PM judgment to know what to build.

Engineering still has to engineer

A clear spec does not eliminate engineering responsibilities. Strong teams do two things consistently:

1. Architecture and technical planning: fit the spec into the system in a durable way (constraints, data flows, integration points, performance, security).
2. Task shaping: break the spec into finer-grained development tasks that are independently testable, so agentic execution stays controlled and reviewable.

A good spec allows the engineers to focus on the work that actually requires engineering judgment.

Reading list

• Agentic workflows for software development – A good overview of agentic workflow design, especially the idea of deterministic checks and evaluation gates that keep speed from turning into chaos.
• How to write PRDs for AI Coding Agents – A practical reframing of PRDs as “spec architecting” so agents (and engineers) can implement reliably with fewer missing assumptions.
• How to Write a PRD with AI (Claude Code tutorial) – Template-forward guidance on assembling a PRD/spec from known context files (including a prd-template.md style approach) so your spec is consistent and agent-friendly.
• How to write a good spec for AI agents – The clearest explanation of “spec as prompt”: why big docs fail and how structure plus constraints drives correct execution.
• Claude Code for Product Managers – A PM-oriented walkthrough of exploring a repo in plain English to tighten tickets/specs and surface the right questions before handoff.
• Claude Code for PM work – Grounded notes on where PM workflows break today (docs are incomplete, reality lives in code) and how codebase-aware tools can reduce that gap.
• The Definition of Ready in the AI Era – A strong argument for shifting DoR from “can dev start?” to “if built exactly as written, would we be satisfied?”

A few definitions to start

Autonomous agentic system: an LLM wrapped in a loop that can plan, take actions via tools, observe results, and continue until it reaches a stop condition (or it’s forced to stop).

Tool calling: the agent selecting from a constrained action space (tool names + schemas) and emitting structured calls; your runtime executes them, validates outputs, and feeds results back into the loop.

Orchestration (the “real software” around the model): state management, retries, idempotency, timeouts, tool gating, context assembly/pruning, audit logging, and escalation paths.

Closed-loop evaluation (Plan -> Act -> Judge -> Revise): a repeatable harness where you run realistic tasks, score outcomes (ideally against ground truth and human-calibrated judges), learn what broke, and iterate.

Guardrails + safe stopping: runtime-enforced constraints (policies, budgets, circuit breakers, permissions) that limit what the agent can do and force it to stop or escalate when risk rises or progress stalls.

A small set of practices that pay off fast

Treat your tools like a product surface, not a pile of functions.
The failure mode is “death by a thousand tools”: overlapping capabilities, ambiguous names, and huge schemas that make selection brittle. Keep tools narrow, make them obviously distinct, and hide tools by default unless they’re relevant to the current step. “Just-in-time” instructions and tool visibility is a pragmatic way to scale without drowning the model in choices. 

Move reliability into deterministic infrastructure (not prompt magic).
If an agent can trigger side effects (create a ticket, refund an order, email a customer), you need transactional thinking: idempotent tools, checkpointing, “undo stacks,” and clear commit points. Prompts don’t roll back production systems; your runtime does. 

Put hard budgets and explicit stop reasons into the main loop.
Most “runaway agents” are simply missing guardrails that set limits on: iterations, tool calls, dollars, and wall-clock time; and “no progress” detectors (same tool call repeating, same plan restated, same error class recurring). When the agent hits a threshold, it should stop with a structured summary: what it tried, learned, and needs from a human.

Design for long-running work with durable state and resumability.
If the agent’s job can outlast a single context window (or a single process), assume it will crash, time out, or be interrupted. Store state externally, make steps replayable, and separate “planning notes” from the minimal context required to proceed. The goal is to resume cleanly without redoing expensive work or compounding earlier mistakes.

Make evaluation real: production-like tasks, ground truth, and judges you can trust.
Vibe checks don’t catch regressions. You want a small-but-representative set of real tasks sampled from production distributions, with ground truth where possible, and automated judges that are calibrated against human agreement (so you know what “good” means). Also assume reward hacking and metric gaming will happen. Build detection for it the same way you do for any other adversarial input.

Security guardrails: constrain action space, validate everything, and sandbox execution.
Tool calling expands your attack surface (prompt injection is just one angle). Practical defaults: strict schema validation, allow-lists for tool targets, content sanitization, least-privilege credentials, and sandboxed execution for anything that can run code or touch sensitive systems.

More reading

Building production-ready agentic systems: Lessons from Shopify Sidekick (Shopify, Aug 26, 2025)

AI grew up and got a job: Lessons from 2025 on agents and trust (Dec 18, 2025, Google Cloud)

Effective harnesses for long-running agents (Nov 26, 2025, Anthropic)

What 1,200 Production Deployments Reveal About LLMOps in 2025 (Dec 19, 2025, ZenML)

Ground Truth Curation Process for AI Systems (Aug 20, 2025, Microsoft).

Function calling using LLMs (May 6, 2025, Martin Fowler).

How to build your first agentic AI system (Oct 2, 2025, TechTarget).

Announcing the AI Developer Bootcamp

I’m excited to share something we’ve been working on: the TechEmpower AI Developer Bootcamp. This is a hands-on program for developers who want to build real LLM-powered applications and graduate with a project they can show to employers.

The idea is simple: you learn by building. Over 6–12 weeks, participants ship projects to GitHub, get reviews from senior engineers, and collaborate with peers through Slack and office hours. By the end, you’ll have a working AI agent repo, a story to tell in interviews, and practical experience with the same tools we use in production every day.

Now, some context on why we’re launching this. Over the past year, we’ve noticed that both recent grads and experienced engineers are struggling to break into new roles. The job market is challenging right now, but one area of real growth is software that uses LLMs and retrieval-augmented generation (RAG) as part of production-grade systems. That’s the work we’re doing every day at TechEmpower, and it’s exactly the skill set this Bootcamp is designed to teach.

We’ve already run smaller cohorts, and the results have been encouraging. For some participants, it’s been a bridge from graduation to their first job. For others, it’s been a way to retool mid-career and stay current. In a few cases, it’s even become a pipeline into our own engineering team.

Our next cohort starts October 20. Tuition is $4,000, with discounts and scholarships available. If you know a developer who’s looking to level up with AI, please pass this along.

Learn more and apply here

We’re starting to see a pattern with LLM apps in production: things are humming along… until suddenly they’re not. You start hearing:

• “Why did our OpenAI bill spike this week?”
• “Why is this flow taking 4x longer than last week?”
• “Why didn’t anyone notice this earlier?”

It’s not always obvious what to track when you’re dealing with probabilistic systems like LLMs. But if you don’t set up real-time monitoring and alerting early, especially for cost and latency, you might miss a small issue that quietly escalates into a big cost overrun.

The good news: you don’t need a fancy toolset to get started. You can use OpenTelemetry for basic metrics, or keep it simple with custom request logging. The key is being intentional and catching the high-leverage signals.

Here are some top reads that will help you get your arms around it.

Top Articles

• “What Is LLM Monitoring & Why It Matters” (God of Prompt)
  A crisp primer that defines token count, latency, and cost as the pillars of observability. It’s tool-agnostic and shows how to wire up Prometheus dashboards via OpenTelemetry.
• “What Is LLM Monitoring? (Complete Guide)” (Amit Yadav on Medium)
  This one gets into the weeds but in a good way. It walks through tagging each request with a prompt ID and user ID so you can trace token spikes back to real root causes. Comes with useful alert rule examples.
• “LLM Latency Benchmark by Use Cases in 2025” (AIMultiple)
  Useful latency benchmarks per use case: chat, search, RAG. Suggests setting alert thresholds at 20% over your p95 SLOs to catch slippage early.
• “The State of LLM Observability in 2025” (Sathish Raju on Medium)
  Starts broad, then gets practical. Has a great checklist for real-time dashboards, latency and token gauges, plus rituals like weekly reviews to refine thresholds. Also dives into pros/cons of current tools.
• “LLM Observability & Monitoring: A Strategic Guide to Trustworthy Gen AI” (Ajith’s AI Pulse)
  A broader take on the space, but solid advice. Introduces a three-layer stack (telemetry → dashboards → alerts) and gives sample PagerDuty rules for token or latency anomalies.

The conversation around AI coding assistants keeps speeding up, and we are hearing the following questions from technology leaders:

• Which flavor do we bet on—fully-agentic tools (Claude Code, Devin) or IDE plug-ins (Cursor, JetBrains AI Assistant, Copilot)?
• How do we evaluate these tools?
• How do we effectively roll out these tools?

At the top level, I think about:

• Agentic engines are happy running end-to-end loops: edit files, run tests, open pull requests. They’re great for plumbing work, bulk migrations, and onboarding new engineers to a massive repo.
• IDE assistants excel at tight feedback loops: completions, inline explanations, commit-message suggestions. They feel safer because they rarely touch the filesystem.

Here’s a pretty good roundup:

The Best AI Coding Tools, Workflows & LLMs for June 2025.

Most teams I work with end up running a hybrid—agents for the heavy lifting, IDE helpers for day-to-day quick work items.

Whichever path you take, the practices you use matter the most.

Some examples to get you started:

• Publish a living coding-guidelines file before you turn agents loose—JetBrains’ Junie team shows a good pattern.
  Coding Guidelines for Your AI Agents
• Keep the agent’s toolchain fast and observable; Armin Ronacher’s post explains why slow tests and verbose logs burn tokens and patience alike.
  Agentic Coding Recommendations
• Reset context often—Philipp Spiess’s rule of thumb is “/clear when you change topics.”
  How I Use Claude Code
• Pair early adopters with skeptics and share metrics (time-to-PR, diff size). Thomas Ptacek’s rant is the best antidote to “LLMs are a fad.”
  My AI Developer Skeptic Friends Are All Nuts

Reading list

• Why Developers Should Care about AI-Enabled Software Engineering – A breezy primer you can forward to any hold-outs who think AI is “just for AI people.”
• My AI Developer Skeptic Friends Are All Nuts – A punchy takedown of common objections and a reminder that agents ≠ copy-paste ChatGPT.
• How I Use Claude Code – Real-world workflow tips: when to “/clear,” how to fork threads, and a cheeky alias for yolo mode.
• Agentic Coding Recommendations – Armin Ronacher on keeping loops token-efficient and why Go beats Python for agents.
• How Anthropic Teams Use Claude Code (PDF) – Department-by-department case studies and a template for your own “Claude.md” grounding file.
• Coding Guidelines for Your AI Agents – How to bake language-specific dos & don’ts into a .junie/guidelines.md file so agents spit out idiomatic code.