It is a common scenario for technical and non-technical leaders to observe that while AI programming tools drastically increase the speed at which individual developers write code, the overall software development team does not see a proportional increase in productivity.

This discrepancy occurs because writing code is only one component of a multi-participant, large-scale software development project. When individual contributors generate code faster, the subsequent stages of the development lifecycle fail to keep pace and become the new bottlenecks. These constraints typically include:

• Code review

• Testing and quality assurance

• Integration

• Release management

• Team coordination

Because these downstream processes have not been accelerated, the project as a whole can become blocked, entirely negating the speed gained during the initial coding phase. Individual AI productivity does not automatically translate to team productivity.

How to Unlock Team-Wide Productivity

To achieve true productivity gains, organizations must move beyond simply empowering individuals to write code faster. The solution requires rethinking the entire software development lifecycle and infusing AI into every phase.

1. Scale AI Beyond Code Generation: Integrate AI tools into your code review process to quickly unblock developers. Utilize AI in your testing frameworks to automatically and thoroughly validate code, reducing the reliance on manual, individual testing.

2. Leverage Continuous AI and Autonomous Agents: Implement agentic workflows to handle the routine “glue work” of integration and deployment (CI/CD). These continuous AI systems can operate autonomously in the background and report back when tasks are complete, freeing up developers for higher-level problem-solving.

3. Cultivate Psychological Safety: The human factor is just as critical as the technology. Ensure that your team operates in an environment where they feel safe to regularly experiment with AI tools. Building a habit of reflecting on how AI is integrated into the workflow — and sharing those experiences across the team — allows the group to iterate and move faster.

By systematically addressing these bottlenecks and fostering a culture of shared experimentation, teams can achieve substantial productivity improvements alongside enhancements to quality and innovation.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups. Join us!

Test-Driven Development (TDD) is exceptionally powerful when combined with AI agents. While historically considered time-consuming for human developers, TDD provides a mechanistic verification process that is perfectly suited for AI. By relying on tests, you eliminate the risk of the agent generating inadequate code or solving the problem incorrectly. Furthermore, it removes the need to manually verify — or “babysit” — every step of the agent’s work.

Agents possess a unique strength in rapid iteration and error resolution. When presented with a set of predefined tests, an AI can repeatedly adjust its implementation until the solution is correct, transforming TDD into a highly reliable and low-overhead methodology.

The Agentic TDD Workflow

To effectively guide an agent through TDD, implement a strict orchestration pattern:

1. Write the Tests First: Begin by developing a robust test suite. Ensure you have comprehensive coverage that addresses all critical and interesting aspects of the desired software. This step locks in the requirements before the agent writes a single line of implementation code.

2. Isolate the Agent and Protect the Tests: Delegate the implementation phase to the agent, but enforce strict boundaries. The agent must be completely isolated from modifying the tests. In some configurations, it is beneficial to prevent the agent from even viewing the test source code, restricting its visibility solely to the test execution results and error logs.

3. Iterate Until Passing: Allow the agent to iteratively write and refine the implementation. Because the agent excels at iterating against predefined constraints, it will continue adjusting the codebase until the entire test suite passes.

Automation vs. Manual Orchestration

Depending on your tooling and confidence level, this process can be managed in two distinct ways:

• Fully Automated: With proper prompting and orchestration frameworks, the entire loop of generating code, running tests, and feeding errors back to the agent can be delegated entirely. The agent independently works with discipline through the feedback loop to reach a passing state.

• Manually Orchestrated: For more complex problems, you might prefer to oversee the cycle. In this approach, you pay close attention to the failing tests, provide minor guidance as the agent iterates, and independently verify that the final implementation passes without any unauthorized alterations to the test suite.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups. Join us!

Yes, in terms of sheer reliability, but relying exclusively on context files sacrifices scalability. This architectural decision should be viewed as a trade-off rather than a strict binary choice.

Recent research from Vercel confirms a common intuition among AI practitioners: context loaded upfront in a file like AGENTS.md or CLAUDE.md operates consistently more reliably than the exact same context loaded on demand through Agent Skills.

However, this does not mean you should avoid using Agent Skills. Instead, you must balance the model’s need for constant awareness against the system’s need for an expansive, modular toolset.

Understanding the Trade-Off

To build an effective agentic system, it is important to understand the mechanical strengths of both approaches:

• Upfront Context Files: Files like AGENTS.md are loaded immediately and remain constantly visible to the agent. Because the model processes this text continuously, it is highly reliable. You should use upfront context when the agent requires strict, persistent adherence to core instructions or when the rules must always be top-of-mind.

• Agent Skills: Skills are loaded progressively on demand. The agent only reads the brief descriptions of the skills upfront, fetching the underlying instructions and logic only when a specific skill is invoked. This allows you to maintain a vast library – sometimes hundreds of distinct capabilities – without flooding the context window or degrading reasoning performance. Skills are ideal for explicit tasks where the trigger for using them is obvious.

The Hybrid Solution

In practice, the most robust architectures combine the two mechanisms. You can leverage the persistent reliability of upfront context to manage the dynamic scalability of Agent Skills.

To implement this hybrid approach effectively, divide your instructions as follows:

1. Store bulk content in Agent Skills: Place the heavy, verbose elements — such as full scripts, detailed reference materials, extensive assets, and complex execution steps — inside individual Agent Skills.

2. Place triggers in the upfront context: Use your AGENTS.md or CLAUDE.md file to provide precise operational hints. Tell the agent exactly when to load specific skills and how to apply them to a given situation.

By using the upfront context as a reliable index and routing system, the agent will consistently know which tools to reach for, while the Agent Skills will ensure your overall system remains highly scalable and your context window remains uncluttered.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups. Join us!

…

You do not need a deep technical background in machine learning to create powerful AI systems. Whether you are a software engineer, a business manager, or a creative professional, anyone can become an effective AI operator today. The most practical approach is to start building directly, focusing on orchestration and evaluation rather than the underlying mathematical theories.

Here is a recommended, step-by-step progression for getting started:

1. Master “Harness Engineering” with Local Agents

If you want to build complex systems, the best entry point is working interactively with local coding agents. Excellent options include Claude Code, Copilot CLI, Codex, and OpenCode. These tools offer a rich vocabulary of customization mechanisms that allow you to orchestrate how the AI operates.

You should focus on mastering features such as:

• Agent skills and custom instructions.

• Subagents for delegating specific, modular tasks.

• Hooks that connect the AI to external tools, scripts, or workflows.

Using these orchestration mechanisms — an approach now referred to as harness engineering — allows you to build custom automations, complex workflows, or even complete applications tailored to your specific needs.

2. Transition to Programmatic Execution

Once you have successfully built a workflow that functions well interactively, the next phase is to drive it programmatically. All of these major coding agents provide Software Development Kits (SDKs), such as the Claude Agent SDK, OpenCode SDK, Codex SDK, or Copilot SDK.

By utilizing a local agent SDK, you can shift from manual interaction to full automation. This enables you to:

• Run your AI workflows as scheduled background jobs.

• Trigger AI processes automatically in response to specific system events.

• Seamlessly integrate the AI capabilities into larger, pre-existing applications.

3. Adopt an Empiricist Perspective

Working with AI is fundamentally different from writing traditional code. AI models are non-deterministic, meaning the same input might yield varying outputs. To build dependable systems, you must learn to measure and manage this inconsistency.

As you continue finding new approaches and tricks, you should focus on:

• Data science and statistics: Learn the basics of how to measure and interpret varied outputs across large datasets.

• Evals (Evaluations): Implement systematic testing frameworks to score the quality, accuracy, and reliability of the model’s responses.

• Experimentation: Run structured tests to observe exactly how modifying your harness (like tweaking instructions or adjusting hooks) affects the AI’s behavior in production.

You can begin building with AI immediately. Focus entirely on using a local coding model’s full feature set to customize your workflow, transition to an SDK for automation, and rely on robust data science and evals to guarantee dependable results.

While there is considerable excitement surrounding multi-agent orchestration frameworks, you should generally treat these open-source packages as experimental research projects rather than production-ready tools.

It is highly recommended to explore them for educational purposes, but integrating them into active workflows or commercial software is usually premature.

The Limitations of Scaffolding

A common maxim in artificial intelligence development is that capabilities not yet mature in the underlying models cannot easily be forced into existence through complex scaffolding or harnesses.

Attempting to compensate for a base model’s current limitations by tacking on heavy orchestration infrastructure typically leads to negative outcomes:

• Decreased Efficiency: Adding layers of agent management and communication often slows down execution and complicates debugging.

• Increased Costs: Running multiple agents in a complex, overlapping harness drives up API usage and compute expenses without a guaranteed return on output quality.

How to Utilize Open-Source Multi-Agent Orchestration Frameworks for AI Coding Today

