Easiest #AI metric to measure might be the least useful #agenticengineering #software #codex #claude

Agentic Engineering · 2026-06-30

This video argues that easily measurable AI metrics like commits, pull requests, lines of code, or token usage are often the least useful for evaluating AI agent productivity in software engineering. The speaker highlights that AI agents can generate a lot of visible activity without necessarily producing trustworthy or valuable impact, potentially increasing cognitive load for human engineers through excessive reviews and corrections. Instead, he suggests focusing on metrics that reflect genuine progress and impact, such as accepted pull requests, escaped defects, review burden, cycle time to validated outcome, and production reliability, or even the cognitive load an agent removes versus creates.

AI-Driven Development Lifecycle: Claude Code Live Walkthrough | AI-DLC

Derick Chen - BuildWithDC · 2026-06-30

This video introduces the AI-Driven Development Life Cycle (AI-DLC) methodology, leveraging AI agents like Claude to automate software development processes. The core idea is to treat the AI as a development partner, guiding it through structured phases (Inception, Construction, Operations) using modular rule details to enforce architectural boundaries and prevent context window pollution. Key takeaways include the importance of human architects and product owners acting as 'gatekeepers' to review and course-correct AI-generated artifacts, ensuring quality and avoiding technical debt, especially when adapting to unique organizational contexts and scaling challenges.

read more

The AI-Driven Development Life Cycle (AI-DLC), as presented in this video, is a structured, flexible software development process designed to accelerate software system delivery while maintaining quality and architectural integrity. The presenter, Derrick Chen, leader of the AWS AI-DLC program, demonstrates how this methodology can achieve 5-20x faster development velocity by reimagining the traditional software development life cycle.

Core Principles and Methodology: AI-DLC operates on a three-phase adaptive workflow: Inception, Construction, and Operations. The methodology is tool and model agnostic, meaning it can be applied with various AI agents and platforms (e.g., Claude, Cursor IDE, Amazon Q Developer, GitHub Copilot). The key is to leverage modular specification architecture, which involves a set of core rules and rule details (prompts) that guide the AI agent's actions. This modularity acts as a core defense mechanism against context window pollution, isolating execution paths and preventing the AI from straying too far from the defined scope.

Human-AI Partnership and Role Definition: The workflow emphasizes a human-AI partnership, where the human team (acting as Product Behavior Lead and Software System Lead) collaborates with the AI agent. The human is responsible for defining business rules, enforcing architectural boundaries, and applying architectural taste to course-correct mid-execution. The AI agent, like Claude, operates natively within the terminal interface, following the defined rules and prompts.

Workflow Execution (Inception Phase Demo): 1. Setup: The process begins by cloning and bootstrapping the AI-DLC rules bundle from the AWS Labs GitHub repository. These rules and compartmentalized prompts are stored in `ai-dlc-rules/core-workflow.md` and `ai-dlc-rule-details/` folders. `CLAUDE.md` acts as the orchestrator, inheriting workflows, prompts, and architectural constraints. The project details directory (`ai-dlc-docs/`) stores deep execution context files, allowing for cross-session memory function – an engineer can pick up where they left off even if the session crashes. 2. Intent Declaration: The Inception Phase starts with the human declaring their intent (e.g., building a travel booking application). This initiates a guided process, leading to the Workspace Detection stage. 3. Requirements Analysis: The AI automatically starts a plan-execute-validate action loop. It generates clarification questions (e.g., travel booking scope, user types, authentication methods, payment processing, search & availability, booking management, user interface, backend architecture, database, notifications, search features) to gather detailed requirements. This is where human technical calibration is critical. The AI-DLC workflow is intentionally heavy by default to ensure extreme precision for high-complexity distributed systems. The human intervenes to answer or modify questions, leveraging Claude to fill in structural blanks while maintaining control over critical decisions. This process helps uncover blind spots and edge cases, significantly reducing requirement changes (or 'bolts' in AI-DLC terminology) mid-iteration. 4. Requirements Document Generation: Based on the clarified questions, Claude generates a formal requirements document (`requirements.md`). The human then reviews this document, making any necessary course corrections (e.g., omitting user authentication for a demo prototype). 5. Audit and State Tracking: All progress, decisions, and approvals are serialized into `ai-dlc-state.md` (for state tracking) and `audit.md` (for detailed decision logs). This provides traceability and allows for seamless session resumption. 6. Workflow Planning: Claude performs workflow planning analysis, creating an execution plan (e.g., identifying microservices for Flight, Booking, Payment services) and breaking down the overall specification into modular units of work with clear dependency maps. Humans review and approve this plan. 7. Application Design: Claude then generates application design artifacts, including `application-design.md`, `components.md`, `component-methods.md`, and `services.md`. These documents detail the microservices architecture, API endpoints, service layer design, error handling, scaling strategies, and API versioning. Humans again act as 'gatekeepers', carefully reviewing these designs to combine their expertise with the AI's output. 8. Units Generation: Once the application design is approved, Claude proceeds to generate units of work. This enables multiple engineering teams to concurrently build distinct units without context collision or merge debt.

