DEV Community: Richard Smith

Docs built for humans, broken for AI agents

Richard Smith — Thu, 09 Jul 2026 23:14:18 +0000

I keep hearing the same complaint from developers building AI agents: their docs don't work. Not because the content is wrong, but because it's structured for humans—for navigation, not for retrieval by an LLM trying to use it autonomously.

AgentDocs caught my attention because it's a conversion layer, not just another doc platform. It takes what you already have—Markdown, Notion, Confluence, OpenAPI specs—and transforms them into agent-consumable formats: structured JSON, semantic chunk hierarchies, retrieval-optimized embeddings. The mechanism is concrete. You're not replacing your docs, you're reformatting them so agents can actually use them.

Here's the angle I'm sitting with: when an agent hallucinates an API call, you currently spend hours debugging whether it's the prompt, the model, or the retrieval. With docs structured for agents from day one, that whole class of debugging shrinks. The emotional payoff is knowing your docs are correct by construction.

The micro SaaS model feels clean: $29–$99/month for indie devs and small teams, $299–$999/month for enterprise. Start in LangChain Discord and agent dev Slack groups—the exact people who've already hit this wall.

I'm genuinely uncertain about timing here. Is this pain urgent enough that devs will pay now, or does it need the ecosystem to mature first?

I Think There's a Product in This: Triage for AI-Generated Code

Richard Smith — Tue, 07 Jul 2026 23:16:39 +0000

I've been using AI coding tools more heavily lately — Copilot, Cursor, sometimes Claude directly. The velocity is real. Features that used to take days are done in hours.

But there's something that's been bothering me: I'm generating code faster than I can review it. If AI writes your code, you end up shipping PRs faster than your review capacity. The manual review bottleneck becomes obvious — you're either rubber-stamping everything or slowing down to actually look at it.

I think there's a product in this.

The idea is a lightweight layer that sits in your GitHub PR workflow and auto risk-scores AI-generated changes. It flags which hunks need human attention (security-sensitive paths, complex logic, untested branches) and which are safe to auto-approve. The target user is clear: individual developers and small teams using AI code generation who are bottlenecked on review.

The advantage is specificity. Not "saves time" — it tells you exactly which diffs need eyes and which don't.

Go-to-market would start in the communities already experiencing this friction — Cursor Discord, GitHub Copilot forums, AI coding subreddits. Free tier with 50 PR analyses/month, then $15-29 per seat for unlimited.

I'm still deciding if the technical challenge of reliable triage is worth the effort. What do you think — is this a real pain point, or am I overthinking it?

Found a gap in the bookkeeping automation chain

Richard Smith — Sun, 05 Jul 2026 23:16:14 +0000

I keep seeing the same complaint surface in founder communities: your automated bookkeeping is solid until one vendor decides not to email their invoice. Then you're manually logging into dashboards, downloading PDFs, and the whole "set it and forget it" dream falls apart.

The mechanics would be straightforward — a browser extension paired with scheduled scraping that accesses vendor portals, pulls missing invoices, and routes them to accounting tools in a standardized format. The target is clear: solo operators and small teams juggling multiple SaaS subscriptions who depend on seamless reconciliation.

What stands out is how visible this pain already is. There's genuine frustration in forums about vendors who skip email invoices, and accountants themselves could become advocates, recommending the tool to their small business clients. Starting at $9/month with a free tier for a few integrations feels like the right entry point to test demand.

The question is whether this is worth building — or if there's already something handling this that I'm missing.

The Neat Trick That Made AI Write Code Our Team Actually Wanted

Richard Smith — Thu, 25 Jun 2026 23:07:41 +0000

I've been thinking about this idea for a few weeks now. Instead of fighting with AI agents to follow conventions, what if you just made the wrong thing impossible?

That's the gist of what Ryan Lopopolo's team did at OpenAI. They encoded their team's taste as failing tests. Curly quotes instead of straight quotes? Build fails. Component in the wrong package layer? Build fails. The agent can't produce slop because slop won't compile.