Instead of deploying these systems in production, use them as learning tools. You can benefit from these public experiments in the following ways:

• Study the Architecture: Download the code and read through it to understand how different developers approach the complex task of scheduling and orchestrating agents working in concert.

• Monitor Developments: Keep a close eye on these projects — especially when a new generation of base models is released. Framework authors often rush to exploit new native capabilities, which can provide valuable insights into the shifting state of the art.

The Recommended Alternative

For current complex, long-running software projects, you do not need a third-party multi-agent framework. Instead, rely on the native capabilities of established coding harnesses like Copilot, Codex, or Claude.

These platforms typically provide everything you need through a more straightforward, reliable structure:

• Main Agent Thread: Acts as the central harness to manage the overarching task, drive the primary logic, and maintain long-term context.

• Sub-Agents: Support the main thread by specializing in specific sub-tasks, farming out discrete workloads, and managing localized context.

Future Orchestration Needs

When the time eventually comes that your workflow genuinely requires a robust multi-agent orchestration setup, you will likely be better served by building a custom system. By that point, you will have a clear understanding of your precise needs and can design a bespoke architecture that addresses them directly, rather than wrestling with a generalized, experimental open-source package.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups. Join us!

…

It is common to set instructions – whether in an AGENTS.md file, a CLAUDE.md file, or another rules file – only to find the agent ignoring them or applying them inconsistently.

To fix this, you need to understand why it happens: instructions are merely text appended to the model’s context for every request. Because large language models are inherently non-deterministic, they may occasionally misunderstand, de-prioritize, or entirely miss your directives.

The most effective approach is to treat your agent instructions as project infrastructure that requires continuous testing, verification, and evolution.

Strategies for Debugging and Refining Instructions

Here are several practical methods to ensure your agent consistently follows your guidelines:

• Test and Verify Repeatedly: Do not assume an instruction works based on a single successful output. Force the agent to invoke the specified behavior multiple times. For instance, if you mandated a specific commit message style, trigger several commits to verify that the format is strictly and consistently applied across different scenarios.

• Interrogate the Agent: Open a direct chat with the agent and ask it to explain its understanding of your instructions. Present hypothetical scenarios by asking, “What if I ask for this specific task to be carried out? How would you do it? Give me a clear and detailed step-by-step explanation.” This allows you to audit the agent’s interpretation before it performs actual work.

• Inspect Thinking Traces: If your model emits reasoning traces, review them carefully. These “thoughts” provide valuable clues about which parts of the context the model is paying attention to and whether it actually processed your specific instructions before generating its final output.

• Iterate Like a Prompt Engineer: Treat your configuration file as you would any AI prompt. If an instruction is ignored, try rewording it, moving it higher in the document, or repeating it. You can even use ALL CAPS to draw attention to critical, non-negotiable behaviors.

• Ask the Agent for Help: If you are struggling to enforce a rule, ask the agent itself how best to phrase the instruction. It can often help you write a more effective prompt tailored to its own reasoning patterns.

The Importance of Consistency

Always remember that models are non-deterministic – the exact same instructions in the exact same environment will yield slightly different results on each run. You must run multiple trials of the same scenario to guarantee consistency. Iterate and refine your instructions until the desired behavior is fully understood and reliably executed.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups. Join us!

With new AI models being released almost daily, featuring continuously improved capabilities and performance, selecting the best one for your specific needs can be challenging. To effectively evaluate and choose the right model, you should rely on a combination of independent benchmarks, crowdsourced testing, and personal validation.

Here is a structured approach to evaluating and selecting AI models:

1. Artificial Analysis

For a high-level overview of currently available models, Artificial Analysis is an excellent starting point. They conduct their own independent testing rather than relying on the metrics published by model providers, which lends their results significant credibility. This resource is particularly useful for evaluating the high-level trade-offs between:

• Performance: How well the model executes standard benchmarks and general tasks.

• Cost: The price per task, token, or API call.

• Speed: The latency and throughput of the model during inference.

2. Arena

Formerly known as LM Arena, Arena takes a dynamic approach to model evaluation. Instead of using a fixed set of benchmarks, it hosts a competitive league where models are pitted against each other.

• Crowdsourced Blind Battles: Users conduct blind tests by prompting different models with the exact same task and voting on the best response.

• Real-World Coverage: Because users have infinite imagination for new applications, this method captures a much wider array of use cases than static benchmarks — a crucial advantage for evaluating models.

Often, your own intuition about a model’s strengths and its optimal use cases will align closely with the crowdsourced consensus found on Arena.

3. Personal Testing

Most importantly, public testing platforms and data can only take you so far. To truly determine which model works best for your specific application, you must conduct your own testing. You should approach this phase strategically:

• Run Familiar Tasks: Maintain a baseline set of tasks that you have already processed with several older models. Because you know what to expect from these prompts, running them with a new model will give you a precise understanding of how its behavior compares to its predecessors.

• Retry Past Attempts: Always revisit complex tasks that previous models struggled to complete. The enhanced reasoning capabilities and improved performance of the latest generation of models frequently unlock solutions that were previously impossible to achieve.

General Guidance

When researching a new model for your agentic tasks, start by checking Artificial Analysis for empirical trade-offs, consult Arena for crowdsourced performance in real-world scenarios, and finally – and most importantly – conduct rigorous personal testing to validate the model against your specific requirements. Public data informs your intuition, but personal testing verifies the reality of the model’s capabilities in your production environment.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups. Join us!

While agentic engineering is incredibly powerful and shows great promise, its capabilities are sometimes overhyped. Reports of AI agents ‘one-shotting’ complete applications from scratch usually involve simple projects where the agent cannot really go wrong. In those scenarios, as long as the generated code compiles and does something useful, it is considered a success.

Applying agentic coding to more complex, existing projects with many interdependent components and legacy code requires a deliberate approach. To achieve high-quality, dependable results, two foundational practices are crucial: Context Engineering and Specification.

Context Engineering

Context engineering involves providing the agent with project-specific instructions and background knowledge. This grounds the agent in the reality of your codebase, ensuring its outputs align with established patterns. Key methods include:

• Configuration Files: Using dedicated files, such as AGENTS.md, to outline base rules.

• Progressive Loading: Supplying context dynamically through specific Agent Skills.

• Project Documentation: Sharing architectural decisions, coding conventions, and system designs.

• Workflow & Testing Guidelines: Providing explicit information on how to use the project’s infrastructure and test suite.

Specification

Specification is the practice of guiding the agent step-by-step using complete, unambiguous information about the immediate task. Rather than relying on the agent to infer your goals, you must define the boundaries explicitly. This can be achieved through:

• Spec-Driven Development: Utilising comprehensive specification documents, such as formal product requirements or detailed roadmap instructions.

• Detailed Prompting: Crafting prompts that clearly articulate the core intent, constraints (what the agent should not do), what a successful outcome looks like, and how to verify that success.

By rigorously applying both context engineering and specification, developers can tame the inherent unpredictability of agentic engineering – transforming it into a dependable approach even within the most intricate legacy systems.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups, and we’re offerring a 25% early bird discount until March 23rd. Join us!

Yes, but in almost all cases, using the best cloud-hosted models is the recommended approach.

Many teams hope to use locally-hosted open models for agentic coding, typically driven by two main motivations: reducing the cost per token and meeting strict privacy or security compliance rules. While open models are impressive and rapidly improving, hosting your own models locally is rarely the most practical or effective solution.

There are three primary factors to consider when making this decision:

1. Model Capabilities

The most advanced open models are still a few steps behind the frontier models developed by the main research labs. When building and deploying agentic projects, you generally want access to the absolute best capabilities available. Cloud-hosted frontier models currently provide a significant edge in reasoning and coding proficiency.

2. The True Cost of Hosting

At first glance, locally-hosted models look great on paper because the raw cost per token is much lower. However, this calculation often ignores the full cost of ownership. When you factor in the hidden expenses, the financial reality looks much less favorable. These hidden costs include:

• Procuring high-end hardware.

• Installing, configuring, and maintaining the infrastructure.

• Amortizing hardware costs over several years.

• Dealing with low utilization rates compared to the highly optimized infrastructure of a cloud provider.

3. Privacy, Security, and Compliance

Operating in environments under strict compliance rules is the primary scenario where a locally-hosted model might be an absolute necessity. If a cloud provider is strictly prohibited by policy, local hosting is a vital option to have.

In reality, however, most compliance needs can be met by cloud providers. When examining actual regulatory requirements, the commitments from cloud labs — including end-to-end encryption and strict data privacy guarantees — are typically more than sufficient for most organizations.

Making the Final Decision

