Much of what is good for AI, is good for humans as well. Not just the benefits of AI tools, but the side effects of those tools being built.

Consider curb cuts for a moment, they’re the little ramps cut into the sidewalk that mean your bike, stroller, walker, wheelchair, or unicycle can get down to street level and back up again. They weren’t installed for unicycles and strollers though, they were installed for accessibility, but what was good for one group of people turns out to benefit the broader community.

To feed AI systems, tiny AI curb cuts are being installed. These aren’t as universal as literal curb cuts, but in many cases they spill over, especially if someone gives them a little extra nudge.

Search

If you want to implement a chatbot that has knowledge of your application’s domain, you’ll need to feed it custom data or context. This may be from support articles, source code, user data, or perhaps the broader internet. Regardless, to provide the right data, you need to be able to find it efficiently.

Taking a step back, if a site or even company has been around long enough, the data being searched has probably rotted. There may be duplicate entries, taxonomies that make little sense, or just information that is incorrect now. To give LLMs the best data, people now need to clean up that data.

To put it another way, building a RAG pipelines is predicated on improving search and data for AI and humans.

Accessibility

LLMs visiting your website may not be able to “see”, or at least not in pixels. Making web applications and content more legible to LLMs will typically make it more accessible to everyone.

This could be in the form of ensuring information is laid out logically and is easily navigable so that agentic research tools can find the right information. It could also involve applying the proper aria attributes and semantic markup to ensure agents can interact with your site reliably.

In both cases humans win (unless the site invests in llms.txt over making the site better.)

Unfortunately, from some basic testing I’ve found that frontier models are quite resilient to non semantic markup. Regardless, practices like replacing buttons with divs, or links with spans do seem to impair the LLMs.

That said, why tax the LLM, why not just make everything better for everyone?

Documentation

At a high level, agents need tacit information made explicit. They need the knowledge that floats around your organization tied up in neat little bundles, at least if you want them to be effective. With AI slipping into corporate workflows and customer support, a lot more is being written down.

Who wins? The AI does, but also the new hire, or the person outside the team looking in.

Another, more code specific side effect is that people are writing detailed AGENTS.md files and encoding knowledge into agent skills.

I find AGENTS.md files (and all their tool specific variants) to be concise encodings of a project or team’s priorities, norms, and architecture that we all should have been writing in the first place. Personal AGENTS.md files can be a fascinating window into what different engineers value.

Skills on the other hand are often treasure troves of concise and concrete information. Take supabase’s Postgres Best Practices skills. These don’t replace official documentation, but they are useful if you want a quick example of full text search or a succinct example of cursor based pagination.

Because AI is modeled on us

For better or worse, AI is a model of us, of what we write, say, and do. Perhaps it’s been trained on a bit more math and engineering and a bit less TikTok than the average person, but many of the problems AI faces are problems we face.

Either implicitly, or with an extra ounce of care, the solutions we put in place for AI can also be solutions we put in place for people regardless of whether we’re using AI.