The thing that stuck with me is how much this changes the feedback loop. Normally you'd review a PR, leave comments, the author revises, repeat. With tests enforcing taste, you skip most of that entirely. The agent gets immediate signal. We get consistent output without micromanaging every decision.

I tried something similar on a side project. Added a few conventions as tests before letting an AI touch the codebase. The diff quality went up noticeably. Not because the AI got smarter, but because the guardrails got tighter.

Still figuring out where the line is though. Too few tests and things drift. Too many and you're fighting yourself. Anyone found good heuristics for how much to encode?

The AI Window Is Open. It Won't Stay That Way Forever.

Richard Smith — Tue, 23 Jun 2026 23:09:45 +0000

I lived through the mobile era in Silicon Valley. For about four years, you could just build something, put it in the store, and people would find it. Then the gold rush ended. Distribution got hard. The window closed.

Now I'm getting that same feeling with AI, but bigger. The difference is I'm older now, and I know what these windows look like. I know they close.

New models, tools, and repos keep dropping. Things that felt impossible last month are trivial today. My partners and I are up late most nights sending each other screenshots, saying "look what this can do." Nobody asks anyone to do this. We just can't stop. Something drops, someone builds with it in a few hours, and the group chat explodes. It feels like we're getting away with something.

The anxiety isn't about whether this is real. It is. The anxiety is making sure I don't waste this moment. Some of the best companies of the next decade will be started in the next few years. I'm sure of it.

So what are you building?

Don't Build Your AI Business on Borrowed Land

Richard Smith — Tue, 23 Jun 2026 03:19:41 +0000

There's a pattern I've been noticing in the AI tools space that bothers me. Developers and small companies are building entire workflows around closed AI platforms, and it feels comfortable until it isn't.

The "harness wars" are real. Every major AI provider wants to be the platform you build on. They offer sweet APIs, generous limits, and seamless integrations. But here's what nobody says out loud: if your entire product is just a wrapper around someone else's AI, you're sharecropping. You're doing the work, taking the risk, and someone else controls the land.

The telltale sign is data portability. How easy is it to export everything you've built? If the answer is "not very," that's the lock-in speaking. Real platform openness means your data should flow freely, not get trapped in someone's ecosystem because it's "convenient."

I've seen this before with other tech shifts. The companies that survived weren't always the flashiest—they were the ones who owned their customer relationships and understood their core value separately from any single tool.

The question I'm sitting with: when the AI landscape shifts (and it will), what will you actually have left?

What's your take on building in the AI space right now?

Don't Build Your AI Business on Borrowed Land

Richard Smith — Tue, 23 Jun 2026 03:11:40 +0000

The question I'm sitting with: when the AI landscape shifts (and it will), what will you actually have left?

What's your take on building in the AI space right now?

Why I Keep Exploring Startup Ideas (And When I Finally Commit)

Richard Smith — Sun, 21 Jun 2026 23:17:53 +0000

I've been doing the idea exploration thing for a while now. You know how it goes — broad scanning, jotting down possibilities, following threads, getting excited about something, then finding a reason to move on. It feels productive. It feels like thinking.

But at some point, you have to stop searching and start building. And that transition is where I keep getting stuck.

The problem isn't generating ideas. With AI tools and all the content out there, there's no shortage of directions to explore. The problem is conviction — that quiet but firm belief that a particular idea is worth your time for the next six months, a year, maybe longer. Without it, you second-guess every decision, abandon ship at the first sign of friction, and end up with a graveyard of half-built things.

What I've found helps is forcing a constraint: set a date to go deep, not just to decide but to start building something real. A landing page, a prototype, even a bad version. The act of making something concrete sharpens your judgment in a way that thinking never does.

Has anyone found a better way to build conviction without wasting months on the wrong idea?

What happens when your potential customers can suddenly build what you're selling?

Richard Smith — Thu, 18 Jun 2026 23:10:51 +0000