When evaluating locally-hosted open models versus cloud-hosted frontier models, the trade-offs are usually clear. Open models offer an environment where you maintain absolute control, which is necessary for environments with the strictest compliance rules. They also offer a low raw cost per token. However, this is offset by high hidden costs, including hardware procurement, ongoing maintenance, and the inherent inefficiencies of low utilization.

Conversely, cloud-hosted frontier models deliver state-of-the-art performance that is best suited for complex agentic coding tasks. They are generally more cost-effective overall because they avoid expensive hardware procurement and maintenance. Furthermore, their high security standards, paired with end-to-end encryption, satisfy the vast majority of compliance needs.

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups, and we’re offerring a 25% early bird discount until March 23rd. Join us!

An outtake from Sunday School: Drop In, Vibe On.

In this session, Eleanor Berger hosted Zain Hoda to explore X1PM, a lightweight, shared workspace designed to bridge the gap between human collaboration and AI agents. While current agentic workflows often rely on complex tool calling for software like Google Workspace or GitHub, X1PM proposes a radically simplified approach: interacting purely through standard Markdown and CSV files.

This presentation showcased how shifting away from heavy platform-specific formats to an agent-native file system allows both humans and multiple AI agents to read, write, and collaborate on the same set of documents seamlessly.

The Motivation Behind X1PM

The core philosophy of X1PM stems from the observation that while AI agents are generally excellent at navigating traditional codebases and file systems, they often struggle when presented with overly complex tools.

“A lot of people have had the observation that agents are really good at interacting with file systems. And so I think a lot of what people have discovered is that you know if you connect your agent to MCPs that are extremely complex they kind of struggle with that.”

Zain noted that connecting agents to dense services, such as a Google Workspace MCP or a GitHub MCP with dozens of available tools, can lead to context rot and confusion for the models. The solution was to return to basics, leaning into file formats that agents process naturally. In Zain’s personal workflow, he effectively replaced Google Docs with standard Markdown files and Google Sheets with simple CSV files.

Although this approach works locally, it becomes challenging when trying to access those documents from the web or from a mobile client. X1PM solves this by providing an interface that looks and feels like a structured workspace but operates on top of these raw, agent-friendly files. It acts as an orchestrator, or a shared space, exposing standard file-system operations — such as reading, writing, searching, and editing — via an MCP server.

Building a Unified Agent Experience

Eleanor noted that this approach beautifully addresses a pain point many AI-native developers experience when using local filesystem-based tools and workflows.

“I love this approach of using markdown files and CSV files because you don’t need all this heavy software... but what I realize that I’m missing is a space that makes it easier for me to collaborate with the agent.”

With a local workflow, connecting an agent on a phone or jumping to a web UI is difficult. X1PM bridges the gap between the structured, readable UI of a SaaS application and the simple file-system access required by coding agents.

The Live Demo

During the session, Zain provided a live demonstration of X1PM in action, emphasizing how easily an agent can interact with the structured data. He used a lightweight CRM system built entirely from a CSV file.

He initiated an interaction using the Claude app, instructing the agent to update a specific contact’s status in the CRM.

“I’m going to tell Claude in the demo CRM, change Emma Wilson’s status to closed won. And this is like full live demo, so I have no idea if this is going to work.”

The agent quickly listed the files, searched the structure, and correctly updated the CSV file. A quick refresh of the X1PM web interface confirmed the change, demonstrating the zero-friction collaboration between human intention, agent execution, and the resulting shared truth in the file.

Cross-Agent Continuity

One of the most striking aspects of the workspace is the ability to run multiple tools seamlessly over the same context. Zain demonstrated switching between Claude, a custom coding agent in a GitHub Copilot setup, and the Cursor IDE.

He tasked Claude with generating the requirements and file structure for a “GTM Engineering” course. Claude set up a directory populated with a README.md, tasks, curriculum, and a launch plan.

Because X1PM is exposed as a file system, Zain could then switch over to Cursor and ask it to begin building out a landing page for the project based on the context Claude had just generated. Cursor had instant access to the newly created folders and files.

Eleanor pointed out the significant benefit of having this level of consistency:

“It’s also really cool that you have this consistency because the interface is so simple and this file system tools actually can switch agents, switch models, and they’ll all kind of well assuming the models are good enough, they all kind of still figure out what to do.”

By rooting the context in standardized text files, the environment becomes completely agnostic to the specific model, UI, or IDE being used.

Going Beyond Coding

X1PM also highlights the potential for agents outside of sheer code generation. Because the system utilizes standard CSVs, developers can orchestrate background agents to perform scheduled logic over the data.

Zain offered the example of a freelance developer managing leads out of a CSV. An autonomous agent could be scheduled to regularly scan the file to flag clients who require follow-ups. A secondary agent could ingest this flag and draft personalized emails based on a Markdown template found in the same workspace.

“You have a lot of visibility into all of the context that your agent has. So really the way to think about this is like this is the sort of shared context space between you and your agents.”

This concept resonates strongly with those running complex multi-agent architectures or needing a centralized place to monitor non-code outputs, such as content calendars or style guides.

Managing Conflicts and Coordination

A naturally arising question when discussing multi-agent systems sharing a file system is the risk of conflicting edits or data loss. A viewer asked if there were safeguards against multiple agents overwriting each other.

Zain shared that, currently, X1PM handles this by returning a standard file-locking error if an agent attempts to write to a file currently being modified by another. The agent will typically catch the error and retry.

He also expanded on how these rudimentary text files could act as a sophisticated coordination layer. Referencing recent experiments by Anthropic where large swarms of agents were deployed to rebuild a C compiler, Zain noted that they relied on lock files to prevent conflicts.

“Those locks could essentially just live in a CSV file and you could tell the agent that when you need if you intend to write... first update the CSV file in X1PM and then proceed with it.”

As developers deploy heavier multi-agent workflows, a central CSV indicating which files are currently “checked out” by which agent becomes an invaluable, human-readable coordination tool.

The Future of Shared Agent Workspaces

The discussion then pivoted to the broader implications for the development ecosystem. Another participant shared their experience building custom systems using Markdown files for task prioritization and tracking among multiple agents. The participant noted that X1PM’s cloud-hosted nature offered an immediate benefit by providing a clean, accessible interface to monitor the progress of these ongoing autonomous tasks without having to constantly comb through local Git repositories.

Eleanor noted that other platforms are beginning to explore this space as well, mentioning Thomas Dohmke’s upcoming “Entire” platform which similarly aims to tackle human-agent collaboration. However, tools natively built from the ground up to support this file-system-first architecture remain scarce.

Zain was pragmatic about the future of his tool, noting it started as a solution to his own daily problems.

“Honestly like it would like something like this will eventually become like a feature of the some other product or other sets of products or maybe some new product comes you know with more polish around this. But for now, like I use it daily.”

Whether X1PM grows into a massive independent product or its underlying philosophy is absorbed by larger platforms, the core execution — simplifying the interface into accessible, text-based file systems — acts as a blueprint for the future of agent tooling.

As AI agents continue to scale, building systems that are natively understandable by both humans and machines will be critical for productive, observable workflows.

…

Looking to learn how to use AI agents effectively for software development? The spring cohort of Elite AI-Assisted Coding, the #1 comprehensive course on making the most of agentic software development, is open for signups, and we’re offerring a 25% early bird discount until March 23rd. Join us!

Hugo is one of those rare educators who actually builds production systems and knows how to teach. That combination is hard to find.

Hugo and Stefan Krawczyk are teaching the next cohort of Building AI Applications for Data Scientists and Software Engineers, starting March 10th (I’ll be there too – this time as a student). The course covers the full lifecycle of shipping LLM-powered applications — not toy demos and POCs, but real production systems with proper evaluation, debugging, observability, and deployment.

Here’s what caught my attention:

• 4 weeks of live, hands-on training with Hugo and Stefan – deep experts and gifted teachers

• Guest speakers from DeepMind, Pydantic, Chroma, and more

• Over $1,000 in credits from Modal, Pydantic Logfire, Baseten, Braintrust, Chroma, and others

• 250+ satisfied alumni from Netflix, Meta, TikTok, Adobe, Amazon, Ford, and others

Most LLM courses teach you how to call an API and write a prompt. This one teaches you how to build something durable and dependable.

Hugo and Stefan are offering a 🔥 25% discount to members of this community. If you’ve been wanting to level up from prototypes to production AI systems, this is the one.

See you in class.

An outtake from Sunday School: Drop In, Vibe On.

In this session, Eleanor Berger explored a different facet of agentic AI. While previous sessions often focused on pure coding tasks — building backends, CLIs, or agents themselves — this talk centered on using agents to facilitate creative work: specifically, the creation of presentation slides.

The motivation came from a practical need. Eleanor had been preparing materials for the Elite AI Assisted Coding course and found herself dissatisfied with her initial slide designs.