Key Friction Points and Solutions: Over-engineering Impulse: Without proper constraints, AI agents may attempt to over-engineer solutions (e.g., proposing a complex distributed event-driven microservice system for a simple asynchronous transaction engine). The human architect must intervene to pull back the scope during the design phase. Runaway Codebase: If humans don't actively review and digest AI-generated design documents and key source code implementations, they risk losing control of the codebase. This severely limits the project's adaptability for future enhancements. The solution is continuous human-technical taste and calibration, leveraging the AI to handle repetitive tasks while humans focus on critical design and architectural decisions. Scaling Development and Compliance: For front-end development, AI should compose pre-established UI component libraries rather than generating raw layout components from scratch. For security compliance, AI should be provided with centralized security wrapper libraries and global compliance requirements as additional skills, rather than magically guessing corporate security postures. This ensures consistency and injects best practices with minimal friction. Token Consumption: While multi-agent orchestrations and background sub-agents can accelerate loop completion, they significantly increase token consumption costs. Workflows must be calibrated to balance speed and cost, starting slow and incrementally optimizing.

Final Metrics and Conclusion: The demo successfully built a fully implemented, test-covered travel booking engine in approximately three hours. This highlights the speed and efficiency gains of AI-DLC. The video concludes by emphasizing that AI-DLC is an intense exercise in continuous human-technical taste and calibration. Adoption is easy, but making it truly work requires adapting the tools and methodologies to one's specific environment and context. The future of software development involves humans acting as conductors for an AI agent orchestra, guiding sophisticated AI models through structured processes to build complex systems faster and better.

Genie Tarpit

Kent Beck · 2026-04-29 · 3 min read

TLDR: LLM-generated code tends to cluster in a "low features, low flexibility" quadrant — worse than the mediocre human code it was trained on — because models optimize for plausible-looking output rather than correctness or maintainability. The real problem is that flexibility (clean, changeable code) degrades silently, so the damage isn't immediately visible. No proven fix exists yet, but recognizing where AI-generated code actually lands on the features/flexibility spectrum is the necessary first step to addressing it.

Humans and Agents in Software Engineering Loops

Martin Fowler · 2026-03-04 · 9 min read

TLDR: The right role for developers with AI agents isn't to micromanage generated code ("in the loop") or abdicate entirely ("vibe coding"), but to operate "on the loop" — building and refining the harnesses (specs, quality checks, workflow guidance) that govern how agents work. When something goes wrong, the instinct shouldn't be to fix the output directly, but to improve the harness that produced it. This shifts developer leverage from writing code to engineering the system that writes code.

Design-First Collaboration

Martin Fowler · 2026-03-03 · 12 min read

TLDR: AI coding assistants silently embed all design decisions (scope, component boundaries, interfaces, error handling) directly into generated code, forcing you to reverse-engineer and evaluate everything simultaneously during review — which is cognitively overwhelming and expensive. The fix is a strict five-level conversation protocol (Capabilities → Components → Interactions → Contracts → Implementation) where no code is written until each design layer is explicitly agreed upon. This reconstructs the natural whiteboarding dynamic of human pair programming, catching misalignments at the cheapest possible moment rather than buried in 400 lines of generated code.

Martin Fowler told me the second edition should be shorter (it’s twice as long) (xpost)

Charity Majors · 2026-02-18 · 7 min read

TLDR: The second edition of Observability Engineering is nearly complete, running almost twice the length of the first — despite Martin Fowler's advice to cut. The extra bulk reflects how dramatically the field has shifted since 2018: OpenTelemetry has won the integration wars, most teams still lack real observability without knowing it, and AI has changed how engineers work in production. The new edition restructures around a clearer audience (software engineers instrumenting and analyzing their own code) and adds a governance section for platform teams dealing with cost and tooling decisions.

How We Migrated the Parse API From Ruby to Golang (Resurrected)

Charity Majors · 2025-07-24 · 11 min read

TLDR: When Parse migrated from Ruby on Rails to Go, the biggest unlock wasn't the language switch itself — it was the debugging workflow they were forced to develop: shadow-mirroring live production traffic to both stacks simultaneously and diffing responses field-by-field. This exposed an entire class of bugs (Rails silently accepting malformed/non-RFC-compliant requests that Go rejected) that no test suite could have caught. That experience with high-cardinality, per-request observability directly shaped the philosophy behind Honeycomb.

Interview with Henrik Kniberg on Generative AI

Henrik Kniberg · 2024-10-28 · 6 min read

TLDR: Generative AI has shifted the automation boundary — tasks previously requiring human judgment can now be delegated to AI, delivering roughly a 10x productivity gain for those who use it well. The key trade-off to understand is that AI introduces unpredictability in exchange for intelligence, but this can be managed (e.g., using AI to generate deterministic code). Organizations that don't adopt it won't just fall behind — they'll be paying a steep inefficiency tax with no business justification.

Why threads can't fork

Thorsten Ball · 2014-10-13 · 4 min read

TLDR: When you call `fork()` in a multithreaded process, only the calling thread survives in the child — all other threads are killed instantly, but any mutexes they held remain locked forever. This makes `fork()` fundamentally unsafe in multithreaded environments (like most Go programs), because shared resources such as `malloc`'s internal lock can end up permanently deadlocked in the child process.

Air Traffic Control

Kent Beck · 2026-07-01 · 1 min read

Kent Beck and Keith Adams (VMware, Facebook HHVM, Slack chief architect) argue that AI-assisted development is fundamentally shifting the engineer's role from writing code in flow state to supervising and directing AI output, analogous to air traffic control. This matters because it reframes how senior engineers should think about their value and identity as the core craft of programming gets abstracted away.