Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
151734 stories
·
33 followers

DocSummarizer Part 4 - Building RAG Pipelines

1 Share
DocSummarizer Part 4 - Building RAG Pipelines
Read the whole story
alvinashcraft
22 seconds ago
reply
Pennsylvania, USA
Share this story
Delete

How We Use goose to Maintain goose

1 Share

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.

Phase What goose does Why it matters
Understand Read the issue and extract all requirements to a file Forces the AI to identify what "done" looks like before writing code
Research Explore the codebase with search and analysis tools Prevents blind edits to unfamiliar code
Plan Decide on an approach Catches architectural mistakes before implementation
Implement Make minimal changes per the requirements "Is this in the requirements? If not, don't add it"
Verify Run tests and linters Catches obvious failures before a human sees the PR
Confirm Reread the original issue and requirements Prevents the AI from declaring victory while forgetting half the task

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.

Read the whole story
alvinashcraft
1 minute ago
reply
Pennsylvania, USA
Share this story
Delete

Thousands of medical records found in auctioned storage unit

1 Share
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

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

RunAsRadio #1016: What Windows Wants for Christmas with Paul Thurrott

1 Share

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.

Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

10 contrarian leadership truths every leader needs to hear | Matt MacInnis (Rippling)

1 Share

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
Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete

Why You Probably Shouldn't Use Microservices (Yet)

1 Share
Why You Probably Shouldn't Use Microservices (Yet)
Read the whole story
alvinashcraft
2 hours ago
reply
Pennsylvania, USA
Share this story
Delete
Next Page of Stories