“I was not so happy with the quality of slides I had for a first instance... I realized this is an opportunity to do something better.”

The result was sunday-slides, an agent skill that manages the process of presentation creation — from content generation and layout to illustration and export. This workflow demonstrates how interactions with AI can move beyond simple question-and-answer exchanges to multi-step processes involving various tools and sub-agents.

The Architecture of the Skill

The sunday-slides skill includes several components:

• SKILL.md: The core instruction file describing the workflow.

• Assets: A bundled logo (customizable) and styling resources.

• Scripts: Python code for specialized image processing.

• Configuration: CSS and TypeScript files for the slide framework.

Interactive Configuration

One of the first things the skill does is establish the constraints for the specific presentation being generated. The skill uses the “Ask User Questions” tool to ask the user about their preferences.

“It wants to use the user question tool. That’s the thing that shows you a UI for answering different multiple choice questions for these parameters and that’s very convenient.”

This step determines several visual parameters:

• Background Color: Setting the tone for the deck.

• Image Style: Determining whether illustrations should be photorealistic, vector art, or — as chosen in the demo — retro pixel art.

• Logo: confirming whether to use the default branding or a custom asset.

These responses are stored as variables to maintain consistency throughout the generation process.

Leveraging Sli.dev

Rather than trying to reinvent presentation software, the skill leverages Sli.dev (Slidev), a powerful tool for developers that generates slides from Markdown.

This demonstrates “skill composition.” She didn’t write the Slidev integration from scratch. Instead, she installed an existing Slidev skill, reviewed it for safety, and then built her new workflow on top of it.

“This in itself comes with a skill. So I installed their skill which is really very high quality... it helped me agentically create my own skill relying on it.”

The sunday-slides workflow instructs the agent to:

1. Initialize a new Slidev project.

2. Install necessary dependencies.

3. Configure themes and styles using bundled CSS/TS files.

4. Generate the content in Slidev’s specific Markdown format.

This approach allows the agent to focus on content and orchestration, while using a specialized tool for rendering and formatting.

Parallelism with Sub-Agents

The workflow generates images in parallel. A presentation might need 10, 20, or 30 distinct illustrations. Generating these sequentially would take significant time.

Eleanor’s solution leverages the sub-agent capability found in modern AI tools like Claude Code, OpenCode, and GitHub Copilot.

“If I can do all of these images in parallel there’s nothing stopping me. Then they don’t have to be serialized.”

For each slide requiring an illustration, the main agent spawns a sub-agent. These sub-agents run concurrently, reducing the total time required to build the deck. This pattern — fanning out work to independent workers — is a standard pattern in agentic workflows.

The “Reflective” Prompting Pattern

Inside each of these sub-agents, the instruction set for generating the image prompt follows a “reflection” pattern:

1. Deliberate: Read the slide content and identify core concepts.

2. Brainstorm: Come up with several distinct visual approaches.

3. Reflect & Select: Evaluate the options and pick the best one.

4. Construct: Finally, write the prompt for the image generator.

“This is a pattern that you’ll see a lot in agentic workflows and often produces better results... it means more iterations, more tokens, that’s the price you pay for getting a better result.”

By forcing the model to “think before it acts,” the quality of the resulting visual metaphors is often higher than a zero-shot attempt.

Solving the Background Problem

A common challenge with AI image generation is consistency, particularly with backgrounds. Even when given specific color codes, models like Nano Banana often produce slight variations that look messy when placed on a slide deck.

“Even if you give them the exact color code... every time you get something a bit different.”

Eleanor’s workaround was simple. Instead of trying to match the slide’s background color, she instructed the agent to:

1. Generate all images on a pure white background.

2. Use a specialized Python script to programmatically replace the white pixels with transparency.

3. Overlay the transparent image onto the slide’s CSS background.

The skill includes this Python script — written by an agent — which uses the pillow library to handle the processing. This ensures that every illustration sits perfectly on the slide, regardless of the background color chosen by the user.

The Live Demo

Eleanor ran the skill live against a fresh topic: “Claude Opus 4.6 vs GPT-5.3-codex”.

She initiated the workflow, and the agent presented the configuration questions. Eleanor selected a Retro Pixel Art style.

The terminal output showed the orchestration unfolding:

1. Project Setup: The Slidev directory structure appeared.

2. Content Generation: Markdown files for the slides were written.

3. Image Fan-Out: Multiple progress bars appeared as sub-agents launched in parallel to generate pixel art for each slide.

“It’s running in parallel which saves some time. This is what I really like about sub agents... being able to fan out a parallel task to multiple agents is something I find very very useful.”

Within moments, the process was complete. The agent ran the build command, and a PDF was exported.

The result was a coherent presentation. The pixel art illustrations matched the retro theme, and the background removal script allowed them to integrate with the slide design.

Key Takeaways

The sunday-slides project illustrates several concepts for AI-native engineers:

• Iteration is Key: Eleanor didn’t write this complex skill in one pass. It took about 2-3 hours of iterative work with an agent — trying instructions, seeing where they failed, adding constraints, and refining the workflow.

• Composition Over Creation: The skill was built on other existing skills. The Nano Banana Pro skill for image generation and the Slidev skill for presentation building. Integrating existing tools is far more efficient than building from scratch.

• Parallelism: For batch tasks like asset generation, the ability to spawn sub-agents helps improve performance.

• Asset Processing: Sometimes the best way to solve a “prompting” problem (like background consistency) is with a deterministic script. Agents can write and run code to fix the output of other models.

“To me that’s a wonderful thing that I can do it and I think it’s in a nice demonstration of how you can use skills to build these complex workflows.”

Mastering Agent Skills is a hands-on workshop for AI power users. Join the next session this Sunday to learn how to build your own skills.

In a recent session of “Sunday School: Drop In, Vibe On,” Eleanor Berger walked through OpenCode, an open-source AI coding agent. Proprietary tools like Claude Code and Cursor have dominated, but OpenCode offers a flexible alternative without vendor lock-in.

The Case for OpenCode

Eleanor opened by positioning OpenCode as a serious alternative to proprietary agents. Of all the terminal-based agents available, she considers it the most visually refined — and a genuine competitor to Claude Code. Unlike tools that lock you into a specific ecosystem, OpenCode is a “bring your own model” platform with a polished terminal, desktop, and web interface.

“I’m really excited about open code and I’m using it in basically myself. It’s I would say the most credible opensource answer to cloud code right now. ... one of the things that’s distinct about it is that it is beautiful.”

The tool stands out for its flexibility. Users can connect to any backend — a GitHub Copilot subscription, an OpenAI account, OpenRouter, OpenCode Zen, or a local inference server like Ollama.

“The other thing that is worth noticing is that you can really connect it to anything. ... So I have my GitHub copilot subscription connected to it. That’s official by the way officially supported. So you’re not doing anything against the terms of service...”

The Model Ecosystem: A Hybrid Approach

Eleanor’s setup mixes models based on the task. Her configuration uses different models for different strengths:

• GPT-5.2 Codex: Used for high-level planning and complex reasoning.

• Gemini 3 Flash: Available for multimodal tasks and large context windows.

• GLM-4.7: Eleanor’s favorite open model for execution — fast and cheap.

“I’m also using quite a lot now actually the GLM 4.7 model. It’s an open model from Z.AI. ... [it] is really fast it’s nice it’s not quite as strong as let’s say Claude Opus? but it’s one of the strongest open models and really fast.”

This lets expensive models handle architecture while cheaper models handle implementation. Eleanor uses GLM-4.7 through OpenCode Zen, which runs an optimized version in the United States, though you could just as easily run it locally or through another host.

Live Demo: The Agentic Workflow

Eleanor demonstrated building a functional agent from an empty directory, showing several useful features in OpenCode.

Project Initialization

Starting in an empty directory, Eleanor used the Here Be Git skill to initialize the repository instead of manually creating configuration files. This is a workflow she runs several times a day when starting new projects — the skill handles the boilerplate and asks about preferences (like whether to include commit instructions for the agent).

“I have a skill helping it and I want to initialize a Git repository and some basic agent instructions. Ask me would you like me to add instructions for the agent to always commit? Yes, please.”

This generated an AGENTS.md file (for persistent agent instructions) and a .gitignore. It’s an “agent-native” project structure where AI instructions are committed alongside the code.

Planning vs. Building

In tools like Claude Code, “Plan Mode” is read-only to prevent the agent from writing code prematurely. When asked if OpenCode has a similar feature, Eleanor said modern models have made it redundant for her.

“I think plan mode was interesting in the past because models were not behaved enough ... to not make any changes ... I don’t think this is a problem anymore and so I never bother because maybe um I don’t know I just don’t find that they need to I just plan and write plan themselves...”

