DocSummarizer Part 4 - Building RAG Pipelines

As AI agents grow in capability, more people feel empowered to code and contribute to open source. The ceiling feels higher than ever. That is a net positive for the ecosystem, but it also changes the day-to-day reality for maintainers. Maintainers like the goose team face a growing volume of pull requests and issues, often faster than they can realistically process.

We embraced this reality and put goose to work on its own backlog.

We actually used goose pre-1.0 to help us build goose 1.0. The original goose was a Python CLI, but we needed to move quickly to Rust, Electron, and an MCP-native architecture. goose helped us make that transition. Using it to triage issues and review changes felt like a natural extension, so we embedded goose directly into a GitHub Action.

Credit: That GitHub Action workflow was built by Tyler Longwell, who took an idea we had been exploring manually and turned it into something any maintainer could trigger with a single comment.

Before the GitHub Action

Before the GitHub Action existed, the goose team was already using goose to accelerate our issue workflow. Here's a real example.

A user reached out on Discord asking why an Ollama model was throwing an error in chat mode. Rather than digging through the codebase myself, I asked goose to explore the code, identify the root cause, and explain it back to me. Then, I asked goose to use the GitHub CLI to open an issue.

During that same session, goose mentioned it had 95% confidence it knew how to fix the problem. The change was small, so I asked goose to open a PR. It was merged the same day.

This kind of workflow has changed how I operate as a Developer Advocate. Before goose, when a user reported a problem, the process unfolded in fragments. I would ask clarifying questions, check GitHub for related issues, pull the latest code, grep through files, read the logic, and try to form a hypothesis about what was going wrong.

If I figured it out, I had two options:

1. I could write up a detailed issue and add it to a developer's backlog, which meant someone else had to context-switch into the problem later.
2. Or I could attempt the fix myself, which often led to more time spent and more back-and-forth during code review if I got something wrong.

Either way, the process stretched across hours or days. And if the problem wasn't high priority, it sometimes slipped through the cracks. The report would sit in Discord or a GitHub comment until it scrolled out of view, and the user would assume nobody was listening.

With goose, that entire process collapsed into a single conversation.

The local workflow works. But when I solve an issue locally with goose, I'm still the one driving. I stop what I'm doing, open a session, paste the issue context, guide goose through the fix, run the tests, and open the PR.

Scaling with a GitHub Action

The GitHub Action compresses that entire sequence into a single comment. A team member sees an issue, comments /goose, and moves on. goose spins up in a container, reads the issue, explores the codebase, runs verification, and opens a draft PR. The maintainer returns to a proposed solution rather than a blank slate.

We saw this play out with issue #6066. Users reported that goose kept defaulting to 2024 even though the correct datetime was in the context. The issue sat for two days. Then Tyler saw it, commented /goose solve this minimally at 1:59 AM, and went back to whatever he was doing (presumably sleeping). Fourteen minutes later, goose opened PR #6101.

The maintainer's role shifts from implementing to reviewing. The bottleneck in open source is rarely "can someone write this code." It's "can someone with enough context find the time to write this code." The GitHub Action decouples those two constraints. Any maintainer can trigger a fix attempt without deep familiarity with that part of the codebase.

This scales in a way manual triage cannot. A backlog contains feature requests, complex bugs, and quick fixes in equal measure. The Action lets you point at an issue and say "try this one" without committing your afternoon. If goose fails, you lose minutes of compute. If it succeeds, you save hours.

For contributors, responsiveness changes everything. When a user filed issue #6232 about slash commands not handling optional parameters, a maintainer quickly commented /goose can you fix this, and within the hour there was a draft PR with the fix and four new tests. Even if the PR is not perfect and needs adjustments, contributors see momentum.

Under the Hood

Maintainers summon goose with /goose followed by a prompt as a comment on an issue. GitHub Actions spins up a container with goose installed, passes in the issue metadata, and lets goose work. If goose produces changes and verification passes, the workflow opens a draft pull request.

But there's more happening under the hood than a simple prompt like "/goose fix this."

The workflow uses a recipe that defines phases to ensure goose actually accomplishes the job and doesn't do more than we ask it to.

The recipe also gives goose access to the TODO extension, a built-in tool that acts as external memory. The phases tell goose what to do. The TODO helps goose remember what it's doing. As goose reads through the codebase and builds a solution, its context window fills up and earlier instructions can be compressed or lost. The TODO persists, so goose can always check what it's done and what's left.

The workflow also enforces guardrails around who can invoke /goose, which files it's allowed to touch, and the requirement that a maintainer review and approve every PR.

There's something strange about using goose to maintain goose. But it keeps us honest. We're our own first customer, and if the agent can't produce mergeable PRs here, we feel it immediately.

The future we're aiming for isn't one where AI replaces maintainers. It's one where a maintainer can point at a problem, say "try this," and come back to a concrete proposal instead of a blank editor.

If that becomes the norm, open source scales differently.

The GitHub Action workflow is public for anyone who wants to explore this pattern in their own CI pipeline.

It’s been a while since we’ve seen one of these types of reports, and yet…..  Imani Williams reports: Thousands of medical records containing sensitive patient information were discovered in a Memphis storage unit that went up for auction after the owner failed to pay rent for three months. Jason Lederfine, who buys storage units as...

Source

Paul Thurrott is back to talk about everything that happened to Windows in 2025, and what that might hold for 2026.

The post RunAsRadio #1016: What Windows Wants for Christmas with Paul Thurrott appeared first on Thurrott.com.

Matt MacInnis is the chief product officer and former longtime COO at Rippling, a unified workforce management platform valued at over $16 billion.