A dynamic I'm noticing shift: potential customers who previously needed convincing are now building their own solutions.

A few months into watching coding agents mature, I've noticed something unexpected. The "champion" problem — that person at a company who loves your product enough to fight internal battles for it — is getting both easier and harder. CEOs and CTOs who previously couldn't evaluate technical decisions are now shipping real software. They understand tradeoffs viscerally, not just conceptually.

This means they're better partners when they adopt something external. But it also means they're more skeptical. They know what a weekend project can accomplish. When I talk to founders struggling with enterprise sales, I wonder if the dynamic is already shifting. The executive who codes doesn't need as much hand-holding — and they might not need you at all if the problem fits a coding agent workflow.

Anyone else noticing this? How are you thinking about the competitive landscape when your buyer can build alternatives themselves?

The AI Revolution Is Quiet, and That Should Excite Founders

Richard Smith — Wed, 17 Jun 2026 02:59:58 +0000

Six months ago, I was talking to a non-tech friend about what I was building. I mentioned AI agents, recursive self-improvement, and the pace of model capabilities. Their response was polite but distant. "Isn't AI just chatbots now?"

That gap between what's actually happening in tech and what's being noticed outside of it is striking. The tools for building with AI have become genuinely powerful, and the conversation in tech circles has shifted toward autonomous agents, recursive improvement, and systems that compound in capability. But most people outside our bubble haven't felt it yet.

For founders, this is interesting. There's a window where the people building the tools understand the landscape better than the market does. Ideas that seem obvious to someone in the space might still be genuinely novel to a potential customer who's just starting to notice that "something is changing."

I'm not saying the hype is real in every direction. But when I look at what I can actually build now versus six months ago, the gap is substantial. The question I'm sitting with is: what do people actually need that only becomes possible with this jump in capability?

Anyone else feeling that tension between building fast and waiting for the market to catch up?

AI is moving from simulation to the physical world. Here's what that means for builders.

Richard Smith — Tue, 16 Jun 2026 23:07:24 +0000

The tweet about OpenAI Robotics caught my attention not because of the job postings, but because of the trajectory. World simulation → physical robots. That's a meaningful shift.

For the past couple years, a lot of AI energy went into generating images, videos, and text. Convincing digital worlds. Now there's a push toward actually affecting physical ones—robots that manipulate objects, that build things, that exist in the real world.

What does this mean for indie hackers and solo founders? A few observations. The tooling and infrastructure for robotics is still early enough that there's room for specialized, focused products. The intersection of simulation and real-world deployment creates interesting technical challenges that don't require a massive team to tackle. And "useful in the physical world" still feels like an underserved promise of AI.

I'm not suggesting everyone should go build robots. But watching where the big players are investing gives you signals about where the puck is heading. The question I'm sitting with is: what are the niche, specific applications of this shift that a small team could actually own?

Curious what others are thinking about AI moving from screens into physical space.

Why I Stopped Chasing "Fundable" Ideas

Richard Smith — Mon, 15 Jun 2026 08:48:36 +0000

Last year I caught myself picking startup ideas based on what VCs funded, what got upvoted on Product Hunt, and what seemed safe enough to raise money around. I wasn't building—I was auditioning.

The Bezos patience thesis hit different when I really sat with it. The competitive moat isn't the idea. It's not even the execution. It's the willingness to outlast everyone else in the arena. But here's the thing nobody talks about: you can't fake that patience on a problem you don't actually care about.

I watched three promising indie projects die in their first year because the founders chose problems that were "solvable" rather than problems that kept them up at night. The moment things got hard—and they always do—the safe ideas lost their shine.

So I started asking myself different questions. Not "will this raise?" but "will I still care about this when I'm 40?" Not "is this market big enough?" but "do I actually want to serve these people for a decade?"

The honest answer ruled out a lot of ideas. But it also made the remaining option feel different. Less like a gamble, more like a commitment.

What problem would you actually stick with when everyone else has quit?