Instead, she just tells the agent to “write a plan,” relying on the model to produce a PLAN.md without modifying code. Better models mean simpler tools — hard guardrails aren’t needed for behaviors models can self-regulate.

Executing an “Agentic Task”

For the main demo, Eleanor built a summarizer agent using the Vercel AI SDK, using different models for each phase:

1. Planning Phase: She engaged GPT-5.2 Codex (Extra High) to analyze the requirements and draft a detailed plan.

2. Execution Phase: She switched to GLM-4.7 to implement the code based on that plan.

The prompt provided to the agent was specific:

“build a simple agent ... using AI SDK and TypeScript. The agent should fetch the top three items ... create summary MD with the title, URL and summary of each.”

The agent picked up relevant skills automatically — including the AI SDK skill for framework documentation and the Context7 skill for library lookups — and did thorough research before writing code. The high-intelligence model produced a PLAN.md, and the fast model executed it — fetching documentation, writing TypeScript, and debugging. OpenCode showed the familiar agentic patterns: a live todo list, bash command execution, and file operations, all rendered in its polished interface.

“It built an agent for us that is looking quite good. It’s summarizing and it wrote samurai. Nice little example ... It looked so good and it worked with different models.”

Beyond the Terminal: Web and Desktop Interfaces

While OpenCode is terminal-first, Eleanor showed it running in two other environments — more a platform than a single tool.

The Self-Hosted Cloud Agent

Eleanor showed OpenCode running as a web server — her own private instance deployed on Railway.

“So I have here my own little web cloud-based agent completely selfhosted. The model isn’t self hosted but the agent itself is ... actually I got frustrated. There was one day when Claude an outage. I was like I don’t have a backup. So I should my own setup.”

She demoed it live, asking a question about an upcoming topic — the agent found the information and wrote a summary almost instantly using GLM-4.7. The web UI mirrors the terminal experience but is accessible from any browser.

The Desktop Application

Eleanor also showed the OpenCode Desktop App, which she called “the best product” in the desktop agent space. The desktop app wraps the agent in a GUI with window management, theming, a built-in terminal for quick commands, and a diff view for code reviews. It supports multiple projects and sessions, and you can configure it extensively — themes, colors, layouts — to fit your preferences.

“The desktop app it has can switch between different projects and different sessions ... And you can have also this window for code reviews. So if it produces new code or new code changes, you can review them in a very nice diff view.”

OpenCode supports sub-agents — you can spawn multiple agents to work in parallel. Eleanor demonstrated this in the desktop app, where the interface visualizes each sub-agent’s individual todo list and progress.

“You can always experiment what it does to see the individual to do of each of them. Look out everything and it animate the results. So really nice desktop app.”

Q&A Highlights: Parallelism and Orchestration

Questions from the audience covered OpenCode’s parallel tasks and orchestration capabilities.

Background Tasks and Parallel Workers

One question was about running multiple background tasks in parallel. Eleanor clarified that OpenCode supports parallelism but doesn’t yet offer a managed cloud service layer like Claude Code Web or GitHub Copilot Agent — you orchestrate it yourself. You could connect to your self-hosted server from the desktop app or terminal, but without a cloud-based agent service, managing multiple persistent workers requires your own infrastructure.

“You can. But they don’t has a web service like called code web or codex cloud ... So you’d have to orchestrate it yourself which not sure if it’s worth the effort. ... So maybe that’s something where they still have a new product to build...”

She noted that the desktop app and local setups can drive parallel agents if you have the right setup (like Vibe Kanban or similar orchestration scripts).

“If you have some setup like vibe kanban or something like this, you can also drive open code and parallel agents. It it works just as well as any of the other terminal based agents for this.”

On Plan Mode

Another question asked whether OpenCode has a Plan Mode like Claude Code or Cursor. It does — you can switch between plan mode and build mode. Eleanor just doesn’t use it personally; she prefers to tell the agent to write a plan directly.

“I never used plan mode. I for some reason I don’t find it useful. I think I can just tell the agent write a plan. But if you like this sort of workflow, yes, you have a plan agent.”

She noted that plan mode was more useful when models weren’t as good at following instructions — now they self-regulate, so hard guardrails are less necessary. Both approaches are valid.

Conclusion

OpenCode is a mature tool ready for production use — AI assistance without the constraints of a closed ecosystem. Eleanor noted that while she still uses Visual Studio and Claude Code regularly, she finds herself reaching for OpenCode more often.

The UI is polished across all three versions — terminal, desktop, and web — with attention to detail that’s rare in open-source tooling. And it’s feature-complete: skills, sub-agents, todo lists, diff views. Everything you’d expect from a modern agent is there.

Mixing models offers cost and performance optimization that single-provider tools can’t match. Self-hosting adds redundancy and control, and the flexibility to swap models is a genuine advantage as the landscape shifts.

As Eleanor summarized:

“really recommend taking a look at open code. First of all, I think it’s a great alternative to some of the commercial tools out there. ... it is indeed good, but open code is a very good option too and they have more less feature parity and the advantage that you have this great choice of different models...”

Eleanor recommended joining the OpenCode Discord to follow development and chat with the community. The developers push updates two or three times a day — a pace that explains the project’s rapid progress.

Jake Levirne has answers. As founder of SpecStory, he’s built the most impressive AI coded software I’ve seen, and shared the workflows that make it legible and trustworthy.

The Two Sides of Software Review

Software development balances two challenges: building the right thing and building the thing right. With AI-Assisted Coding, these are addressed through two review types.

• Intent Review asks: Are we solving the right problem? It aligns the team on the what and why before anyone writes a line of code.

• Code Review asks: Is the implementation correct, secure, and maintainable? This is about verifying the execution (the how).

The review type used depends on the task’s risk and complexity.

Three Workflows for AI Collaboration

SpecStory adapts its review process using three primary patterns.

Pattern 1: Intent First, Then Code Review (Traditional)

Use this for your most critical systems. Don’t let the AI start until the team agrees on the plan. Once the code is written, check every line. It’s slow but safe.

Use this for security sensitive code or core infrastructure where mistakes are unaffordable or a shared understanding of the implementation is critical.

Pattern 2: Intent Review with Optimistic Implementation (Iterative)

This handles most (~70%) of the work. Write your plan and start the implementation immediately. If your team suggests a change mid-way, throw it away (code is cheap thanks to AI). Demos are shared along the way.

This pattern works well for business logic, major UI features, and work where the outcome is more critical than the implementation details.

Pattern 3: Demo Review Only (Lightweight)

This pattern is for exploration and prototyping, so it skips formal reviews. A developer builds a quick prototype, often with a single prompt to an agent, and shares the demo with the team through a recording or live meeting. The goal is feedback on the concept, not production code. The output is a better understanding of the problem, which informs a design spec for a pattern 1 or pattern 2 implementation.

Self-Review for Solo Developers

Solo developers must review their own work with the same rigor as a teammate’s. Distance is the best tool for this.

• Time-delayed review: Step away from the code for a few hours or a day to return with a fresh perspective.

• AI-simulated review: Present your design or code to a new AI agent with a clean context. If it can’t understand the plan, your documentation is unclear.

• Code archaeology: Intentionally revisit an old feature to review its original intent and implementation, which is useful when adding a related feature or fixing a bug.

The Intent Review Process

The intent review is your most important task. Do not just skim the spec. An intent review typically centers on a design document.

• Generate and Refine: Use an AI agent to generate a design document. Load it with context about your existing codebase and your goals. Then, read the document top to bottom. Iterate with the agent, asking it to clarify ambiguities or correct its own logic until the document accurately reflects your intent.

• Remove Implementation Details: A good design document should focus on intent, not implementation. Code blocks in a spec can become a liability, as they can quickly fall out of sync with the actual codebase. It’s better to let a fresh agent generate code from a clean, implementation agnostic spec.

For one feature, Jake used five prompts to load context before asking the agent to write the design doc. He then used another six prompts to refine it, questioning its assumptions, and selecting the best approach out of seven options it proposed. This process requires deep thought and iteration.

Sharing Your Intent

State how much human effort a document represents. Labeling a draft as “AI-authored draft” or “AI-authored, heavily human-edited” indicates the scrutiny required. This prevents reviewers from wasting time on errors you haven’t corrected. Providing the AI chat history alongside the document shows which alternatives you explored and why you rejected them.

Tools like SpecStory’s Arena simplify this by presenting the final document side-by-side with the chat history that created it. This allows reviewers to click any part of the document and see the prompt/response pair responsible for it.

Demo and AI-Assisted Code Reviews

While intent review is primary, demo and code reviews have their place.

Demo Reviews

Instead of waiting for a formal “demo day,” share demos asynchronously as soon as a piece of functionality is ready. An interactive demo is better than screenshots or a recorded video. Share a branch and instructions so your team can run the prototype themselves, rather than just watching a video.