We discuss:

1. Why “extraordinary results demand extraordinary efforts”

2. Why you should deliberately understaff projects, and how to know when you’ve gone too far

3. Matt’s transition from COO to CPO and what surprised him about leading product

4. The “high alpha, low beta” framework for evaluating people, processes, and products

5. When founders should quit their startups (hint: much earlier than VCs want you to)

6. How to fight entropy in your organization through relentless energy and intensity

—

Brought to you by:

Google Gemini—Your everyday AI assistant: https://ai.dev/

Datadog—Now home to Eppo, the leading experimentation and feature flagging platform: https://www.datadoghq.com/lenny

GoFundMe Giving Funds—Make year-end giving easy: http://gofundme.com/lenny

—

Transcript: https://www.lennysnewsletter.com/p/10-contrarian-leadership-truths

—

My biggest takeaways (for paid newsletter subscribers): https://www.lennysnewsletter.com/i/181916584/my-biggest-takeaways-from-this-conversation

—

Where to find Matt MacInnis:

• X: https://x.com/stanine

• LinkedIn: https://www.linkedin.com/in/macinnis

• Email: macinnis@rippling.com

—

Where to find Lenny:

• Newsletter: https://www.lennysnewsletter.com

• X: https://twitter.com/lennysan

• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/

—

In this episode, we cover:

(00:00) Introduction to Matt MacInnis and Rippling

(04:38) The importance of extraordinary efforts

(08:37) The challenges and rewards of relentless effort

(10:11) Your job as a leader is to preserve intensity

(12:39) You learn far more from success than failure

(16:34) Transitioning to chief product officer

(19:54) Fixing product management at Rippling

(25:27) The “high alpha, low beta” framework

(28:55) The PQL framework

(35:16) Hiring frameworks and team dynamics

(36:52) A helpful interview tactic

(40:00) Leading as a COO vs. a CPO

(42:34) The reality of product-market fit

(46:38) The problem with venture capital

(49:29) When founders should quit their startups

(41:48) The immutable market

(54:13) Lessons from Notion’s success

(57:43) Investment strategies and narrative violations

(01:00:42) The power of compounding, power law, and entropy

(01:07:02) Maintaining intensity and fighting entropy

(01:11:33) The importance of feedback and escalations

(01:14:31) Rippling’s vision and success

(01:17:48) AI’s impact on SaaS and business software

(01:23:42) AI corner

(01:26:23) Final thoughts and lightning round

—

Referenced:

• Rippling: https://www.rippling.com

• Sunil Raman on LinkedIn: https://www.linkedin.com/in/sunilraman

• Dan Gill on LinkedIn: https://www.linkedin.com/in/dangill

• Carvana: https://www.carvana.com

• Brian Chesky’s new playbook: https://www.lennysnewsletter.com/p/brian-cheskys-contrarian-approach

• Parker Conrad on LinkedIn: https://www.linkedin.com/in/parkerconrad

• Inkling: https://www.inkling.com

• Akshay Kothari on LinkedIn: https://www.linkedin.com/in/akothari

• Notion: https://www.notion.com

• Conway’s law: https://en.wikipedia.org/wiki/Conway%27s_law

• Seeking Alpha: https://seekingalpha.com

• Dennis Rodman’s website: https://dennisrodman.com

• Dancing pickle emoji: https://slackmojis.com/emojis/456-dancing_pickle

• Pickle Rick: https://en.wikipedia.org/wiki/Pickle_Rick

• SPOTAK: The Six Traits I Look for When I’m Hiring: https://finance.yahoo.com/news/spotak-six-traits-look-m-181335267.html

• Geoff Lewis on LinkedIn: https://www.linkedin.com/in/geofflewis1

• Zenefits: https://en.wikipedia.org/wiki/TriNet_Zenefits

• New banking records prove Deel paid thief who stole trade secrets from Rippling: https://www.rippling.com/blog/new-banking-records-prove-deel-paid-thief-who-stole-trade-secrets-from-rippling

• Workday: https://www.workday.com

• Matic robots: https://maticrobots.com

• Wall-E: https://www.imdb.com/title/tt0910970

• Conviction: https://www.conviction.com

• Mike Vernal on X: https://x.com/mvernal

• Sarah Guo on X: https://x.com/saranormous

• No Priors: https://linktr.ee/nopriors

• Gemini: https://gemini.google.com

• ChatGPT: https://chatgpt.com

• Claude: https://claude.ai

• Bryan Schreier on LinkedIn: https://www.linkedin.com/in/bryanschreier

• Heated Rivalry on HBO Max: https://www.hbomax.com/shows/heated-rivalry/50cd4e99-04ee-427b-a3b4-da721ed05d9c

• Fellow coffee maker: https://fellowproducts.com/products/aiden-precision-coffee-maker

—

Recommended books:

• Pale Blue Dot: A Vision of the Human Future in Space: https://www.amazon.com/Pale-Blue-Dot-Vision-Future/dp/0345376595

• Conscious Business: How to Build Value Through Values: https://www.amazon.com/Conscious-Business-Build-through-Values/dp/1622032020

• Thinking in Systems: https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557

• The Effective Executive: The Definitive Guide to Getting the Right Things Done: https://www.amazon.com/Effective-Executive-Definitive-Harperbusiness-Essentials/dp/0060833459

—

Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.

—

Lenny may be an investor in the companies discussed.

To hear more, visit www.lennysnewsletter.com



Download audio: https://api.substack.com/feed/podcast/181916584/2422f50f3e275fb97bde02d06941d714.mp3

Why You Probably Shouldn't Use Microservices (Yet)