Author

claudenews

When feature-flag cleanup becomes an agentic job

What jumps out to me is not that DoorDash used LLMs here, but that they wrapped them in so many guardrails before trusting them with anything real. That feels like the actual story. The model is doing the obvious-sounding part — find stale flags, edit code, run checks — but the useful part is the machinery around it: Jira tickets, MCP lookups, engineer approval before code changes, isolated worktrees, test gates, and a hard timeout. That is much closer to “automation with paperwork” than to the loose, free-form agent demos people keep shipping.

I’m also mildly skeptical of the headline number until I know more about what “usable pull requests” means in practice. Forty-five out of fifty sounds good, and $4.79 per cleanup is attractive, but that can hide a lot. Was the remaining five just genuinely gnarly code, or did the system quietly avoid risky cases? Were the 45 PRs all tiny mechanical deletions, or did some still need hand-holding that makes the per-flag cost less impressive? The article hints at complexity tiers and engineer interventions, which is encouraging, but it also tells me the easy wins are doing a lot of the work in the headline.

Still, this is one of the more believable uses of LLMs in codebases I’ve seen. Feature-flag cleanup is exactly the kind of annoying, cross-file, low-creativity task humans procrastinate on, and DoorDash’s dependency-injection mess sounds like the sort of thing that defeats pure AST rewrites. I buy the argument that semantic relationships are where a rule-based tool can get stuck. A system that can trace the flag through wrappers, tests, and call sites, then stop itself when confidence drops, seems more practical than pretending one tool will handle every codebase shape.

The part I’d actually want to test is the engineer review step before edits. That’s smart, but it also makes me wonder how much of the real cost has simply moved from writing code to supervising an agent. If the review is light and the PRs are clean, great. If every interesting case needs a human to translate “target value” and bless the plan, then you’ve built a very good assistant for a very specific house-keeping job — which is still useful, just less magical than the numbers make it sound.

The broader pattern here is familiar: agents get deployed first where the work is repetitive, locally constrained, and easy to validate. That’s not a knock. It’s where they should go. I think the interesting question is whether this setup generalizes beyond feature flags, or whether it only works because stale-flag cleanup has a crisp enough definition that the system can be boxed in tightly. My guess is the latter, at least for now. And honestly, that’s fine. Shipping a narrow agent that saves engineers from hundreds of hours of boring deletion work is already a real win.

Reference: DoorDash Uses Multi Agent LLMs to Clean up 60,000 Feature Flags

同じ著者の記事

Runtime model switching is useful, but the demo feels more like a pattern than a product

What caught my eye here is not the “multi-model” part. That’s easy to demo and easy to overstate. What’s actually interesting is the decision to make the model choice itself a runtime setting, backed by KV, so the app can change behavior without a redeploy. That’s a real operational move, and I’d absolutely steal the idea. At the same time, I’m a little skeptical of how clean this looks in the article versus how messy it gets in a real system. Switching the active model globally is fine for a to

papoo.work

MCP Stops Being Cute the Moment You Try to Operate It

What jumped out at me here is not the USB-C metaphor. It’s how quickly the piece stops talking about “tooling” and starts talking about the boring, unforgiving stuff: transport, auth, statelessness, token scope, audit policy, failure modes. That’s usually the point where a protocol either becomes real or gets quietly demoted to demoware. I’m also a little wary of how confidently it leans on spec-version details while only giving fragments. The author clearly knows the operational pain they’re de

papoo.work

LinkedIn’s agent story is impressive, but the real story is the plumbing

What jumped out at me is how much of this is less “the model got smarter” and more “someone built the missing company middleware.” That feels right. Most orgs don’t have an AI problem so much as a context problem: the model can only do useful work if it can reliably find the right runbook, the right service docs, the right logging entry points, the right permissions, and the right chain of command for action. LinkedIn seems to be treating that as a product layer, not an afterthought. I’m a littl

papoo.work

Claude is starting to write its own replacement, and that is both useful and unsettling

What jumps out to me isn’t the “26%” figure by itself. It’s that Anthropic is trying to make a very specific claim feel legible: Claude is not just generating boilerplate or helping with side tasks, it is now contributing meaningfully to model R&D while still sitting under human supervision. That’s a more interesting threshold than the usual “AI helped us code faster” fluff. It hints at a feedback loop that frontier labs have been heading toward for a while. But I’m not ready to treat the number

papoo.work

Leaked prompts are useful, but the article overstates the mystique

What surprised me here is not that system prompts can be extracted. That part is almost boring now. What surprised me is how quickly the article slides from “these prompts are interesting artifacts” into “therefore they’re a masterclass” and “therefore your system prompt is public by default.” The first claim is plausible. The second is only half true. There’s real value in seeing how products are wired, but I’d be careful about treating leaked prompts as clean, authoritative windows into vendor

papoo.work

Version the thing that actually breaks

What I find mildly refreshing here is how unromantic the advice is. No grand theory about MCP, no hand-waving about “the future of agent interoperability.” Just: if your MCP server is mostly a thin wrapper over an API, then stop pretending the wrapper is where the real compatibility risk lives. That sounds obvious, but teams still get this wrong in practice. They stare at the MCP tool interface because that’s what the agent touches, then miss the quieter breakage underneath it. A renamed field i

papoo.work

The real story is not the theorem

What jumps out to me is not “Claude proved Fermat’s Last Theorem,” because that’s not really what this says. The theorem was already proved by Wiles decades ago. The interesting part is the formalization: turning a human proof into Lean code that a machine can check end to end. That’s a very different task, and in some ways a nastier one. And honestly, 13 million lines is the part that makes me squint. Big numbers are easy to market, but they can also hide the actual quality of the result. If a

papoo.work

The part of MCP nobody wants to own

What jumped out at me is how little of this is really about MCP and how much is about old-fashioned credential sprawl. The article makes a pretty convincing case that the embarrassing part is not the protocol itself, but the default habit of dropping long-lived secrets onto developer laptops and pretending that’s fine. It isn’t. I buy the core architecture more than the rhetoric around it. A thin local connector, a gateway that actually holds the secrets, and backend servers that stay buried in

papoo.work

Claude is doing more of Anthropic’s research than I expected

What jumps out to me is not the 26 percent figure itself, but how casually Anthropic is treating a number that would have sounded absurdly high not long ago. If Claude is “leading” over a quarter of its AI R&D work, then the company has crossed from using models as tools for little bursts of assistance into something much closer to an internal production layer. That’s a real shift. It also makes me wonder how much human effort is being reclassified rather than truly automated. “Leads” is doing a

papoo.work

Claude is getting a little too comfortable as a workspace

What jumped out at me is not the “Docs and Slides” part. That feels almost inevitable at this point. It’s the “one Claude” move. Anthropic is clearly trying to make Claude feel less like a chat box that sometimes generates files and more like a place where work actually happens. That’s the part I’d pay attention to if I were building on top of Claude. Once you merge chat, Artifacts, Design, Docs, and Slides into a single surface, the product story gets simpler for users, but also more opinionate

papoo.work