AI-Assisted Code Reviews

For changes warranting a code review, use AI to assist. Tools like Claude Code have built-in commands like /security-review that automatically scan for vulnerabilities like SQL injection or insecure data handling.

Custom Review Commands:* You can create your own review prompts. The templates in the spec-flow repository provide a starting point for creating slash commands that review pending changes or full pull requests. These commands can be customized to check for things beyond simple style, focusing on the why behind the code.

For example, after generating a static site generator, a /code-review command identified an unused os import and pointed out that using relative paths could cause issues if the script were moved.

• Aggressive Linting: AI agents are good at respecting linters. Use this to your advantage by setting aggressive structural constraints. For example, you can configure your linter to error on files longer than 1000 lines or functions longer than 500 lines. This forces the agent to create more modular code without you needing to read every line.

file_length:
  warning: 900
  error: 1000
type_body_length:
  warning: 350
  error: 500

Conclusion

Working with AI requires new habits. Velocity without understanding creates knowledge debt, where no one can explain why the code exists or how it works.

The goal is not to review less, but to review appropriately.

• Match rigor to risk. Use lightweight reviews for prototypes and thorough, multi-gate reviews for critical infrastructure.

• Prioritize intent. Most problems arise from a misunderstanding of requirements. A solid intent review is the most effective way to stay aligned.

• Use AI to review AI. Leverage built-in security scanners, custom review commands, and aggressive linting to automate quality checks.

By adopting these workflows, teams can harness AI’s speed while ensuring the resulting systems are legible, maintainable, and understood by their human owners.

Why Browser Extensions Were Previously Out of Reach

Isaac opened the session by introducing the topic:

“Optimizing the browser before had just been really hard. Nobody really wants to write browser extensions. What I’ve been learning from Eleanor is that it’s actually quite approachable. Part of that is just because there’s some things to learn, but a big part of that is because AI and agents make it accessible.”

Eleanor echoed this sentiment. Despite being a programmer, she had avoided browser scripting for years because her expertise lay in backend systems, not front-end development. The breakthrough came when she realized that models like Claude Opus 4.5 and Gemini have extensive knowledge of these technologies baked in from decades of documentation and examples.

“I don’t even need to understand very well. And so I started experimenting.”

Setting Up the Agent Context

Before diving into code, Eleanor walked through her AGENTS.md file — a minimal set of instructions for the AI agent. The file contained:

• Git workflow automation: Instructions to commit and push changes automatically, keeping local and GitHub repositories in sync

• Project structure: Directories for user scripts and extensions

• Metadata conventions: Namespace and versioning schemes to prevent hallucinations

• Coding style: A request for explanatory comments, useful when the agent generates complete scripts that need quick comprehension

• Permissions: Guidance to request only the minimum necessary permissions

For the browser’s built-in AI features (Gemini Nano), Eleanor included additional documentation links since this functionality is too recent to be well-represented in model training data.

When asked how she created this context, Eleanor explained that she had the agent read the relevant documentation and write the guidance, then verified and refined it:

“That’s really the sign of the times. Since we got Claude Opus 4.5 and GPT 5.2 and Gemini 3, there’s a lot you can hand over to them. I still feel the need to be in control, verify, read, but generally 99% of cases it’s doing what I’m asking.”

First Script: Restyling Hacker News

Eleanor began with a simple task: changing the styling of Hacker News to use serif fonts and a white background. Using Claude through the VS Code extension, she issued a single prompt. The agent generated a complete user script with appropriate metadata headers, including the match pattern for Hacker News URLs.

To run the script, Eleanor used Tampermonkey, a browser extension that manages user scripts across Chrome, Edge, Firefox, and Safari. She simply pasted the generated JavaScript into Tampermonkey’s editor and refreshed the page. The styling changes appeared immediately.

“As you’ve seen, I didn’t write any CSS. I don’t actually know CSS very well. I just asked the agent and it did what I asked for.”

Second Script: Copy Page as Markdown

The next demonstration tackled a more practical problem. Eleanor frequently needs to copy web content as Markdown rather than HTML — particularly useful when feeding content to AI models, where Markdown saves tokens and generally works better.

She switched to Gemini Flash for this task, noting its speed and cost efficiency. Her prompt requested:

1. A user script that converts page HTML to Markdown

2. A library loaded from a CDN (she let the agent choose)

3. A menu item and keyboard shortcut (Ctrl+Shift+C)

The agent selected the Turndown library for HTML-to-Markdown conversion and generated a script with the required permissions for clipboard access and menu registration. The initial version worked for copying entire pages.

Debugging Selection Behavior

Eleanor then requested an enhancement: copy only selected text when a selection exists, otherwise copy the entire page. The first attempt failed — the script always copied the full page regardless of selection.

Rather than diving into the code herself, Eleanor took a screenshot of the browser’s debug console and fed it back to the agent with a description of the problem. The agent identified two issues: duplicate script instances and iframe content overwriting the selection. After applying the fixes, the selection-aware copying worked correctly.

“This is kind of in the realm of vibe coding. I don’t actually know this stuff with browsers and JavaScript all too well. So if I wanted to do it myself, I could probably spend some time and learn it. But in this case I’m completely relying on the agent.”

Converting to a Chrome Extension

User scripts have limitations — they cannot add toolbar icons, for instance. Eleanor demonstrated converting the Markdown copying functionality into a proper Chrome extension using OpenAI’s Codex.

The agent created:

• A manifest.json file with metadata and permissions

• Icon files (including a generated Markdown icon)

• A background service worker

• A content script for page interaction

• The bundled Turndown library

To install the extension locally, Eleanor navigated to chrome://extensions, enabled developer mode, and loaded the unpacked extension directory. After one round of debugging (the selection feature again needed adjustment), the extension worked with both the toolbar button and keyboard shortcut.

Browser-Native AI: Summarization with Gemini Nano

For the final demonstration, Eleanor explored Chrome’s built-in AI capabilities. Recent Chrome versions ship with Gemini Nano, a small language model that runs locally on the device.

She created a user script for Hacker News that adds a “summary” link below each item. When clicked, the script:

1. Loads the browser’s native language model

2. Fetches the linked article

3. Uses the summarization API to generate a brief summary

4. Displays the result in a tooltip

The agent — this time using Claude with access to Chrome DevTools — tested the script automatically before reporting completion. After resolving a permissions issue with cross-domain requests, the summarization feature worked.

“That’s pretty cool. I now have this feed where I click the summary and it fetches this article and creates a bit of a summary which, for a small model running locally on my device, is something I can understand.”

Key Observations

Several themes emerged from the session:

• Low barrier to entry: None of the scripts required Eleanor to write JavaScript or CSS directly. The agents handled implementation details while she focused on describing desired behavior.

• Iterative debugging: When scripts failed, feeding error messages or screenshots back to the agent proved effective. The agent could reason about browser-specific issues like iframe conflicts and script duplication.

• Model selection matters: Simple tasks worked well with faster, cheaper models like Gemini Flash. More complex tasks benefited from Claude’s reasoning capabilities.

• Context documentation pays off: The minimal AGENTS.md file prevented common issues like hallucinated namespaces and excessive permission requests.

Isaac summarized the broader implication:

“There’s just so many paper cuts in every workflow that you kind of grow to accept. Being able to use AI to do these things means you don’t really have to accept them anymore because you can spend a little bit of time and make a new extension without learning an entire new domain.”

I wanted to learn more. I had ideas I couldn’t implement inside a company. I wanted to build my own products, create my own courses, and have the freedom to make mistakes and to try paths others were confident were wrong.

I knew AI was powerful, but I didn’t know the best way to use it. I had theories to test and bad ideas to explore. This is the story of that exploration, how AI enabled it, and what I’m doing next, and why the January Cohort will be my last one.

Five Experiments in Six Months

I created two courses and began building two products. I rebuilt those products in four frameworks I had never used before, learning each well enough to understand what was happening under the hood. I could never have imagined doing all this at once. AI was the catalyst.

1. The AI Coding Course

I started an AI coding course with Eleanor Berger. To succeed, we needed to market it, but I had no social media presence. This project forced me to use AI for everything: not just for coding, but for creating content, writing blog posts, making presentations, and producing videos.

It became a research project on using AI effectively. It was the single most transformational thing I did. Every other experiment tied back to the lessons learned here.

2 & 3. Building Products (and My Tech Stack)

My brother and I started building two products: Raw2Draft, a content management tool for my course, and plot.builders, a tool for writing fiction.

How do you review generated code? Where is the line between useful and slop? Should you understand every line? Is it possible to prove that code is good without understanding every line? How do you use agents well? Is vibe-coding useful for building product? Does framework really matter? How do you use AI without giving up all the speed gains back in maintenance, bugs, and review?

