Larry Hendrix

Coding agents make traditional READMEs obsolete. Not because documentation doesn’t matter. But because static summaries of dynamic systems don’t scale. READMEs today: • Go stale fast • Nobody wants to maintain them • Slowly turn into technical archaeology They’re snapshots of a moving target. Coding agents change the interface. Instead of reading a compressed summary, you can: • Analyze the codebase in real time • Trace git history for architectural intent • Ask “why is this like this?” and get contextual answers • Generate setup instructions dynamically No staleness. No maintenance burden. No drift from reality. So what happens to READMEs? Two paths: 1) They disappear. Onboarding becomes “ask the agent.” 2) They shrink. Documenting only what’s outside the repo (3rd-party configs, env variables, human processes). And even that may fade as agents integrate directly with external systems. The README’s original job was compression. Coding agents remove the need for compression. We’re moving from: “Here’s a summary of the system.” To: “Interrogate the system itself.”

20

28 Comments

Even frontier LLMs can use a helping hand when it comes to detailed API documentation for fast-moving open source libraries and tools. I put together a quick cheatsheet generator, and a repo of cheatsheets (generated by LLM, of course, from the source projects' github docs repos). Example for Bun: https://lnkd.in/gAYCU5bz #bun #llm

15

There's an unfortunate trend in technical publishing where "Modern" in the title usually means "will be outdated by Thursday." Jesús Espino's (whom I'm glad to have met in Florence this year) new book on REST API development in Go earns its prefix through an almost rebellious act: it champions Go's standard library over the framework-of-the-month club we've all joined at various points in our careers. The thesis here is simple and mildly subversive. You can build production-grade APIs without immediately importing half of GitHub. Want middleware? Write it yourself first with http.Handler. Need an ORM? Understand database/sql before you reach for GORM. This "pedagogical restraint" is rare enough to be noteworthy and valuable enough to be worth your time. What actually impressed me was the book's structural honesty. It doesn't pretend you architect everything perfectly from day one. This mirrors how real systems actually evolve, which suggests Espino has actually maintained services that kept him awake at night 🤣 . The book builds a shopping list API incrementally across chapters, adding authentication, security, caching, and deployment strategies as you go. The real value proposition isn't that this book will make you an expert. Nothing does that except building and maintaining real systems. But it will give you the mental models to become one. In an industry addicted to complexity and novelty, a book that demonstrates how to build things simply and well with concrete examples is almost subversive (really). It won't revolutionize how APIs are built, but it will make you better at building them. Sometimes that's exactly what you need.

64

5 Comments

AI Definitely Replaces Engineers I had some Python code in a personal project that prepares data for an Astro/Node.js website and decided to use Claude to improve it. Rather than refactor my existing 20-line script, Claude decided to completely rewrite it as a 200-line JavaScript file with raw string parsing for quotes and commas. When I suggested using a proper CSV library, it dutifully implemented my feedback. Then, like many engineers I've worked with, it got frustrated when the library didn't work on the first try and quietly reverted back to the manual parsing approach—while confidently telling me what an excellent job it had done. Technically, it did follow my instructions since it used the library... for about 10 minutes. When I finally pointed it to a specific, well-documented library, Claude implemented it correctly and once again praised its own brilliant solution. Fun Fact: My original Python file was only 20 lines because it used pandas to parse a gzipped CSV, and this would have taken 30 seconds for me to add a column. So yes, this AI session was exactly like working with past engineering teams. The only thing missing is Claude boasting to the business how much smarted it is than the rest of the team. #AI #SoftwareEngineering #TechHumor #Claude #Development

104

21 Comments

Agentic Coding Tools Are Forcing Better Documentation Anyone who’s joined an existing product knows the pattern. The "why" is often locked in tribal knowledge. Decisions, tradeoffs, and historical context are missing, outdated, or never written down. Documentation was created once, checked off, and forgotten. Agentic coding tools (Windsurf, Claude Code, etc.) make that impossible to ignore. These tools don’t just generate code. They reason across a codebase using context, constraints, and intent. That makes documentation a first-class input: → design intent → conventions and standards → explicit guardrails In large codebases, consistency won’t come only from reviews anymore. Documentation becomes part of how these tools behave. Bad docs don’t just slow teams down. They create risk — and agentic tools will amplify it. Well-maintained documentation lets both humans and agents move faster, with confidence. #AgenticAI #Documentation

20

We just released Taro's newest course about what life is really like at FAANG. So much of the discussion about working at FAANG focuses on things like the scale of the work or the free snacks. But on the day-to-day level, an engineer at Google or Facebook doesn't think about these topics. They are spending most of their waking hours on things like: - how much scope do they have? - how much control do they have vs just being a cog in the machine - what do their coworkers think about them? As a 5 year veteran of Meta, I break down the real pros and cons of working in Big Tech. Check it out here: https://lnkd.in/gfkwVDf9

58

4 Comments

If coding agents struggle to work with your code so will humans. Agent friendly code bases, are also human friendly. Human co-pilots use agents to make your code base more agent and human friendly.

44

2 Comments

When abstractions stabilize, code becomes habitable—and “LLM-friendly.” If your code uses small, intention-revealing helpers (e.g., write(), read(), partition(), delayWritesFrom(), and a HistoryRecorder that emits Jepsen EDN), you can prompt an LLM with paragraph from the book and get runnable tests for concrete scenarios. People reading patterns from my book or the DDIA book can try this with Tickloom. For example, see an interesting scenario from DDIA 10.6 section on 'linearizability and quorum' https://lnkd.in/dWMreGru Jepsen integration makes it concrete. #DistributedSystems #DDIA #Jepsen #LLM #Tickloom

26

1 Comment

Rails 8.2 just fixed a silent pain we all had. Managing secrets in Rails has always been… split. Some in ENV, Some in credentials.yml.enc. Different APIs. Manual fallbacks. Code changes when moving secrets around. Rails 8.2 introduces: Rails.app.creds::Combined Credentials One unified API. ENV first. Encrypted credentials second. Same behavior for nested keys, defaults, and errors. It just works. Even better? You can plug in your own backend: Vault. 1Password. AWS Secrets Manager. Move secrets between ENV and encrypted credentials without touching your app code. Small feature. Big developer happiness win.!! Rails keeps getting sharper. #rubyonrails #rails #rails8 #webdevelopment #backend #programming #devtools #ruby

37

1 Comment

LangChain's Harrison Chase thinks Claude Code killed the pure-play coding agent business model. When foundation models go deep in a specific domain, you can't win by building "a better version." The file system tool that makes Claude Code powerful for coding could actually work better for research agents, taking notes and building context over time. Most LangChain users build agents for legal workflows, customer support, and data analysis -  domains where Anthropic isn't training specialized models. The real challenge becomes teaching agents your specific business logic when they weren't trained on your mental model of the world. Differentiation has to come from workflow integration, infrastructure, or entirely different problem domains. Full episode: https://lnkd.in/edbje2WN

15

2 Comments

We don’t hire software engineers to solve LeetCode problems. We hire them to design scalable architectures. Debug complex systems. Balance speed with security. Collaborate with humans. And navigate messy, ambiguous problems. But too many interviews still boil down to: “Solve this algorithm puzzle under time pressure.” LeetCode rewards memorization, not engineering judgment. It filters for people who had time to cram, not the ones who’ve built secure, reliable systems. If you want to hire great engineers: Give them real-world scenarios. Let them talk through constraints and risk. Watch how they think—not how fast they recall a pattern. Because building software—especially secure software—isn’t about regurgitating solutions. It’s about understanding the problem well enough to solve it.

87

19 Comments

Mid-refinement today we hit a classic: a capitalization bug buried in legacy code. One teammate shrugged, “We’ll tackle it in a few sprints.” While the timeline debate continued, I asked GitHub Copilot and Claude 4: “Show me where category-title capitalization occurs—string formatting is off.” Thirty seconds later, the rogue regex popped up. “Refactor it, elegantly.” By the time the meeting concluded, the pull request was awaiting reviews. Takeaway: the bug wasn’t hard—just hidden. AI compressed the archaeology from hours of grep and context-building to seconds of conversation. The real leverage now isn’t in finding problems—it’s in choosing the fixes that will meaningfully move the system, and the business, forward.

19

1 Comment