We spend a lot of time talking about the future of AI, but we don't spend enough time looking at how the people actually building these tools are using them. If you listen to the marketing, AI is supposed to replace half your staff. If you talk to builders, you know it's mostly a tool for getting through the boring stuff faster.
The Utility Gap
Lately, there has been a significant shift in the discourse around large language models. The initial shock of what these models can do has worn off. Now, we are in the messy middle where founders and product managers are trying to figure out if these tools actually move the needle on productivity or if they just create more noise that needs to be cleaned up later.
When we look at the internal operations of a company like OpenAI, specifically their use of ChatGPT Sites, we see a pattern that every builder should pay attention to. They aren't using AI to dream up the next big strategy; they are using it to structure fragmented information. It is about taking the mess of internal documentation and turning it into something usable without requiring a human to manually tag every single page.
Practical Over Magical
For a founder, the biggest trap is trying to make AI do something magical. The real wins are usually much more boring. Jev, a product leader with deep roots in the space, has highlighted a few ways AI is actually landing in the real world. These aren't high-level abstract ideas; they are tactical workflows.
One of the most effective ways to use these tools is for technical synthesis. If you are a non-technical founder or a product manager working with a complex codebase, using an LLM to explain the logic of a specific PR or a legacy module can save hours of back-and-forth with your engineers. It acts as a bridge, not a replacement. It allows the humans to have a higher-level conversation because the AI handled the translation of the low-level details.
The Eight-Case Framework
When we break down real-world use cases, they usually fall into a few categories that matter to builders:
- Drafting and Scoping: Using the model to create the first version of a PRD based on rough notes. It’s never perfect, but it beats a blank page.
- Data Transformation: Taking messy customer feedback and turning it into a structured list of feature requests.
- Code Review Assistance: Identifying obvious logic errors before a human even looks at the code.
- Content Localization: Not just translating, but adapting tone for different markets at scale.
- Internal Search: Making the company wiki actually searchable using natural language.
- Customer Support Triage: Filtering the easy questions so the team can focus on the hard ones.
- Prototyping: Building functional front-end mockups in minutes to test a flow.
- Automated Documentation: Generating documentation as the code is written, ensuring it stays up to date.
None of these use cases are revolutionary on their own, but in aggregate, they change the speed at which a small team can operate. The skepticism comes in when people expect the AI to do the thinking for them. It can't. It can only accelerate the thinking you’ve already done.
Reframing the Developer Experience
The recent DevDay updates from OpenAI signaled a move toward making these tools even more integrated into the developer workflow. We are moving away from the chat interface and toward "sites" and applications where the AI is an invisible layer. For a founder, this is the signal you need to follow. If you are building a product today, your AI features shouldn't feel like a chatbot bolted onto the side. They should feel like a feature that just happens to be powered by an LLM.
The most successful AI implementations are the ones where the user doesn't even realize they are interacting with a model. They just know the task got done faster.
We saw this with the rollout of new developer tools that focus on real-time interaction and better context windows. The goal is to reduce the friction between an idea and a shipped feature. But as builders, we have to be careful. The easier it is to generate code or content, the easier it is to generate technical debt and low-quality output.
The Founder's Perspective
From where I sit, the biggest risk right now is "AI theater." This is when a company spends more time talking about their AI integration than they do solving a real customer problem. The use cases highlighted by Jev and the internal teams at OpenAI are grounded in utility. They solve the problem of "I have too much information and not enough time to process it."
If you are a builder, your priority should be finding the friction points in your own workflow. Don't look at what the hype cycle says you should be doing. Look at the tasks that your team hates doing. Those are usually the best candidates for an LLM. Whether it's summarizing meeting notes or drafting unit tests, the value is in the time recovered.
Real Talk on Integration
We need to be honest about the limitations. AI still hallucinates. It still misses context that a human would catch in a second. That is why the "human in the loop" isn't just a catchphrase; it's a requirement for building reliable software. When OpenAI shows off their internal tools, they aren't showing off a fully automated company. They are showing off a team that is better equipped to handle the scale of their own growth.
For those of us in the crypto and AI space, the convergence is going to be about data integrity. If we are going to rely on AI to help us build and manage our systems, we need to be able to trust the data going in and coming out. The transparency of a builder-first approach is the only way to navigate this without getting swept up in the nonsense.
The Takeaway
Stop looking for the killer app for AI and start looking for the killer workflow. The teams that win over the next two years won't be the ones with the most complex models; they will be the ones who integrated AI into their daily operations so deeply that it became invisible. Use it to bridge the gap between technical and non-technical teams, use it to clean up your internal data, and use it to get to the first draft faster. Then, get back to the actual work of building something people want.
Read the original at Lenny's Newsletter →