We rebuilt the apps in several frameworks to find out, and developed strong opinions that inform the course.

We tried many frameworks, here’s a few.

Next.js and React: AI support was strong, but the complexity was high. The time saved generating code was lost in the review cycle.

FastAPI and React (with Mantine): We simplified the backend with FastAPI, which we could test in isolation, and used AI for the frontend UI. This was better, but still challenging.

Air: I started talking to Danny and Audrey Roy Greenfeld. Danny was working on bringing HTML composability into FastAPI, an idea that evolved into a full framework called AIR. I rebuilt my apps with it and was blown away.

The code was simple, and the AI support was phenomenal. I attribute much of this to the documentation that have clear, consistent patterns that gave AI something concrete to work with. Well-documented code gives AI clear patterns to follow.

4. The Retrieval Course

I created a retrieval course for boot.dev to see how helpful AI was for creating educational content. It was helpful, but not as much as I’d hoped.

Its best use was generating a rubric to evaluate my lessons. The rubric prompted me to add some things, but I disagreed with more than half its suggestions. It was still a net win.

It was also helpful when I could transcribe what I was thinking and have AI create a rough first draft from the transcription.

5. The Book

I wrote and edited a 22-chapter book. It is not yet published, but the process solidified my thoughts on writing, structuring ideas, and maintaining continuity. AI was extremely helpful here, more so than with the retrieval course, because the book was documenting what I do daily.

Teaching fundamentals requires breaking down concepts in ways you don’t naturally think about anymore. The mental model you use after mastering something is very different from the one needed to learn it and that transformation isn’t obvious and requires significant work.

What I Learned About AI

This six-month sprint was an intensive research project. My productivity is drastically higher than it was before. Here are a few important lessons.

AI Is a Learning Accelerator

The biggest speed up is because I learn faster. And learning is the bulk of new work for me. I was blocked as a writer for over ten years. Now when I sit down to write, I have 10 to 15 new things I learned that week worth writing about - not just AI techniques, but new APIs, async patterns, decoupling strategies, entire domains I’d never touched before.

There was no single “this changes everything” moment. It’s been a gradual compounding. My throughput keeps increasing, week by week, and I keep getting more and more excited.

Structure is a thinking tool

To think clearly, we learn to structure our thoughts with project plans, pro/con lists, specs, tickets, and other methods for comparing options. AI is excellent at creating these frameworks. You can accelerate your thinking by transforming your raw ideas into such structures.

For example, you can record a jumble of thoughts and have an AI organize them into a pro/con list, extract key components, sort them by difficulty, or provide a summary. This is a powerful way to clarify your ideas and speed up the entire process.

Your Thinking Style Determines Your Success

AI is a tool for thought. How you think about problems determines the leverage you get.

Spec-First Thinking: If you think through specs and requirements, like a product manager, AI can be a powerful code generator. People with product backgrounds get massive speedups with AI because of this.

Code-First Thinking: If you think by writing code you’ll see less benefit from generative AI. This approach doesn’t provide the detailed, context that AI needs to generate good solutions.

There are many thinking and problem-solving structures. Software engineers will get a ton of value by adding other approaches, such as Spec-First Thinking, to their toolkit alongside Code-First Thinking.

Vibe Coding

I hoped “vibe coding” was viable. The idea that I could just describe what I want and see it appear. That I could build based on feeling and imagination.

I spent significant time trying to vibe code a real, working product that I actually used daily with real edge cases. Not a script. Not a blog. A product. It does not work at that scale. Our thoughts are not structured enough. AI is phenomenal for prototyping and closing that feedback loop, but you cannot “vibe” your way to a finished product.

Spec-first agentic development is not vibe coding.

What’s Next: Focused Building

My period of expansive exploration is shifting to a more focused one. Every domain is big enough to devote a lifetime to and I am so excited to use AI to build new things that I want to focus there

I have two areas of focus:

Developer Tooling: I see very few people using AI well. I want to build tools that help developers get real leverage from it. Specstory is doing great work here. Amp’s experimentation on the review process is also exciting.

Retrieval: The best way to improve LLM output is to control the context you provide. Retrieval is a key, and it’s a field that is lagging. Mixedbread is doing critical work in this space.

Conclusion: My Last Cohort

This journey has given me clarity. It has shown me what I can build and what I want to focus on.

AI is a tool that amplifies your ability to think and learn. There’s far more depth to using it effectively than people let on. I devoted six months to researching this nearly full-time. Nothing I’ve accomplished was impossible before, but I simply did not have the time to do it until I could use AI as an accelerator.

I still want to teach, but as a byproduct of my learning, not for income. This January will be my last cohort co-teaching the AI coding course with Eleanor. I'm sharing everything I've learned. If you want to learn how to use AI to accelerate your own work, join us. Eleanor is taking the course forward with exciting plans for the community — she'll share more in the new year.

In this session, Eleanor Berger introduced MDFlow, a tool she discoveredrecently. MDFlow enables developers to create reusable “recipes” — markdown-based prompts that can be executed with various AI agents directly from the terminal.

“What MDFlow does is it kind of lets you create these recipes, these commands that are written in markdown — essentially prompts — and run them with any one of the many different agents that are available.”

The tool currently supports Claude, Copilot, OpenCode, Gemini, and potentially others. Eleanor acknowledged that while terminal-based workflows aren’t for everyone, MDFlow demonstrates the power and flexibility that command-line environments can offer.

The Core Concept

MDFlow’s approach is straightforward: each recipe is a markdown file where the filename follows the pattern command.agent.md. For example, poem.claude.md would be a recipe called “poem” that runs with Claude. This naming convention is intentional.

“He’s not trying to create a system that sort of abstracts the different agents and how they work. The assumption is that every agent is a little bit different. It has different parameters, and you are specifying explicitly which one you’re using.”

Eleanor explained that you can think of MDFlow recipes as external versions of the slash commands found in Claude Code, Codex, or Copilot — commands that live on your filesystem and can be invoked directly.

A Simple Example: Generating Poetry

The first demonstration was a minimal recipe that generates a short poem. The markdown file contained just a few lines of instruction, and Eleanor ran it by simply executing the file as if it were a script:

$ mdflow poem.claude.md

The result appeared quickly, followed by a menu offering options to copy the output to clipboard, save to a file, or quit. Eleanor had configured her terminal to run .md files directly with MDFlow, eliminating the need to type mdflow explicitly.

Passing Parameters

MDFlow supports front matter for configuration. Eleanor showed how to override defaults — for instance, switching from haiku (a fast, inexpensive model) to sonnet for more sophisticated output:

---
model: sonnet
---

“This bit here doesn’t do anything other than passing model equals sonnet to Claude when I run it.”

Command Arguments and ASCII Art

The next example used Gemini to generate ASCII art. The recipe accepted command-line arguments using a special syntax, allowing Eleanor to pass different words to the same recipe:

“I kind of made a command out of it that can take arguments on the command line. That can be very useful if you are repeating a command again and again just with different arguments.”

She noted that Gemini 3 Flash is a strong option for tasks like this — fast, capable, and generous with free usage even without a paid subscription.

Invoking Claude Code Skills

Eleanor demonstrated that MDFlow can invoke skills already available in your agent. She has a custom skill for generating lorem ipsum placeholder text (which, she noted, is more complicated than one might expect). The recipe simply instructed Claude to invoke the skill:

“Claude will identify that it should invoke this skill, which will in turn call a script that generates the placeholder text in a particular format and distribution for me.”

This composability is key: anything your agent can already do can be triggered through an MDFlow recipe.

Incorporating Shell Command Output

One of MDFlow’s more powerful features is the ability to run shell commands and incorporate their output into the prompt context. Eleanor demonstrated this with a recipe that runs the tree command and asks the agent to format the directory listing as a markdown table.

“We are running the tree command just to look at files in the directory, and we’re asking the agent to format it with a nice markdown table. What we do here is we’re actually invoking the tree command and adding the output to the context.”

The agent received both the original prompt and the command output, then generated the formatted table.

Piping and Composition

MDFlow supports standard Unix piping. Eleanor created an md2html.md recipe that reads markdown from standard input and converts it to HTML with specific styling instructions. She then composed two recipes together:

./tree-table.gemini.md | ./md2html.claude.md

This generated a markdown table with one agent, then piped it to another agent that converted it to HTML and saved the file.

“So what you see here is composability. We can use standard input and standard output and all these basic components of the CLI and create composable commands.”

Repository Review with Copilot

A more complex example demonstrated reviewing a GitHub repository. The recipe used Copilot with GPT-4.1 (described as “ancient history” but fast and free). The instructions told the agent to:

1. Create a temporary directory

2. Clone the repository passed as an argument

3. Review the codebase

4. Save a markdown summary to a file

“Obviously, that’s a very simplistic review by, by now, ancient and elegant model, but this could be a very thorough review for maybe the branch I’m working on.”

The recipe completed quickly, producing a one-page markdown summary of the repository’s purpose, programming languages, and libraries.

From ASCII Art to PDF

The final demonstration chained multiple steps: generate ASCII art, convert it to HTML, then use pandoc to create a PDF. This ran through OpenCode configured with Gemini 3 Flash:

“It sounds a bit kind of convoluted, but let’s face it, that’s the sort of thing we do all day around, right? We invent for ourselves all kinds of processes like this where we need to create something with this program and then convert it to this other program and then convert it yet again.”

The recipe handled the entire pipeline, demonstrating how MDFlow can orchestrate multi-step workflows.

Configuration Defaults

Eleanor shared her default configurations for each agent. For Claude, she uses haiku as the default model with dangerously-skip-permissions enabled. For Copilot, she also defaults to haiku. Gemini uses flash with yolo mode (no permission prompts). OpenCode similarly uses Gemini 3 Flash.

“Every agent has different parameters it will take on the command line, but basically you don’t want to be interrupted.”

Key Takeaways

MDFlow provides a practical way to:

• Create reusable prompts stored as markdown files on your filesystem

• Work with multiple agents without abstraction — each recipe targets a specific agent

• Pass arguments to recipes for flexible, parameterized commands

• Incorporate shell command output into prompt context

• Compose recipes using Unix pipes and standard I/O

• Invoke existing agent skills from the command line

A viewer asked whether MDFlow could work with Copilot subscriptions. Eleanor confirmed it does — she uses it regularly and demonstrated it during the session.

“The same flexibility we expect from our agents, we also get in the terminal environment.”

For those interested in exploring agent workflows beyond IDE integrations, MDFlow offers a lightweight, composable approach that leverages familiar command-line patterns.

Sunday School: Drop In, Vibe On sessions happen every other week on Sunday. They are free and open to all.

Decisions and dead-ends live in my head for maybe a week. After that, they’re gone. Buried in Slack threads. Lost in git commits that say “refactor auth flow.”

New developers ask the same questions I ask myself six months later:

• Why did we build it this way?

• Did we consider other options?

• What were the trade-offs?

I dig through git history and I try to remember my own reasoning. Usually I just guess.

I started using SpecStory to fix this.

It saves and indexes every AI conversation, organized by project. My daily Claude sessions become searchable history.

Three Ways I Query My History

I use it daily. Not for storage. For retrieval.

1. Browse I drill into specific sessions. Conversations collapse, so I can scan fast.

   

2. Search I find every mention of a library or bug. Here I’m searching for “tip-tap.”

   

3. Ask “Why” This is the part that matters. I chat across my entire project history to understand why I made decisions.

   

The “Why” Behind the Code

Normally I access SpecStory through a local agent (often Claude Code).

One of my apps has a complex React editor (TipTap) embedded inside a Python/HTMX application, which looks messy. A new developer would ask the same thing I ask myself six months later:

“Why is this complex React component inside the main repo? Why wasn’t it extracted into its own module?”

Code shows what. It rarely shows why.

My agent can search SpecStory. So I asked:

“Why is tip-tap editor in the repo instead of broken out into its own module?”

It searched my old sessions and found context I’d forgotten:

• Tight Coupling: The editor relies on app-specific authentication APIs.

• High Cost: Extraction would require extensive work.

• Pending Upgrade: We’re waiting for TipTap V3 before refactoring.

• “Good Enough” Architecture: The current “React island” approach is fine/good enough.

  

It also told me what we did instead. We refactored the monolithic file in place to make it more maintainable.

Four things I learned that I couldn’t find in the GitHub repo:

1. We considered extraction seriously.

2. We deliberately chose to keep it coupled.

3. This part of the codebase is historically fragile.

4. We planned a migration for the future (TipTap V3).

That’s institutional memory.

Turning Insight into Action

The analysis also found a missed opportunity: extracting the Markdown converter piece only.

The agent flagged this component as a good candidate for extraction at the time, but the conversation moved on without a decision.

I wanted to raise this with the team, so I asked the agent to create a proposal summarizing the pros, cons, and reasoning.

I got a one-page summary:

• What: A utility to convert TipTap HTML to Markdown.

• Why: Identified as valuable, but skipped for other priorities.

• Pros: Zero coupling, high reuse, low effort.

• Cons: Minimal maintenance for a separate package.

• Plan: A clear 3-step execution strategy.

Vague architectural question to something we can make a decision about.

How It Works

I built this workflow using SpecStory’s API and a simple local setup. Claude Code gets tools to query my project history directly.

The setup:

• CLI Tools: Scripts that call list_projects, list_sessions, and get_session from the SpecStory API.

• Agent Instructions: A CLAUDE.md file that teaches the agent how to use these tools.

The agent fetches context on its own. It sees the project history, filters sessions, and reads transcripts to answer my questions.

The Setup

• Install the SpecStory CLI.

• Run your AI agent through the CLI using specstory run to sync automatically. Or run your agent normally and use specstory sync when you finish.

Conversations save locally in a .specstory directory and to the cloud.

Beyond Code

Before ending I want to briefly cover one more use case I rely on SpecStory for:

Sharing My Work

“Look through the features we shipped this week and write a blog post about them.”

SpecStory captures the reasoning behind each feature which mean the output content has that context. Nobody cares what you did unless they know why it matters. Most people who stumble across your blog or content won’t know why something matters unless you provide that context in your writing.

I get better drafts, faster. Because the “why” is already saved.

But we’ve heard the feedback — including from students in our most recent cohort, who had plenty of kind things to say about the course but also offered this fair critique: when you’re just getting started, “it depends” isn’t the most helpful answer. You want something concrete.

So here’s a concrete answer.

Our Recommendation

Editor: Visual Studio Code

VS Code is free, open source, and by far the most popular code editor. It’s easy to install and will serve you well.

AI Agent: GitHub Copilot and/or Claude Code

You’ll want Agentic AI capabilities on top of VS Code, in the terminal, and in the cloud. Either of these will work excellently — or both, if you can afford it and want to experience different models and approaches.

GitHub Copilot provides access to models from multiple providers, including the best models like Anthropic’s Claude 4.5, OpenAI’s GPT-5.2, and Google’s Gemini 3. It also supports a wide variety of models from other providers. The Pro subscription is $10/month ($100/year) and is genuinely enough for most people getting started. Pro+ at $39/month adds more usage and access to additional models. You can also pay per use for additional requests if you need them.

Claude Code is the tool that kicked off the agentic coding revolution and remains one of the most feature-rich and sophisticated options available. It provides access to Anthropic’s models, including Claude 4.5 Opus, which tend to be excellent for coding tasks. You’ll need at least a Claude Pro subscription ($20/month) to use it, and most users doing substantial work will want Max ($100 or $200/month) for higher usage limits.

Both agents are available as extensions for VS Code, as command-line tools for the terminal, and as hosted web agents for asynchronous work (we cover all modalities in the course). Both have huge communities and all the latest features.

But What If I’m Using Something Else?

That’s great! This recommendation is specifically for people who are unsure where to start and want a straightforward answer. If you’re already comfortable with a different tool, or your team uses something else, or another option is more accessible or affordable for you — stick with what works.

In the course, we use GitHub Copilot and Claude Code frequently, but we teach the principles and techniques that apply across all tools. We help students work with whatever setup they have.

Need Help Getting Set Up?

If you’re joining the next cohort on January 12th, or you just want some hands-on help getting started, drop into one of the Sunday School: Drop-In, Vibe On sessions - completely free.

There’s a session tomorrow, Sunday December 28th, and another on Sunday January 11th (right before the course starts), then every other Sunday after that. Bring your questions, get unstuck, watch live demos. No preparation needed.

Create a dedicated folder for throwaway agent files and exclude it from git. A simple convention is to add a tmp/ directory at the repository root:

Create a tmp/ directory at the repository top-level and add it to .gitignore

With this in place, you can direct the agent to write working documents there:

Create a plan for testing the Foo functionality of the Bar component and save it to tmp/ so I can review it.

The agent produces something like tmp/foo-testing-plan.md. You review it, iterate on it, then ask the agent to implement. When you’re ready to commit, the plan stays out of your repository tree. Delete it when it’s no longer useful, or let it accumulate harmlessly until you clean up.

What belongs in tmp/

• Implementation plans — step-by-step approaches the agent will follow

• TODO lists — tracking progress across multi-step tasks

• Research notes — API documentation summaries, library comparisons

• Testing logs — output from test runs, debugging sessions

• Drafts — intermediate versions of code or documentation

The pattern separates the agent’s “scratchpad” from the repository’s permanent record. You get visibility into the agent’s reasoning without polluting your commit history.