I’m hiring smart engineers excited to do product development with AI in Toronto so drop me a message if this sounds interesting to you.

In early 2026 we’re noticing a strong move away from traditional SaaS products and a rapid adoption of custom software. Customers paying per-user for massive suites of software (comprising features that are largely unused by the majority of customers) has lost its appeal in the face of more readily available bespoke solutions using AI tools like Claude Code or Claude Cowork. In our work we’re looking to pass on that benefit to our customer and do more for less which has attracted a pragmatic tier of interested founders and business leaders.

This has been noticed by general engineering consumers too. I specifically enjoyed this post about spending a weekend replacing software subscriptions using AI coding tools. I’ve recently done the same thing to replace Zoho Books with my own tool for easily managing business features. I never used the full set of features anyway and by replicating the features I actually use, I was able to even personalize those features to better fit my needs.

One underlying reason why building a custom solution is compelling is because it removes a “data island”. With SaaS software there’s a general attempt to lock-in the user to their system by holding a user’s data hostage. GDPR has helped in this sense because users are able to receive a raw export of their data on demand, but the interface for building live solutions on top of these software is often painful. If you want to build a custom AI tool that matches your data, you need easy access to that data. Frankly SaaS has mostly gotten in the way here as a result of their business model.

As it gets easier to build custom workflows and applications, it becomes more and more rewarding to gain control of the data these systems need. Rather than having an agent struggle with an API interface, run up against rate limits, or deal with data access gaps why not build the same solution with an interface that matches what your system needs? Interfaces and integrations remain one of the most important conversation topics when thinking about AI adoption.

As I’ve continued building on Benny Chat I’ve been transitioning how I work with third-party services. I went from leveraging MCP Servers for their ease of setup, to extracting those servers into custom tool hooks for AI agents, to now looking at removing the third-parties entirely and building my own. Todoist for example has an amazing API interface for managing tasks and has recently been leaning into AI features but how hard would it be now to just replace it for what I need.

The only concern is as we do these things are we not creating the same islands of data that we were trying to get away from? Perhaps data capture isn’t the right approach. I regularly use Obsidian and one of the features I rely on the most for integrating it with AI is that it’s built on a bunch of files sitting in my local filesystem. Almost any tool can read files. Because of this Obsidian doesn’t isolate their data on a data island and instead allows it to be easily accessible. As we look to build solutions for our own needs, it’s important we don’t accidentally isolate ourselves from our own data just because that’s the shape SaaS software has embedded in our minds for the last decade or more.

On Oz

Oz by Warp.dev released last week and presents an interesting tool for facilitating the use of AI agents. It’s an agent orchestrator that helps users define containerized environments where the agents can run. While I’m still experimenting with the tool, I have a few initial impressions.

I’ve been working on a process for compiling the dozens of email newsletters I receive on different topics down into a single digest of linked articles. I filter based on preferences Claude helped me pull out of previously highlighted articles I read in my reader app, Matter. I’ve been incrementally improving this system by reading an email at a time and ensuring that the AI is correctly using my preference to select linked articles. Having finally gotten to a point where there’s trust in the system, I’m at a point where automatically kicking off this process might make sense.

Oz did a great job of connecting to my code repository, automatically discovering the skills I’ve been developing, and allowing me to set private keys for giving my agent access to my email. Kicking off jobs and testing the system, I noticed that the behaviour of the runs changed which makes sense. Oz isn’t running Claude Code, it’s running on its own agent scaffolding which means that there’s a bit of an adjustment for my processes to run in their system. The iterations I’ve done to hone my process needs to be redone in their system to make the process reliable and this friction is annoying enough to turn me off of Oz.

While my use case is a largely personal one Oz was developed to solve a range of problems for teams. I’m solving similar concerns these days with Github Actions kicking off Claude Code jobs, pipeline tools like Trigger.dev, or custom LLM apps that can run processes on demand. While Oz offers a convenient interface for teams to use, I’m not sure if I like the process island that they’re forming. Do I really want all of my agentic processes to shift to going through their system? Especially when that might mean refactoring all of my agentic processes to better match their system. It’s enough to give me pause.

Impressive Agentic Feat of the Week

I recently migrated a Squarespace website of over 7,000 pages to a static NextJS app in just 5 hours. I leveraged AI scraping tools to get the raw data, batch LLM jobs for data transformations, and numerous `bun` scripts to extract, transform and load all of the content of the site. I scripted the migration of all of the images to GCS and wrote a simple image manager interface for uploading new content.

I’ve used a number of techniques we’ve been developing with our teams at Rangle and have been inspired by the work we’ve been doing in this space. Working on a handful of real businesses pushing with agentic processes has massively expanded what I thought was possible to accomplish and I’m thrilled I’ve been able to more and more consistently reproduce these great outcomes.

One thing that has become abundantly clear in the work we’ve done is that we’re never aiming to one-shot an outcome. Coming up with a singular perfect prompt doesn’t magically get you great results and I still see a lot of problematic practices with the adoption of agentic “skills” that offer the promise of perfect outcomes from essentially prompts. It seems like two things often produce the best outcomes: knowledge and taste.

When I work to create something with agentic processes I do a lot of shaping. I work at the plan layer multiple times, I run small samples of tests, and I try to shape the result before I let the agent fully attack the problem. That shaping is an active process that does feel slow at times but that ultimately produces a better result than a single run would do. I will actually let it run sometimes too but in those cases the result is a throwaway.

A big reason to throw away large generative work is to avoid being “pulled” by AI rather than being the one “pushing”. Where I’ve left gaps in my ideas, AI will try to fill in. Those helpful adjustments are painful when those details matter and they shift my work from dictating to analyzing to provide feedback. Sometimes this cleanup process is helpful but if you stay in this mode for too long you lose all semblance of structure and intent. You become a servant to the machine.

Planning is the new coding. Approach it with the same intentionality and rigor, and it will reward you well. And as you build, resist the gravitational pull of the SaaS mindset — whether that’s a vendor holding your data hostage or a shiny new tool asking you to restructure your workflows around theirs. The moment you stop owning your data and your process, you’re paying more than just the subscription fee.

If you’re unfamiliar this video is a helpful overview of the features:

My initial impressions offer a more nuanced experience than the chipper attitude of this presentation which should help you get a balanced perspective.

Using Antigravity

Agent Manager

This interface feels like a move in the right direction. It offers a means of managing the work done by an agent, ability to see and respond to plans easily, and clear indication of changes made. I like the Agent Manager’s UI but it’s been a little buggy so far. I made some good changes but it is missing some of the context I have in my CLAUDE.md files on how I wanted it to build the app. I’m not sure if it’s reading some of my core information files or docs.

Knowledge

The knowledge base feature looks interesting but in the two medium-sized features I created it didn’t seem to think this needed to be updated. Unsure when it will feel there’s something worth of it. As with all AI memory systems I do worry about it getting the wrong idea and storing that idea for later use.

Intelligent Tool Approval

Antigravity lets the model choose when to run a tool in some cases rather than stopping to ask for permission. This is a cool concept if it works well and I’m curious to explore with this further. I worry that seemingly innocent commands may look non-destructive and get called anyway by the model despite causing some destructive change. This may require a metadata layer similar to how MCP servers have expanded their interfaces to include if a tool mutates data.

Browser Tool

It’s great to see them add a tool for interacting with the code as it’s actually run. However, my initial setup of their browser didn’t seem to workout very well. I installed the extension but the agent had difficulty finding the extension. Eventually it seemed to work when I opened up a new tab after closing Chrome.

Since Chrome isn’t my main browser, it’s not setup quite right for the application I was testing but it worked well on a later project. It seems to be able to record, capture screenshots, and read the console.

Commenting

Having a highlight and comment system on AI plans is plain great UX. In existing solutions I find that there are often times where I’m opening a note or something to put my feedback in and then scrolling down and pasting that feedback into the chat input at the bottom of a agent chat window. When I made comments, it seemed like they were factored in appropriately when I asked the model to apply them.

The pitch of this feature sounded good but I’m curious how the model thinks about incorporating feedback like this in practice.

Gemini 3 Pro (High)

I’ll pay it a good compliment in saying that this model felt a lot like Claude Sonnet 4.5 to the point that I felt like it was working with me in the same way I’m used to. It’s not often that happens when switching models. That said, I still didn’t get my context appropriately in the conversation and worry a bit if I have to start all of my conversations with it saying Read @CLAUDE.md before we can start working.

On release day there’s always a lot of strain on these models and this was no different. There were a couple times I needed to leave and come back when working through the features to let the global limit cool off a bit. Hopefully the usage gets a bit more predictable and lets more people use this regularly.

Onboarding

When I launched Antigravity and onboarded, the onboarding crashed on the final step. Then I had to go through it again and even though I had indicated I wanted it to pull in settings from my Cursor, it ignored that and didn’t pull in any of my extensions or config. This is definitely a headwind in my adoption journey but something that is likely to get fixed with time.

Takeaways

I built out two features at the same time to explore the agentic capabilities of the Antigravity IDE. One feature was to add notes for users in a feed and the other is to allow users to upload images to Google Cloud Storage using a rich text field. However, I think having the changes happening in parallel was a bad idea.

Part of me assumed these changes would exist in separate worktrees or branches so that they wouldn’t conflict. Some of the demo videos made that seem like it might be the case but no, it’s the same as running two separate Claude Code instances in the same repo. Just a new UI.

Ultimately, I wanted to put Antigravity through its paces, but running two things at once confused me a bit while learning a new tool. It also seems to have confused the interface too because one of the agents just stopped responding to my prompts after it tried unsuccessfully to test the feature in the browser. The other agent completed it’s work fine but in the Review tab was still showing both sets of changes which was, again, confusing.

At the end of my coding session I had problems determining how to progress and what to do with the resulting conversations. There’s an ability to review the changes and provide feedback but it’s still a bit confusing how to get the IDE to commit the change from the Agent Manager view. When I did merge I also didn’t know what to do with the conversations. I wish there was an archive feature or something as deleting these conversations doesn’t feel great especially when the Knowledge doesn’t seem to update.

To complete my changes, I ended up just switching back over to Claude Code as that seemed to have overall better context on what I was building and I had better muscle-memory as to how to progress a late stage change.

In Antigravity, there’s a lot of really great intentionality around context but some of the control around context does feel limited. Because it’s a “smart system” there’s a lot less control. That’s helpful in someways but also makes it more difficult to understand exactly what’s going on at any time.

I keep noticing some things I’ve come to appreciate about other interfaces that are missing here. One example is queued changes in Claude Code. If there’s a string of commands that make sense to just run one after another, it’ll queue them up. I find that while the auto approval works well in Antigravity, but I find there are times where I need to wait to approve several changes that were clearly known in advance that could have been approved without delays between each approval.

Release Article & Videos

The release blog mentions “Gemini 3 is also much better at figuring out the context and intent behind your request” but I haven’t found this to be the case. Jumping into an existing codebase some of the core NextJS architecture I had in place for version 16 was ignored despite clear indications. That said, many of the solutions create were well done. They just didn’t retain the high context as this blog post might indicate.

In the getting started video, it was refreshing to see the a Google engineer directly trust the AI with his API key. I think that’s honestly the norm in a lot of cases depending on how permissive the keys are. It enabled the AI to explore and investigate the API with context of the interface due to some Googling of the interface from the web. In all honesty, this is a pretty likely use case for most devs.

Agents Testing During Research

It’s amazing to see the impact of the Intelligent Tool Approval when it comes to agents doing research. That’s where there’s a bit of magic in this release. This makes me think that this might be one of the better agentic interfaces to do coding research within.

Nano Banana Image Gen

It’s awesome to have an image generation module as powerful as Nano Banana running directly in the IDE. It can generate assets and directly add them to the application. That’s pretty incredible. (no transparent backgrounds though unfortunately)

Next

I’m intrigued by Antigravity but it’s still feeling a lot like a Beta of something that could be cool. It’s going to be interesting to watch other competitors in the space learn from these solutions and find ways to improve their services based on these changes. I wouldn’t recommend rolling Antigravity as your main editor for a few weeks while bugs get ironed out but I think it’s great to experiment with and potentially run research tasks on existing projects.

Videos are great for telling the story at a glance focusing on the high-level summary — but they don’t always have the space to unpack the details that really outline the feel of building something with an AI.

That’s what this publication is for. Unpacking the hype and diving deep.

If you’re building with AI tools or just curious about the real-world bumps on the road, this deeper dive will give you practical insights and a more nuanced perspective.

Lessons Learned in the Coding Session

I’ve captured all of the 88 messages I sent in this coding session in one consistent webpage where they can all be browsed at your convenience. There’s also this companion site where I outline some of the high level takeaways.

In this post I’ve pulled out a few gems that highlight some tips and tricks that I think are pretty critical to having a good experience doing AI Assisted Coding.

For each note, you’ll notice the note number (message number), a quoted text that indicates the message I sent the AI, and a description that details what I was doing at each step. For example, the first major message I sent was this one:

Here we’re catching Claude Code up to some of the research I did to begin the feature. You’ll see the comment there and a quick note with the details. This is everything I needed to give the AI to get the feature started.

Let’s look at a few other notes that are more telling

Providing Context7 to Documentation

Context is super important to get right when working with AI, so much so that there’s an entire Context Engineering movement. As such, I often leverage Context7 to pull docs from technologies I’m coding with to leverage in my code.

Today’s AI models are trained at some point in the past and all contain a timestamped view of the world and pulling this context ensures we’re aligned with the latest version of any technology we’re using. This can have a huge impact on how well a feature is integrated in our code.

I’m using this to ensure we’re correctly calling the API and ensuring that we’re downloading the image from that API in the right format.

Note: I’m also not generating code right away. I’m using this research to put together a document that we can reference later when we build out the feature. I find this helpful to ensure we keep available key technical considerations as Compaction in our conversation (generated summaries of conversations) may cause some details to get lost.

Prompt to Prompt

As I’m building features that, themselves, leverage Large Language Models, I’m needing to create some prompts and tweak them as I go. I generally will tweak a bit by hand but I’ve found as I continue working with Claude Code that it’s often more explicit and creative at coming up with good prompts.

Anthropic themselves also have a really great prompt creation tool on their Claude Console page for developers to take their prompts and refine them into more optimized prompts for working with their models.

Generate Test Data

I’ve found AI uniquely helpful in getting some test data spun up quickly for testing out features. If you let it go a bit wild you’ll sometimes be rewarded with something cool or unique! Try it out sometime!

Regular Planning is Key

Using Claude Code, planning is a pretty critical step.

I will generally add planning in as a step whenever my direction shifts fundamentally. Here I’ve realized I have a new page that I need to develop that leverages the feature we’re working on but will require a much wider sense of the application to be able to pull off well. At these times I want Claude to be investigative and curious rather than ambitious and assuming. If I just let it go on a feature like this it could easily create a page I don’t want or add unrelated changes that don’t line up with the direction I’m moving towards.

Give Claude Code Your Tedious and Hungry

I love tasking Claude Code with fixing the code around the changes that have occurred. When I use AI Assisted Coding tools I also couple those tools with a suite of analysis tools to test the code that is generated for common errors and mistakes.

This is key to going fast and projects that I don’t have setup well in this space move slowly even when I use AI Assisted coding practices. It’s plain painful to get them moving as I need to be much more diligent as to what changed and why.

That said, you may need to poke it a few times to do what you want. AI will often take shortcuts in order to try to focus on what it sees as it’s main goals and priorities. This means occasionally you’ll need to redirect those goals a bit to align with your own.

Regularly Document Wins

When I finally pushed through the major defect that had come up, outlined in the video, I realized we needed to update our documents to capture this. It wasn’t captured anywhere else yet and it is critical to get this captured so we can refer to the fix in the future.

An Image is worth a lot of Words

Passing images to Claude Code is an amazing way to tell it exactly what you have in mind. I regularly pass images to it when I’m working to have it understand something a bit more complex or need to simply point at something for it to understand. Reference images can help a lot when coming up with a design or theming around a color.

I will regularly leverage a visual vibe coding tool like Magic Patterns to build out ideas for me to quickly reference via screenshots or code snippets. I’ve got a bit more about how I use that tool here:

The Overall Journey

Building with Claude Code is exhilarating because you can go from idea to implementation so fast. But as I’ve learned, it’s just as important to slow down sometimes — to observe, orient, and decide — before you act. AI can supercharge your coding, but it can’t replace the human insight that keeps your code cohesive and aligned with your goals.

Going back through these messages has been a great way to surface some of the ways that I work with Claude Code to prototype. As you go through them, I’d love to know if you found anything interesting about the way that I work with Claude Code that I didn’t mention.

Additionally, I’d love to hear how you’re working with AI-assisted coding tools. What bumps have you hit? What tricks have you found? Drop a comment or reach out — let’s keep unpacking the hype and learning together.

Now let’s get into it.

Our Take

AgentKit and Agent Builder feels great and looks like what the future of tools for building Agents around real products and services will look like. It’s like an extension on n8n’s existing capabilities (another agent builder tool) but AgentKit is streamlined around OpenAI’s offering. This could be serendipitous if you’re already leveraging their existing file storage solution or other core features.

The kit is streamlined for building quickly but I don’t really think it’s quite the powerhouse people think it is. We can see why by reviewing some of the other features in the announcement.

ChatKit is an application layer toolkit for delivering a chat interface to end users by directly leveraging ChatGPT’s methodology. It has a nice set of features that manages to do many of the things that the Vercel AI SDK was already doing well. I’m a fan of some of their direction which is clearly inspired by that library.

Similar to building with Swift for the Apple iOS, to leverage this kit a team will be aligning with a design system of visual components created by OpenAI. Until we get a chance to play with these components, it’s unclear how far these components can be pushed and where the limitations are. Additionally, we’ll need to wait and see how this library will evolve over time since this product space is certainly very new.

OpenAI is looking to own more of the experience layer by providing an ecosystem of UX and UI tooling. Applications leveraging their agent platform will need to keep pace with changes and adjust accordingly if they adopt this approach to building. That can be an uncomfortable place to be longterm and might be a worry for early adopters.

OpenAI mentioned that there would be a capability to publish Apps in ChatGPT in the future but no word yet on exactly when. The actual guidelines to publish an app are quite extensive however. They remind me of an Apple App Store-like approval process blocking publishing and becoming featured. Adherence to the style and intent of ChatGPT will be directly rewarded here.

AgentKit doesn’t directly land users into ChatGPT, which can be a bit misleading if you watched the presentation. It seems like AgentKit has everything setup to build something into ChatGPT itself but in actuality AgentKit is for creating agentic experiences on separate company-specific websites.

As OpenAI leans into adopting MCP, there seems to be some underlying messaging that companies don’t have a vendor lock-in around OpenAI. However, the MCP ecosystem is still missing many core services and is still maturing. I’d argue there is a lot of inherent vendor locking with AgentKit. That much is clear.

Evals is one of the most compelling reasons to be excited about AgentKit. But to leverage it well teams will need a very clear vision of what an agent does and what it looks like when it does something well. That continues to be a difficult spot for product builders to define.

Overall, I think AgentKit shows an interesting perspective on what agentic platforms should look like. Unless there’s a clear path towards Apps in ChatGPT I think the main adopters of these releases are going to be B2B application builders. While there’s room for a B2C path, losing brand seems like it lacks competitiveness and limits the upside potential.

Existing options for building agents continue to be available and, given a team with some frontend engineering capability, those solutions aren’t as complex as OpenAI makes it sound.

This simple gaming question sent me down two very different paths that perfectly illustrate how search has fundamentally changed. And if you’re running any kind of online business or content operation, this shift is about to upend everything you know about visibility, traffic, and revenue.

A Tale of Two Searches

Path 1: The Traditional Google Journey

When I typed “what do I do with Tangy Clam Meat wow classic” into Google, I entered a familiar but exhausting maze:

Step 1: Google shows me search results (after scrolling past AI summaries I don’t trust yet)

Step 2: I click on WowHead because it ranks first

Step 3: I’m bombarded with ads—top, bottom, sides, pop-ups

Step 4: I navigate their specific UI, hunting for information

Step 5: I discover I need to click on “reagent” (who knew that’s what cooking ingredients are called?)

Step 6: Finally find my answer buried in the middle of the page

Total time: Several minutes.
Mental energy: Depleted.
Ads encountered: Countless.

Path 2: The AI Conversation

Then I tried Dia‘s AI search. Same question, completely different experience:

Step 1: I type my question naturally

Step 2: AI searches multiple sources simultaneously

Step 3: I get a direct, synthesized answer

Step 4: Done

But here’s where it gets magical—and this is the part that changes everything.

Context-Aware Follow-Ups

Now, I had more items to check in my inventory. In the traditional model, I’d have to either:

• Start a completely new search for each item

• Try to navigate the same cluttered website to find more information

• Open multiple tabs and repeat the entire process

But with AI search watch what happens:

Me: “what about tender crocolisk meat”
AI: Immediately understands I’m still asking about WoW Classic recipes and provides the answer

Me: “raptor egg”
AI: Knows the context (a directory of results), gives me recipe details

Me: “small venom sac”
AI: Tells me it’s not for cooking but for alchemy instead

I didn’t have to specify the game. Didn’t have to say “recipe” or “wow classic” again. The AI maintained our conversation context. I literally just typed item names—sometimes misspelled—and got exactly what I needed.

This isn’t just convenience. This is a fundamental reimagining of how we interact with information.

Why This Matters

The Click-Through Economy is Collapsing

Many a website’s business model assumes one thing: you’ll click through to their site. But when AI provides answers directly, that assumption crumbles. Here’s what’s at stake:

Revenue Streams in Critical Danger:

• Display advertising (no clicks = no ad views)

• Affiliate links (AI won’t pass these through)

• Sponsored content (less attractive with declining user counts)

But this isn’t just a story of decline. New revenue opportunities are emerging for those willing to adapt—from data licensing to AI-specific services. Watch my detailed breakdown of the revenue transformation matrix and emerging opportunities →

The Paradox of More Content, Fewer Visitors

Here’s the mind-bending reality of AI Engine Optimization (AEO): You need to create more content to get fewer visitors.

Why? Because AI systems need comprehensive information to reference. You’re no longer optimizing for one perfect landing page. You’re building an entire knowledge ecosystem that AI can traverse.

Example: Instead of one “Tangy Clam Meat” page, gaming wikis now need:

• “Where to farm Tangy Clam Meat in Westfall for Alliance players”

• “Is Tangy Clam Meat worth keeping for leveling cooking 1-300?”

• “Tangy Clam Meat vs Clam Meat - which recipes need which?”

• “Best grinding spots for Tangy Clam Meat for level 15-20 characters”

• “Can Horde players get Tangy Clam Meat or is it Alliance only?”

• “Auction House pricing guide for Tangy Clam Meat by server type”

Each page might only get a handful of direct visits, but they all contribute to the wiki’s visibility when someone asks an AI “what should I do with this random meat in my WoW inventory?”

Admittedly this is a contrived example and I’m not sure how beneficial these questions would be for World of Warcraft directly but it’s illustrative of the kinds of content that may answer AI questions.

The Metrics That Actually Matter Now

The challenge with measuring AI visibility is real. As HubSpot discovered, AI results vary based on conversation context, user history, and countless variables you can’t control. The same query produces different results depending on what questions came before it, whether memory is enabled, which AI you’re using. You can’t A/B test AI responses like Google rankings.

Here’s what we do know and can measure:

1. Traditional SEO Remains Your Foundation AI systems pull from search-indexed content. Without SEO visibility, you likely have no AI visibility:

• Organic rankings (your baseline for being discoverable)

• Indexed pages (comprehensive coverage = more AI reference material)

• Domain authority (trusted sites get cited more often)

2. The Volume-to-Visit Paradox Track the new reality HubSpot describes—more content, fewer visitors:

• Total pages published vs. traffic per page

• Coverage of long-tail questions in your space

• Visitor qualification metrics (conversion rate, time to purchase)

3. Visitor Quality Indicators The few humans who arrive have already done their research in AI. Monitor:

• Conversion rates (should increase)

• Pages per session (should decrease—they know what they want)

• Support ticket sophistication (fewer “what is this?” questions)

4. Competitive AI Visibility Manual checks remain your best option. Weekly sample queries about your category:

• Do you appear in AI responses?

• How prominently versus competitors?

• Which of your pages get cited as sources?

5. Content Architecture for Agents You’re now publishing for machines first. Measure:

• Question-answer pairs created per topic

• Structural clarity of your content (can an AI easily parse it?)

• Topic interconnection (how well you link related concepts)

The uncomfortable truth: we’re measuring proxy metrics because the real metric—influence within AI conversations—is largely invisible. As HubSpot notes, this is marketing for agents versus humans. The agents don’t click, don’t convert, and don’t fill out forms. But they determine whether humans ever hear about you at all.

We’re in uncharted territory where success might mean accepting lower traffic while betting that the traffic you do get is exponentially more valuable.

The Two-Audience Strategy

You’re now designing for two completely different consumers:

AI Agents

• Need structured, comprehensive data

• Consume hundreds of pages to form opinions

• Prefer clear, factual information

• Value completeness over creativity

Highly Qualified Humans

• Already know about you from AI conversations

• Ready to buy, not research

• Need immediate value demonstration

• Want streamlined conversion paths

This is a fundamental shift from offering content (mostly for free) and profiting off of advertising. Now it’s likely if you’re making content it needs to be paid. (oh! Maybe this is a good time to check if you’re subscribed 🙃)

Practical Survival Strategies

1. Build Your Answer Archive
Transform your existing content into Q&A format. Every blog post should answer specific questions people might ask AI about your space.

2. Create Conversation Chains
Design content that naturally leads to follow-up questions. Think about the customer journey as a conversation, not a funnel.

3. Establish Direct Relationships
Email lists, apps, communities—anything that bypasses search becomes exponentially more valuable. You need to own your audience relationship.

4. Structure for Machines
Well-organized, schematized data becomes a competitive advantage. Structured data that AI can easily parse and cite will win over beautiful but chaotic content.

5. Monitor AI Mentions
Set up systems to track when and how AI systems mention your brand. This is your new SEO ranking.

What This Means for Content Creators

The comfortable era of “write content → rank in Google → get traffic → monetize” is over. The new reality:

• Your content might be read entirely by machines

• Success happens inside AI conversations, not on your website

• The few humans who visit are ready to buy, not browse

• Brand building occurs in AI memory, not human memory

This isn’t just another algorithm update. It’s a fundamental rewiring of how information flows online.

The Bottom Line

The shift from search to conversation, from clicks to context, from keywords to knowledge graphs—it’s all happening now. That simple gaming question about Tangy Clam Meat revealed a seismic shift in how we find and consume information.

Sites that adapt will thrive by becoming invaluable data sources for AI while creating exceptional conversion experiences for the few humans who visit. Sites that don’t adapt will simply become invisible.

The question isn’t whether this change is coming—it’s already here. The question is whether you’ll evolve your strategy in time.

What’s your experience with AI search? Are you seeing changes in your traffic patterns? Drop a comment below with other Substack members or join our Discord to discuss.

For more deep dives into AI’s impact on digital business, subscribe to Stable Discussion. And if you want to experiment with AI-powered research yourself, check out Benny Chat.

While the 100 page PDF is free to read, I also enjoyed listening along to the NotebookLM podcast narration on the same topic which you’ll find at the end of this post. LLMs can help us to break into new concepts clearly and it feels a little bit like the process described in How to Read a Book. When you first pick up a new book they suggest doing a scan of the table of contents, index, and summary of the book to get your bearings. We can now take this one step further!

Let me walk you through how I built a prototype using this methodology—and show you just how powerful AI made the process.

Step 1 - Defining my Product

One idea that’s stayed with me is making it easier for engineering leaders to find the right candidates. In some organizations these leaders don’t get much help and need to figure out how to recruit great people on their own. Suddenly the first 30-60 minutes of their day is scrolling through LinkedIn messages, job boards, or massive piles of resumes. It’s a far cry from the cool tech stuff they signed up for but it’s also an essential part of building their team.

In my prior role as Head of Engineering, I developed a proof of concept for this product, but I realized I hadn’t truly validated the idea with my target audience. But, I had a working example and a lot of good source material on my product idea.

I had started with a specific candidate in mind (me) and had noted key factors to consider. Throughout the prototyping process, I used AI-assisted coding and documented both how the application works and why it might appeal in a crowded market of hiring agencies and recruiters. These notes were essential for AI coding and could now also be leveraged to help me define the product again here.

I relied on Granola to turn conversations about the idea into actionable notes. Talking through ideas helped me refine my approach and capture valuable insights.

After gathering these notes, my next step was to create a clear product description using my task management assistant, Benny Chat.

I asked it to pull up relevant notes and it quickly brought up some likely candidates from its search over all of my notes. Next I needed a summary to ensure these notes were the ones I needed.

After some back and forth, I found the note I was looking for but also got a bit of helpful related context along the way from other research I’ve done.

Benny offered to write me a pitch for this business and that’s exactly what I was looking to do. I adjusted it slightly to focus on the niche I’m aiming at and let it get me the following definition:

AI Agency for Engineering Leaders: Business Definition A talent-matching agency for engineering leaders, powered by AI and human expertise, that delivers highly targeted shortlists of technical candidates explicitly tailored to the unique skill criteria and team culture requirements set by the hiring manager.

• Engineering leaders describe their specific hiring criteria (skills, experience, values, context).

• Each leader is paired with an AI agent—and backed by human experts—that actively sources, filters, and ranks a weekly curated slate of “best-fit” candidates (no noisy spam, just right-fits).

• Recommendations are grounded in data but filtered and contextualized to what really matters in the role.

• The service goes beyond “keyword matching”—it helps managers clarify their actual needs, guides tradeoff decisions, and offers transparent reasoning for every candidate picked or skipped.

We have a Product Definition and now we’re ready for the next step!

Step 2 - Defining our Prototypes

Learn More Faster describes how customers will give you better feedback when they have three different ideas to compare and contrast together. A single example doesn’t open up enough conversation, two tends to have users just pick a favorite, so three is the sweet spot where users start to step back and think about pros and cons of each approach. In the real world customers are often comparing multiple products to evaluate which one they should use and this selection of prototypes mimics the natural landscape of their decision making.

Now, three prototypes can be a lot of work especially if you have one idea that you absolutely love and it’s hard to break out of that option. This is a great opportunity to leverage the thinking of an LLM to help broaden your available options. Specifically a “thinking” AI model that can reason.

In Benny Chat, we offer a Reasoning model that can “think” and leverage longer trains of thought. This allows it to come up with a better answer using the available context.

Currently our Reasoning capability has been performing really well using the new fully released gemini-2.5-pro model from Google but I’m open to changing it when a better model shows up.

Fortunately, this is a widely read book and I’m able to reference the methodology directly as part of my prompt to help the AI coming up with prototypes. Benny gave me some amazing definitions like this one:

I continued brainstorming with our Reasoning model, I came up with a set of three great prototype ideas that could be clearly communicated. When satisfied, my next prompt to Benny Chat’s Reasoning model is:

“Think carefully about the first option and describe for me a landing page that highlights this offering. I'd like you to highlight how the page looks, what is in each section, and define marketing copy that makes sense for this kind of an offering. Think about what we know about Learn More Faster to define a page that is easy to understand and gets the point across clearly to the viewer”

This is going to give us a clear Prototype Definition with a few key details:

• A overall goal

• A overall design look, aesthetic, and visual feel

• Sections by section outline with details of what should be written

• Actions users will have to engage

Taking the result of this query, we’re ready to get an AI builder involved to get a real prototype generated!

Step 3 - Building the Prototypes

According to Learn More Faster, you don’t need to fully build prototypes—you can simply tweak a competitor’s site, mock up a page in Photoshop, or use a slideshow to simulate the experience. But today, rapid prototyping tools make it easier than ever to quickly create and refine your ideas.

For proficient AI generation, context is everything. In the AI product space, everyone is all-hands-on-deck building Context Engineering into their smart experiences. Fortunately for us, we’ve already done a lot in the previous two steps to provide context that will guide the prompt we’ll use to build out our prototypes!

I start by opening Magic Patterns, dropping in our prototype definition as the prompt, and specifying Shadcn as the design library since it’s my preferred choice for building.

Once the prompt generates the webpage, the result is much more robust than our simple outline. The page is organized into clear sections that directly reflect our prototype structure, making it easy to see how each part comes together.

Next, I review the prototype for any obvious inconsistencies or errors. While AI tools are impressive, they can sometimes miss details or generate inaccuracies that need to be corrected. At this stage, I focus on the content rather than design—making sure the statements are accurate and aligned with the overall concept.

Tip: Be specific when making edits—explain what you’re changing and why. The more detail you provide at this stage, the better the model can adapt in future iterations. Thoughtful feedback now will improve results down the line.

Now it’s time to lean into Magic Patterns fully and see why we’re using this specific builder. Using the command /Inspiration we’ll spin up 4 different versions of the page we’ve been building out as our prototype.

Using 4 credits to generate multiple versions is well worth it compared to the time you’d spend forking a solution generating options manually. Magic Patterns makes it easy to explore different approaches and visually communicate ideas that might otherwise stay stuck in your notes.

At this point I keep iterating until I’m satisfied that the prototype meets my expectations. The entire process (not including creating the source notes) can take as little as 15 minutes! And the results speak for themselves!

Transforming Startup Creation

AI doesn’t directly build a startup for you. The skills you need to build a successful startup go far beyond just putting together a good looking web page. It’s about communicating an idea clearly to a specific niche customer and growing out from that point.

AI helps you to find that customer and connect with them faster. Communicate with them better by being able to present more clearly and more directly than you might otherwise be able to. Once you’re in touch with that target customer everything changes, but prototyping is all about making that connection happen to get real insights.

AI tools like Granola can help package that conversation up for you and remind you of details that you would otherwise miss. These tools don’t run the interview for you and they shouldn’t. They won’t tell you if someone is going to actually buy what you’re selling.

I’m excited by the opportunity to connect more effectively with potential customers—leaving a strong impression that I care about their challenges and am committed to solving them. Any tool that helps me do this faster is a winner in my book.

If you found this post helpful and want to dive deeper, consider a paid subscription. You’ll get full access to the Stable Discussion Discord—where you can connect with other AI enthusiasts—and to the ideation tool I used today, Benny Chat. With prices going up soon, now is the perfect time to join.

Read more

I’ve felt it as recent advancements to AI models made it easier than ever to rely on AI Agents to build on our behalf. This shift has made this means of building a possibility. Where before simple coded solutions would be often inaccurate, now we’re getting beautiful complex interfaces.

However, that reality is largely a solo endeavor and the tools and practices used are individualized. Due to this being an emerging field, those who code with AI naturally use their own chosen tools, models, techniques, and workflows. This is a reflection of a new ability to work with users in a way not previously possible. AI-powered software can now adapt to you and work with how you see the world.

In a world where everyone is running their AI agents their own way and seeing results they like, can we find a way to build teams that use these tools? Should we try?

Faith in Workflows

We have relationships with the models that run the software we use in our daily workflow. These AIs talk to us where we are at, so it’s not just a tool anymore. It’s now a colleague or a friend that helps us when we’re frustrated and trying to get something to work. We’ve faced challenges and these AIs have established a bond of sorts through their help.

I have a better relationship with GPT-4 than I did with o3 or GPT-4o. I find 4 less conversational but more accurate. That focus on concise accuracy was a benefit to me as I leveraged AI in my products. I want it to focus clearly on a single goal. These values shaped what I cared about and how I evaluated which model I would pick.

Those values and our past experience build personal relationships, forming our perspective when we try to think objectively about how AI tools work. A familiarity bias toward workflows we understand have worked well becomes evident.

You’re willing to deal with bad results from that tool, being familiar with how it works. You know from past experience that this model is capable of giving you something great. Familiarity feels like reliability despite them being different things.

When first trying out a new AI tool, each failure is critical. We don’t know if this tool will be capable of coming up with good results and how long we’re willing to wait to find out is determined by our expectations with other tools. Our brain tells us, “Wouldn’t it just be better to go back to a tool you know well that already seems to understand what you want?”

When we start to bring teams of smart AI builders together, it’s notable that not everyone wants to use the same tools. They don’t have the same relationships and won’t believe in experiences they haven’t had. Without a significant shift in capability, it’s hard to dislodge their faith and practices.

Randomness at Play

Complicating this is something less personal and more mechanical: randomness. If you ask for the same thing twice, you won’t necessarily get the same output. One run nails your brief; the next runs down a side path and gets attached to it. It’s not malice or incompetence; it’s just how the system functions.

When OpenAI announced their latest GPT-5 model, they highlighted a number of impressive web apps that were built on the spot with their latest model. Sometimes, demos included several different responses to the same prompt and the researcher, Yan, noted:

One thing to note, GPT-5, just like many of our other models, has a lot of diversity in its answers. What I like doing, especially when you do this type of vibe coding, is to take this message and ask it multiple times through GPT-5; then you can decide which ones you prefer.

Model providers, like OpenAI, work hard to try to build the best model they can. Running multiple times gives you a chance to see them in their best light. However, it also highlights that sometimes you might not be happy with what you get.

So now when teams are working together to determine which tools they’ll want to use, they may have luck working against them. A lead’s early evaluations may show off poor results on a model everyone else on the team loves to use daily. Is it how they used it for their workflow or is it just an unlucky generation? That’s a hard question to answer.

Recently, I worked through building a new UI for a project and decided to test out Magic Patterns, another AI coding platform that’s focused around web design patterns. As I worked to build out a new webpage, I noticed they had a Brainstorm mode. This mode launches four different generations of your prompt to be output as four different examples. As a result, you get a bit of variety as well as a better chance at getting a really great result out of one of the attempts.

Image generation tools have been doing this for a while. We know that those tools sometimes generate bad stuff, but because we always generate 4 at a time (or in ChatGPT’s case, an AI picks the best of 4 behind the scenes), we always get at least one decent image. Otherwise, we know our prompt might need to be changed to something that produces a better output in the model.

This works great with images we can see right away, but it doesn’t work as well with long segments of text. It’s hard to read four different code bases and see which one is the best. However, we can see the output as a website or application and perhaps that’s enough to start to understand what these tools we’re coding with are actually good at.

Emergent Tech Means No Standards

As teams look to adopt major new technology, the term best practices gets thrown around frequently. Leaders want assurance that whatever effort is put into the practice is going to give them a positive outcome. Otherwise, a technology is just seen as a toy that really doesn’t serve them much purpose.

AI coding has been seen as an interesting toy, and it initially deserved that description. Attempts to get AI to meaningfully contribute to coding environments have been plagued by unremarkable code, fabricated API integrations, and misaligned feature development. These early impressions have left their mark and even now many developers hold the opinion that AI coding is still a distraction and can’t be capable of doing anything real.

Looking at the success of Claude Code’s ability to produce meaningful output and the adoption of other development tools, that belief is starting to weaken. It’s hard to ignore that something significant is happening. But how are these same developers going to communicate to their leaders what they need to do about these developments and where should they invest?

Large companies offer answers to these questions. For example, Microsoft is enthusiastic to sell you on a suite of AI tools for Copilot that bring AI into your business. These large companies are keen to become the new standard choice for AI and establish common ways of working for your team. As teams look for this, there’s always someone there eager to sell them a standard.

However, AI is currently an emergent technology. As I’ve mentioned previously, AI solutions that were built just months ago are becoming obsolete as new capabilities become commonplace and models become more available. Because outputs vary and standards lag, emergent teams face a moving target.

Teams building with AI need to assume that models will get better, capabilities will change, and the ways they’re currently engineering with AI are temporary. This is a challenging position for developers and leaders because it’s outside the technical norm to communicate how the team is investing in AI.

Building in the In-Between

Now, teams that look to work together have many interesting tools available to them. It takes a bit of curiosity and a bit of creativity to leverage the tools into workflows that are beneficial—but perhaps more importantly, it takes something we’re not always comfortable with: uncertainty.

The truth is, we’re in a liminal space with AI-powered development. The tools that seem indispensable today might be obsolete in three months. The workflows we painstakingly establish could become irrelevant with the next model release. And the standards we try to impose might actually limit us from discovering what’s truly possible.

This doesn’t mean teams should abandon all structure—disorder isn’t the answer either. Instead, teams need to cultivate what might feel like contradictory qualities: being structured enough to collaborate effectively while remaining fluid enough to adapt when everything shifts beneath their feet. It means holding our tools lightly, our processes flexibly, and our assumptions tentatively.

The most successful teams will be those that stay curious about what’s emerging, rather than defensive about what’s familiar. They’ll create space for experimentation alongside execution. They’ll document what works today while staying alert to what might work better tomorrow. Most importantly, they’ll recognize that the discomfort of not having established best practices is actually a feature, not a bug—it keeps us awake to possibilities we haven’t imagined yet.

In this world where AI agents adapt to individual working styles and randomness plays a role in every output, perhaps the real skill isn’t in standardizing our approaches but in learning to orchestrate diversity. Teams that can harness different tools, different models, and different workflows—finding harmony in that variation rather than enforcing uniformity—might discover capabilities that no single approach could achieve.

The shadow we’re building in isn’t darkness; it’s the space before dawn, where shapes are still forming and definitions remain fluid. Teams that can navigate by feel, stay aware of the shifting landscape, and remain genuinely curious about what they don’t yet know—these are the teams that will define what building with AI actually means.

In the end, the question isn’t whether we should build teams that use these tools. It’s whether we can build teams that are as adaptive, curious, and aware as the AI we’re learning to work alongside.

Turns out, wedding websites have a hidden depth and the stakes are surprisingly high. Now that I'm on the other side, I want to share some reflections on wedding websites, the hidden complexities, and why sometimes buying beats building—especially for high-pressure, one-shot events.

The Unexpected Pressure of Wedding Tech

I've spent years in consulting and have dealt with demanding clients, but I wasn't prepared for how high-stakes a wedding website would feel. Every wedding touchpoint carries emotional weight, and when there are bugs or issues, you'll definitely hear about them—from family, friends, and especially your future spouse.

What makes this particularly challenging is that unlike most software projects where you can iterate and improve, wedding websites are essentially one-shot products. They need to work correctly the first time, with limited opportunity for testing with real users or fixing issues as they arise.

The Anatomy of a Wedding Website

On the surface, wedding websites seem simple. And in many ways, they are! But dig a little deeper, and you'll find several critical features that must work flawlessly:

RSVP Functionality

This is the primary reason most couples create a wedding website. It's not just collecting yes/no responses—you're typically gathering:

• Food selection choices

• Email addresses for automated reminders

• Dietary restrictions and allergies

• Plus-one information

If any part of this system fails—the form doesn't save responses, emails go to spam folders, or data gets lost—you've compromised the main purpose of your site.

Email Management

This is more complex than it appears. You need emails that:

• Are properly validated and omit common typos.

• Come from a "warm" email account that won't trigger spam filters

• Arrive at the right time with the right information (reminders/save the date)

I've experienced firsthand how email validation can go wrong. I have an @hint.services email that many sites reject because they don't recognize .services domains—imagine discovering any of these issues after sending invitations!

Privacy Controls

Many couples want to keep certain wedding details private—like the venue location—until they've confirmed someone is actually invited. This requires:

• Some form of authentication

• Clear user flows for accessing private information

• Proper security to prevent unauthorized access to details

Every additional privacy feature adds complexity and potential points of failure. When a guest returns to the site after RSVPing, will they know how to access the private information? Will the system remember them correctly?

I’m even leaving out a few key features like a registry, but since I didn’t use most of those features I’m leaving them out for now. Just note this can become a more extensive set of features pretty easily!

The AI Building Landscape Has Evolved

When I was initially thinking of building my own wedding site, I was primarily using tools like Cursor. In the months since, we've seen a surge of AI-powered development tools like Bolt.new, Lovable.dev, and Claude Code that make custom site building much more efficient and streamlined.

I've found myself wondering: if I were starting today, could I have easily built a custom wedding site with these new tools? And more importantly, should I have?

The answer, I believe, is still no—and this is why.

The Testing Challenge Remains

While AI coding tools have dramatically reduced the implementation challenge, they haven't solved the testing challenge. You can have all the right pieces built correctly in isolation, but if they don't fit together properly, the entire system fails.

It's like trying to connect Legos with a completely different building system. Lego pieces work together because they have a fixed, well-understood connector. Most software systems don't have such clear connectors—they're adaptable but require careful integration.

AI still struggles with these connections. It can generate impressive components, but ensuring they work together reliably requires human oversight and testing—exactly what you don't have time for when planning a wedding!

Enterprise vs. Startup Approaches

This wedding website experience has interesting parallels to my professional work. I'm currently advising at an enterprise-sized company, and I've noticed how differently I use AI there compared to my previous role at a startup.

At the enterprise level, details matter immensely because solutions scale to many users. The expectations for AI become much more granular. In contrast, startups can build quickly, pivot as needed, and accept some imperfections to get to market faster.

Wedding websites fall firmly in the "details matter" category—you're building something that must work correctly the first time, for a specific group of people, on a non-negotiable timeline.

Buy vs. Build: The One-Shot Factor

For products or services where users will return multiple times, you can iterate and improve. But for one-shot experiences like weddings, you need reliability from day one.

That's why, despite my technical background and the impressive capabilities of today's AI tools, I'm ultimately happy I went with a proven template-based solution. The peace of mind was worth far more than whatever customization I might have achieved.

When the stakes are high and you only get one chance, sometimes the smartest technical decision is to rely on systems that others have already thoroughly tested.

I'd love to hear from others who've faced similar "build vs. buy" decisions for high-stakes personal projects. Did you create your own wedding website? How did it go? Let me know in the comments!

Admittedly… I did build an AI Wedding Info Site.

I did end up creating a small info site for my wedding with AI on Loveable.dev. If you’re a paid subscriber, it’s available to you below!

The site has a few nice features. There’s a tiled background I created in Midjourney that sits behind an animated text intro. Then there’s a visual timeline of the events during the wedding which is helpful for quick reference. And lastly, there was a link to a spot for guests to upload photos of the evening.

Read more

I was working as a Head of Engineering without a dedicated Product person. I needed to quickly turn strategy documents into actionable tickets, so I plugged in a Linear MCP for project management and Todoist for my personal tasks. My plan was simple: dropping in documents and thoughts, then generating properly linked tickets assigned to the right people.

But then something interesting happened. I gave the AI a large, vague task like "implement user authentication." Instead of creating a single ticket, it:

• Broke the task into subtasks (phased out tasks that can be completed and tested independently)

• Set up dependencies between them

• Added test criteria to each subtask

• Included security considerations

I never asked it to do any of this. The AI looked at the context (engineering project in Linear), understood the implications, and structured the work the way an experienced PM with a background in engineering would.

This wasn't a workflow I had configured. It was emergent behavior - the AI combining its understanding of software development with the capabilities of the Linear API to create something more useful than what I'd asked for.

Why This Matters More Than You Think

Traditional automation tools like Zapier would require you to explicitly program each of these steps. If this, then that. Deterministic and predictable.

MCPs enable something fundamentally different. When an AI can see multiple tools at once and understand their capabilities, it starts finding creative solutions to problems. It's not following a script - it's actively problem-solving.

Another example: I connected an AI to both my email and my calendar. When I asked it to schedule a meeting based on an email thread, it didn't just find an empty slot. It:

• Analyzed the email thread to understand the meeting's purpose

• Suggested a duration based on the topics discussed

• Drafted an agenda pulling key points from the emails

• Even suggested which participants were optional based on the conversation flow

Again, I hadn't programmed any of this logic. The emergent behavior came from the AI having simultaneous access to multiple tools and the context to use them intelligently.

The Speed of Discovery

What makes MCPs particularly valuable right now is the speed at which you can experiment with these emergent workflows. I can connect a new tool in minutes and immediately see what unexpected behaviors emerge.

This rapid experimentation is crucial because we're still discovering what's possible. Every new combination of tools seems to unlock new emergent behaviors:

• Connect a code repository MCP with a documentation tool, and the AI starts auto-generating docs that actually match your codebase

• Add a data analysis tool to a CRM integration, and suddenly the AI is finding customer patterns you never thought to look for

• Combine project management with communication tools, and the AI begins surfacing blockers before they become problems

The key is that these aren't features anyone built. They're capabilities that emerge from giving AI the right tools and context.

The Current Limitations

Of course, MCPs aren't perfect. Configuration can be painful - I often end up writing custom MCPs because existing ones don't quite fit my needs. The ecosystem is fragmented, with everyone building their own MCP hoping to get noticed.

There's also a real question about longevity. As AI code assistants get better at writing API integrations on the fly, will we even need MCPs? Maybe they're just a stepping stone to something better.

But right now, they're the fastest way to explore what happens when AI can orchestrate multiple tools. And what I'm seeing suggests we've only scratched the surface of what's possible.

What This Means for the Future of Work

The emergent behaviors I'm seeing with MCPs hint at a fundamental shift in how we'll work with AI. Instead of AI as a better search engine or writing assistant, we're moving toward AI as an intelligent orchestrator of our digital tools.

Imagine a future where you describe a goal to your AI assistant, and it figures out which tools to use and how to combine them to achieve it. Not because someone programmed that specific workflow, but because the AI can reason about the capabilities available to it.

That's the promise of emergent AI workflows, and MCPs are giving us our first real taste of what that might look like.

Start Experimenting Now

If you're curious about this, I'd encourage you to start experimenting with MCPs yourself. Pick two or three tools you use daily and connect them to an AI assistant. Then watch for the unexpected.

What surprised me most wasn't the time saved on routine tasks - it was discovering entirely new ways of working I hadn't imagined. When AI can see across your tools and find its own solutions, the results can be genuinely surprising.

That's the real story with MCPs: they're not just about connecting AI to tools. They're about discovering what AI can do when it has the freedom to be creative with those connections.

Benny Chat: MCPs for Tasks

We recently posted about our work building out Benny Chat using MCPs which has enabled it to be a uniquely capable task helper in a way that other task tracking tools aren’t! Read on for more information on how we brought Benny Chat to reality and how to get your hands on it.

To give you a sense of this urgency, a friend sent me this YouTube video of Google’s new ability to generate videos with audio:

Last week, my entire feed of news felt this cool and impressive.

I needed a place to start. An ability to see the landscape and understand each major announcement well enough to discover where I wanted to focus. I needed a map.

There aren’t many good sources for ready-made and current domain-specific news maps. Social feeds like Twitter/X aggregate influencer opinions but lack direction. Those feel like the last place to look but are often the first thing people see.

Newsletters consolidate announcements, but they often group links without a broader view or perspective. Publications excel at pointed statements and discussions, but struggle to show the larger picture.

This is a curation problem. It’s difficult to get signal from noise when AI is moving so quickly. I think AI can help.

Creating Info Maps

As I lay in bed thinking about what could be done to get me up to speed, I realized this is actually a space where a bit of AI-assisted research could go a long way. Tools like Perplexity Research and OpenAI’s o3 model have gained notoriety for being excellent at evaluating information and coming up with novel approaches to problems.

I scanned over some of the news I’d been sent and started building out a prompt to give to Perplexity Research. I dropped in the following prompt, including some of the keywords I’ve been seeing as I recovered:

What are the latest AI updates from the last week. I know about Claude 4, openai MCPs, google announcing new things, and figma config Ai things. But please review other major news and categorize the updates for me to be able to see at a high level and review

As a result, I received a comprehensive map of the week, including an executive summary, details of recent platform changes, enterprise adoption, regulatory changes, tech infrastructure changes, and emerging specialized tools. The news expanded from my keywords to cover many more announcements, including the Quen3 release and corrected me that the implementation of Veo3 I was impressed by was actually made in a product called Flow.

Most impressively, the details are grounded in the sources directly from these companies. While there are some Reddit posts referenced in the sources, a lot of primary source information is leveraged to build out this summary. Now it’s also easy to get more high quality details.

Additionally, the prompt I gave curates the details for me. I asked for something high level that can be easily reviewed. If I wanted it to be brief or formatted in a specific way, it would be easy enough to do that too. When’s the last time you got a newsletter that was personalized to you? (← free startup idea!)

Exploring the Map

Now the journey doesn’t stop there. Maps aren’t perfect replications of reality; if they were, they wouldn’t be very helpful as they’d simply be a mirror of reality. As such, the simplifications that are made offer entrances to unexplored depths. A map enables us to think like an explorer and venture on.

The summary was great, but I can tell that the Figma Config conference was overshadowed in the news. I wanted to get a few more details on that, so I asked the follow-up question:

Give me more on the Figma Config conference that happened. It may have been during the week before

Perplexity can limit search results to only include those within a specific time period. Since I wasn’t sure exactly when the conference was, I gave it an out to expand the search.

As a result, I got a great summary of the announcements at the conference. This was actually just a quick search and not a deep research.

However, upon reviewing the details here, I had a deep research question I was dying to ask:

How does what Figma announced stack up against Canva or is there another direction that there are looking to go?

Now, I’m using the context of this conversation about GenAI advancements to give this research question some context. We can see that in the Tasks that the research agent determined from my question:

This research agent has the context of all of the results in this conversation. That’s very helpful as that information can help Perplexity guide their questions toward more specifically the underlying question I have which is really about Figma and Canva both pursuing a similar line of AI product tooling.

Benefits of Mapping

As a result of this map, I was able to achieve Inbox Zero and get back to a sane place. I had a basis for understanding each of the updates, which gave me more selective focus. I didn’t need to look at each announcement with questions looking to see if there was an important announcement that related to my work.

The map gave me enough context to know the landscape and gateways to learning more. I’d encourage you to try this out yourself the next time you feel like a wave of information is hitting you. Maybe it’ll feel a bit less daunting once you’ve created a map to go off of.

I was a slow adopter to Perplexity, but now I’m really hitting my groove with it. In many ways, I prefer it to ChatGPT results because it has a different focus on information. That said, I still leverage o3 and believe it could produce a similar result to what I’ve shown here.

Announcements

A few weeks ago, we released Benny Chat, and it’s been steadily getting better by the week. I recently pushed some new updates around daily and weekly notes. If you’d like to check it out, you can either become a paid subscriber on our Substack here or become a member of the Discord directly.

A new video on Benny Chat will be coming soon! But here’s the announcement in case you missed it:

Paid Subscriber Announcements

Read more

Let me introduce you to Benny Chat – my custom-built replacement for the Claude-Obsidian workflow. While I'll share how to access Benny at the end of this post, I first want to walk you through the journey that led me here. It's been quite the rabbit hole!

If you’d rather watch than read, there’s a companion video on our YouTube channel that walks through the same material step by step—feel free to pause here and check it out.

The Knowledge Management Quest

My journey began with Roam Research, a tool that excels at connecting notes by making each note a referenceable object (similar to website URLs). This creates webs of connections between different notes in a shareable format. While I loved the connectivity, I struggled with its node-based structure – each block of text is a specific node. This just didn't match how I think and write.

This frustration led me to build my own application (not my first rodeo). I created "D&D Notes" where I could add entries like "The Dragon's Castle" and tag them as places, people, organizations, etc. Notes could reference other notes, creating that connectability I wanted.

But then I discovered Obsidian, which is essentially Roam Research for documents, but with much more flexibility. You can shape documents however you want without the strict structure. I switched immediately, pulled all my Roam Research content over, and moved forward.

What really captivated me about Obsidian was its graph view – the ability to visualize connections between notes. I found myself regularly checking this graph, watching how my note structure evolved over time. Plus, the plugin ecosystem allowed me to extend and customize Obsidian to fit my specific needs.

Adding AI to the Equation

As I dove deeper into AI, I explored tools like Obsidian Smart Connections, which adds AI capabilities to connections between notes. The semantic similarity search was particularly interesting – instead of searching for exact text matches, I could find notes with similar concepts. Looking for "Hero's Fortress" might lead me to "Mario's Castle" through semantic connections.

Pretty neat! But there was a significant problem – keeping Smart Connections up to date was a hassle. The embedding models changed frequently, requiring me to re-embed everything. Every time I opened the app, I'd wait a long time for embeddings to update before I could use the fuzzy search feature I actually wanted.

I also didn't love the chat interface. Obsidian Copilot offered a prettier alternative, but after my experience with Smart Connections, I was hesitant. I realized I didn't actually want to chat with my notes – I wanted to reference them in a robust system that could take action.

At this point, I’d pared everything back to core Obsidian and a couple of must-have plugins. The Obsidian Text Generator covered quick drafting and rewrites, which felt “good enough” for daily writing—at least until I saw how AI could tackle tasks.

The Task Management Revelation

Everything changed when I saw a post from Austin, the founder of Saner. He demonstrated breaking down a task into pieces, prioritizing them, and assigning due dates – all through a chat interface. I was immediately intrigued.

While Saner had good connections, I got stuck in the onboarding process. It pushed too much at once and didn't quite understand my context when I tried to use the chat as I'd seen in Austin's demo.

But the idea of AI managing tasks stuck with me. I explored Tana, which bills itself as an "AI native workspace" using "super tags" to organize notes. While interesting, I found its AI capabilities frustratingly limited:

Me: What are my current goals?

Tana: I'm sorry, but I don't have access to your personal information or current goals.

What gives? For an AI task workspace, this was a direct violation of what I expected. Even when I pointed it to specific tasks in my workspace, it couldn't access them. The gap between the AI capabilities and the actual tool was maddening.

The MCP Breakthrough

Then I discovered MCPs (Model Context Protocol) and had a revelation. I could use Claude Desktop with Todoist through MCPs to create what I wanted:

Me: Hey, good morning, what tasks are on my to-do list?

Claude Desktop: Good morning! Here are your tasks for today: - Draft the product update email (Due: today) - Review pull request #42 in GitHub (Due: today) - Schedule meeting with design team (Due: tomorrow) - Follow up on client feedback (Due: tomorrow) Let me know if you want to mark any as complete, add a new task, or get more details about any item!

And it would pull down my tasks! I could ask for overdue tasks, create new ones – everything I wanted from Tana but couldn't get. This was ideal.

I had this big realization: MCPs completely replaced a major company’s task management software. There was no turning back.

But there was one significant problem – Claude's uptime is questionable. With the entire world hitting their system, they don't maintain 99.99% uptime. There were times I simply couldn't use Claude throughout the day. Other MCP systems weren't as reliable, and since I was running MCPs on my local machine, the servers went down frequently. I was constantly restarting Claude to get them back up.

I had this amazing system with brutally bad uptime – what felt like 80% at best. That's when I decided: enough. Time to build my own solution.

Knowledge Management vs. Task Tracking

Before building, I needed to clarify the distinction between knowledge management and task tracking in my workflow:

Knowledge Management:

• Long-term documents written by me

• I control what goes in (no AI auto-importing)

• Location and structure are bespoke

• Used for brainstorming and organizing ideas

Task Tracking:

• Short-term tasks and engineering logs

• History matters but is temporary

• Feeds into long-term documents

• Action-oriented and prioritized

My AI needs differ between these spaces. For task tracking, I'm fine with AI-written artifacts – the AI can write the entire task description based on my input. I love auto-tagging and filing for tasks but am more cautious about it for knowledge management. Semantic search is essential for knowledge management but less critical for well-structured tasks.

This clarity helped me concentrate on what I really needed to build.

Introducing Benny Chat

So I built Benny Chat – a custom solution focused on task tracking while connecting to my knowledge management system. Here's what it can do:

1. Task Management: I can ask "What are my current to-dos for today?" and Benny pulls them from Todoist. I can create new tasks, and they appear with checkboxes that maintain context across different chats.

2. Knowledge Access: I can search my Obsidian notes with queries like "Look up my notes related to React Native" and get relevant results. Benny can display full notes with metadata and AI summaries.

3. Visual Content: It even renders my Excalidraw files directly in the chat, allowing me to reference visual notes and diagrams.

4. Web Search: Through Perplexity integration, I can perform web searches without leaving the chat.

All of this runs on a server, so I can use it on my phone or on the go. I've set it up with connected all the necessary MCPs (I even wrote a custom GitHub search MCP for my specific needs).

The result is better than Claude Desktop + MCPs for my specific needs – more reliable, more tailored to my workflow, and more integrated with my existing tools.

Try Benny Chat Yourself

If this sounds useful, here’s how you can start experimenting with Benny Chat:

1. Join our Stable Discussion AI Discord community where you'll connect with AI experts and get early access to tools like Benny.
   

   Join our Discord

2. Subscribe to our paid plan on Stable Discussion, which also includes access to our Discord community.
   

   Subscribe now

Both of these options options will give you access to Benny Chat and other AI prototype tools we're developing. You'll be able to use Todoist, GitHub repos as a source (great for Obsidian notes), and Perplexity for web searches.

I'm excited to see what you make of Benny Chat and how it might transform your workflow the way it has mine. After this exploration, I've found that sometimes the best solution is the one you build yourself – especially when it comes to integrating AI with your personal knowledge and task systems.

What knowledge management and task tracking tools are you using? Have you tried connecting them with AI? I'd appreciate hearing about your experiences in the comments!

I’ve even noticed myself go down this road a bit in my recent post on v0:

The Blind Spot in AI Tool Reviews

When a reviewer evaluates Bolt.new, Lovable, Replit, or v0 without specifying exactly which version they tested, they're inadvertently misleading their audience. Consider these real examples from just the past few months:

• Bolt.new transformed from a web-only development environment to supporting native iOS app development with Expo in February 2025, then added one-click Figma integration in March, completely changing its value proposition.

• Lovable evolved from a single-player to a collaborative platform with its v2.0 release, introducing multi-step reasoning capabilities and direct code editing that fundamentally altered how users interact with the system.

• Replit released Agent v2 in March 2025 with major performance improvements, then implemented significantly faster AI response times in April—making benchmarks from just a month earlier essentially meaningless.

• v0 has undergone its own significant evolution enhancing editing through locking of files and pushing changes up to Github along side deployments to it’s hosted environments on Vercel.

In addition to the announced changes listed, there are another series of changes that occur behind the scenes. Rather than model releases (GPT-4 vs GPT 4.1) these tools continually evolve behind the scenes.

The problem isn't just academic—it has real consequences for businesses and consumers making decisions based on these reviews.

Why Version-Blind Reviews Fail Their Audience

Imagine reading a glowing review of Bolt.new that criticizes its lack of design tools, only to discover that the Figma integration released three days after the review was published solves exactly that problem. Or picture a comparison chart showing Lovable as a solo-developer tool when it now supports full team collaboration.

These versioning omissions create three specific problems:

1. False Equivalence: Comparing tools without version context is like comparing different products entirely.

2. Decision Paralysis: When readers can't trust reviews to reflect current capabilities, they're left guessing which information is still relevant.

3. Resource Waste: Organizations invest time and money based on outdated information, often requiring costly course corrections.

The Versioning Vacuum: A Fundamental Industry Problem

Unlike traditional AI model companies that clearly label versions (GPT-4, Claude 3.5, etc.), many AI development platforms don't offer standardized versioning systems at all. While Lovable has embraced formal versioning, others like v0 operate on a continuous deployment model with no clear version markers.

This versioning vacuum creates several challenges:

• No Common Reference Point: Without standardized versioning across platforms, it's impossible to establish equivalency when comparing features.

• Invisible Improvements: Major capability enhancements often roll out silently, with no version identifier to signal the change to users.

• Documentation Dilemmas: Changes to pricing models and feature availability can occur without version identifiers, making it difficult to pinpoint when critical changes were implemented.

• Platform Metamorphosis: These tools can literally transform their core identity between "versions" - from Bolt.new's transition to Figma integration or Lovable's evolution from solo to team collaboration - making comparison a moving target.

This lack of industry standardization means reviewers must work harder to document the exact state of each platform at the time of review, and readers must be even more vigilant in verifying that information remains current.

How to Fix the Problem (For Reviewers)

If you're reviewing AI development tools, a new standard of documentation is essential:

• Always specify the exact version number tested for each platform (e.g., "Lovable 25 - 04 - 2025 tested on April 27, 2025") where possible

• Document key feature availability at the time of testing

• Include update notes if significant changes occur during your review process

• Consider implementing a "review freshness" indicator that shows readers how recently the tool was evaluated

How to Read AI Tool Reviews (For Consumers)

For those consuming these reviews:

• Check the publication date and compare it against the platform's changelog

• Look for version numbers in the review—if they're absent, be skeptical but verify the numbers are not available

• Verify key criticisms against the current version before making decisions. Leveraging tools like Perplexity to investigate at scale can be helpful

• Follow up with a brief trial of your own, focused on features most important to your needs

The Future of AI Tool Evaluation

As these platforms continue to evolve at breakneck speed, our evaluation methods must evolve with them. What we need is a more dynamic approach to reviews—perhaps continuous evaluation platforms that track capabilities across versions or community-maintained comparison charts that update in real-time.

Until then, both reviewers and consumers need to acknowledge the moving target problem. The most valuable review might not be the most comprehensive one, but rather the one that most clearly documents exactly what was tested and when—giving readers the context they need to make informed decisions in this rapidly changing landscape.

AI is changing how products are built, but there's a blind spot: designers are still standing on the sidelines, even as the tools finally let them take center stage. Most teams treat AI as the domain of engineers and data scientists, and for designers, this technical barrier makes AI seem unapproachable and out of reach.

On the other end of the spectrum, there’s a subculture of “vibe coding” and hustle culture. Small teams or solo builders are cranking out rough AI prototypes, often without rigorous product development practices.

But even as these experiments multiply, they rarely result in thoughtful, user-centered products—often sacrificing quality and vision for speed. This highlights a gap: while engineers and hackers can rapidly iterate on technical possibilities, what's too often missing in the process is the guiding hand of design.

I’ve noted that the teams closest to the customer are best positioned to deliver real value. Designers, more than anyone, bridge the gap between WHAT a customer wants and HOW the business delivers it. This makes designers uniquely well-placed to drive and shape how AI is applied to solve practical, customer-centric problems.

What’s new, and what too few teams have noticed: the AI toolchain has finally become accessible enough that designers themselves can prototype, test, and iterate—without waiting for engineering or hunting down a Python wizard.

Design-Driven Product Development

Over the years, I’ve formed a straightforward operating model for developing great products on engineering teams:

On most teams, "Make it Work" means building quick, rough prototypes—getting something functional before worrying about polish or coherence. That may sound efficient, but by relegating design and user experience to the end of the process, these products often inherit all the awkwardness, missed opportunities, and makeshift decisions of their early versions. Design becomes an exercise in damage control and technical compromise—not in envisioning or elevating what’s possible.

Teams can attempt to avoid this list order by doing big planning cycles, documenting ahead of time, or other attempts to "shortcut" the process. However, when they run into problems, these approaches often revert to doing things in this order. This is just the tried and true way of getting things done.

Why not flip this script? What if, from the very beginning, designers were the ones to shape the prototype—not as a surface afterthought, but as the driving force for both how the product functions and feels? If prototyping is the process where key decisions are made, designers should be there, guiding what’s built, not just decorating it after the fact.

Now, as AI makes prototyping more accessible and immediate, designers can move from concept to interactive demo without the traditional bottlenecks. This shift helps ensure that design considerations aren’t an afterthought, but baked in from the earliest steps.

Some of the most innovative solutions come from design-led exploration—where a designer, by understanding both the user and the technology’s constraints, proposes an approach no one else saw. By leading with design, teams can reduce costly rework, discover what users really want earlier, and prevent soulless or awkward interfaces from ever making it out into the world.

Representing Business and Technology

Designers bridge the gap between development and business teams. They translate technical constraints into user-centric solutions that meet business objectives. They also transform high-level business requirements into wireframes, prototypes, and visual designs for developers to build out.

Negotiation is essential, not just to the design role, but across the triad of product, design, and engineering. Each group brings its own perspective, priorities, and blind spots: designers may champion user needs but sometimes underestimate technical effort; developers possess crucial implementation insight but can occasionally lose sight of broader business or user aims; even product or business leaders may bring great vision but stumble on feasibility. The healthiest teams recognize these dynamics and lean into the creative tension, surfacing their assumptions and sharing context early and often.

When these disciplines disconnect, you often see familiar breakdowns: designers shut out of early technical decisions; product obsessing over features without clarity on what’s possible; and developers, at their worst, retreating into reactive “IT mode,” simply processing tickets and change requests rather than partnering in the product vision. Nearly everyone working in tech will have seen these patterns and felt the frustration they create.

The opportunity, then, isn’t for designers to take over prototyping alone, but to pull the process closer to multidisciplinary influence—helping organizations build better products faster by dissolving long-standing silos.

AI Prototyping

AI prototyping is better than ever before. With a competitive landscape of new tools, there are many great solutions that improve over time. And with so many people looking at leveraging these tools, a variety of new techniques are being explored that continue to push what they are capable of.

While coders will likely leverage IDEs (Integrated Development Environments) like Cursor or Windsurf, web-based solutions that don’t require a complex development setup tend to be easier to use. These web-based tools additionally offer the ability for teams to remix solutions with others and share prototypes across a team.

These days, I prefer v0 because of their direct connection to the Next.js technology and their integrated Vercel deployments which are familiar to me. Finding a tool that matches your experience offers a significant advantage. Additionally, the design aesthetics of v0’s solution seem to be pretty good for my needs.

Other tools like bolt.new and lovable.dev offer a similar suite of tools but focus differently to best match the needs of their customers. As this space continues to show huge revenue growth and remains novel to market to users, additional solutions continue to be released.

Designers Building with AI Prototyping

I was able to run a workshop on AI for the design team at Compass Digital. This workshop provided AI fundamentals for building personalized AI design workflows but also provided guidance on prototyping using vibe coding techniques. By the conclusion of the session, the team felt familiar with the concepts and were putting together some really interesting designs that immediately pushed at the limits of what’s possible with these prototyping tools.

Designers often need to guide coders and product managers to understand what’s possible. Because coders are more focused on the code, a user experience that aims at a specific visual style often gets lost on them. Product managers are excited about what they know but are usually a bit more concrete-minded and need to be shown what’s possible. Once they get it they’re usually fully behind an idea.

At my first startup, I saw firsthand how designers can expand what teams believe is possible. We were stuck on a UI detail—a post-it note display the developer thought couldn’t be built with CSS. I took a stab at it and sent over a solution. When my cofounder saw it working, he realized more was possible than he’d assumed. That moment not only solved our immediate problem but also deepened our collaborative approach to product development.

Designers frequently bridge gaps between vague ideas and concrete solutions. With AI prototyping tools, they're even better equipped to overcome blockers and build stronger, more collaborative relationships with other teams.

The New World of Design-Led Implementation

We’re now establishing a new operating model:

1. Design to make it work

2. Develop to make it right

3. Collaborate further to make it good

With new AI code generation tools, designers are better positioned than ever to build incredible things. These initial solutions can be the foundation of great features that enable the rest of the teams to better build and establish solutions that bring it to life.

If designers remain sidelined, teams will keep shipping products that feel disjointed, generic, or frustrating to use. But if design leads without staying grounded in technical and business realities, solutions may end up beautiful but impractical or impossible to bring through to production. This new approach depends on design remaining tightly connected to both business goals and engineering constraints, stepping beyond old silos to work collaboratively from the start. Rather than throwing things over the fence to development and back again, we must establish clear outcomes and follow them all the way to conclusion.

While this is likely only possible with web development teams due to the limitations of these tools, it’s extremely likely that code generation tools for apps are just around the corner. For now, web teams are living in the future and should look to benefit.

If you feel like your team is excited about this future or you’d like to learn more about what AI can do for your design team, we’d love to hear from you. At Hint Services, we run workshops specifically for design teams and offer advice for clients looking to leverage AI tooling in their organizations. If this resonates with you, please drop us a line!

For those unfamiliar, v0 is Vercel's AI tool that generates "production-ready" code from natural language prompts. It's similar to having a junior developer who can code quickly but sometimes misunderstands your instructions.

As of today, April 20, 2025. This is my experience with v0.

The Good: Rapid Development That Works

Starting with v0 was surprisingly smooth. Within 8 or 9 prompts, I had a decent-looking website. Describing what I wanted and seeing it materialize felt remarkable – especially for someone like me who dreads the initial project setup because ideas seem to grow with time.

What impressed me most was how v0 handled the overall structure. It understood the concept of a modern Next.js website, including advanced usages I'm familiar with, and implemented it with clean React components and Tailwind styling. For someone building a marketing site or simple web app, this acceleration is significant.

The Challenges: When AI Becomes Excessively Creative

However, like any AI tool, things weren't perfect. v0 tended to over-index on everything I described, sometimes jumping between different approaches based on subtle prompt changes. It wasn't until I added a screenshot reference that it aligned with my vision.

Several issues required manual handling:

YouTube API Implementation

The YouTube API integration code was... optimistic. v0 created a solution that first searched and then requested the first matching channel – not efficient. It asked for my API key (showing how to get one) but didn't implement it in the code or set it up as an environment variable after prompting me.

As a side effect I now know how to configure environment variables in v0 but I think the assistant was supposed to hide that from me.

Inconsistent Updates

When I asked for specific changes to one section (like the hero), v0 would often change other elements too (like all the headings). This created a situation where fixing one thing would unexpectedly alter another.

Missing Caching

The YouTube API quota was quickly exhausted, and v0 didn't implement caching. For a production site, this is a critical oversight that required manual fixing.

Library Stubbornness

When I tried to implement the latest release of AnimeJS for animations, v0 fought against me, insisting it knew better which version to use. This created a frustrating dynamic – I found myself thinking, "Just do what I'm asking, please!"

The Deployment Dance

The most challenging part was moving the project between Vercel accounts. I had created the site under my personal account but needed it under my company account.

I assumed v0 backed up to GitHub, so I could simply reconnect the repo to a new Vercel instance. Not so fast! When I tried this, I ended up disconnecting GitHub entirely, creating a mess. Now I have two GitHub repos and only one is still linked with v0.

Lesson learned: Vercel instances are first-class citizens, and GitHub connections are secondary. In the future, I'll create a new Vercel project linked to the existing GitHub repo rather than trying to rearrange things.

Ranking the AI Coding Assistants

After testing several “ship to prod” AI coding tools, here’s my ranking:

1. v0 - Despite its quirks, it's the simplest and most helpful. Using it from my phone at the gym was a surprisingly useful feature!

2. bolt.new - Nearly as flexible and easy as v0, but lacks tight Vercel deployment integration I’m already using. I do think I wouldn’t have had issues with Anime.js with bolt however.

3. lovable.dev - Similar to bolt.new but with a less polished experience. I need to give it another try, but my first impression was underwhelming.

4. Replit Agent - Great for backend services but struggles with UI work. And let's be honest – who is writing pure backend services these days?

Final Reflections

Despite the challenges, v0 transformed a task I was too busy to tackle and dreaded into something enjoyable. The hardest parts of web development became easier, allowing me to focus on the creative aspects rather than boilerplate code.

These tools aren't magic. They require a clear vision, specific guidance, and a willingness to fix things when the AI misunderstands. The best approach is treating them as collaborative partners rather than independent creators.

I'm keeping v0 in my toolbox as a valuable assistant – one that can accelerate development while needing occasional adjustments. I'm excited to see how these evolving tools will reshape our workflows and unlock new capabilities.

Have you tried v0 or similar AI coding tools? I'd love to hear your experiences in the comments!

If you’re coming in fresh, here’s a quick refresher:

MCP (Model Context Protocol) Servers connect AI Chat clients to tools and data. Rather than relying on conversation history or what an AI can find online, they instead access data sources and tools. These can be as simple as documents or as complex as APIs. As chat “agents” become more common, these tools are essential for providing valuable grounding for our AI workflows.

My Daily Workflow

My current workflow looks a bit like this:

I keep my notes in Obsidian, my personal tasks in Todoist, and my work tasks in Linear. MCP servers interact with each of these as needed on behalf of my AI clients, Claude or Cursor. I go between these different tools as I work but these connections keeps all of this work in sync. A lot of the outcomes of these conversations become notes that end up back in my Obsidian note files.

This has assembled an AI assistant that is incredibly capable. Acting as my assistant, it will schedule tasks for me, update details as I uncover challenges, and re-organize my day upon asking. I zoom through task creation and organization in the morning, and the AI helps to fill in details that I might otherwise miss.

These little improvements keep pleasantly surprising me. For example, I’ll ask for the AI to create a task to fix a bug with the login page, and it’ll give me a few test steps related to the bug that I should go through to validate that the fix worked as intended. Pretty neat!

How It feels to be a Superuser

I feel like a superuser because I've finally achieved what other AI assistants have promised but failed to deliver: personalized control with powerful capabilities. Let me put this in perspective:

The Evolution of AI Assistants:

• Alexa/Siri: Can connect to services via 'skills' but require exact command phrasing with minimal flexibility.

• Standard ChatGPT: Offers natural language understanding but lacks meaningful customization. It has tool use and service integrations but is locked into using OpenAI’s models and application.

• MCP-Enhanced AI: Combines natural language understanding with direct connections to my chosen tools (Todoist, Linear, Obsidian), preferred AI models, and client interfaces based on my specific needs.

This combination of flexibility and control is what makes the experience truly powerful. Rather than adapting to an AI SaaS offering that is opinionated on how I use AI, I've configured the AI to adapt to a workflow and tools that works for me.

Feedback on MCP Servers

Now, there are always trade-offs when living on the cutting edge. While I'm enthusiastic about these tools, I'm also documenting their limitations to help set realistic expectations and perhaps guide future improvements. Here are the key challenges I've encountered while building my AI superuser setup:

Semantic API Interfaces are Better

As I play with Linear and Todoist, I’ve noticed that there are a few things the AI gets wrong time and time again.

Linear creates a task ID that gets generated when a new task is created, like TASK-123. While the server seems to do a pretty good job creating new tasks, it’ll often use the wrong three-digit number to reference the task.

For Todoist, todos have a priority value from 1 (high) to 4 (low). But for some reason, it regularly misunderstands which is high and which is low when reading or creating todos.

By contrast, one thing that always works in Todoist is adding due dates. I’ll tell it to schedule a task to be done tomorrow, and it always gets that date right! Many AI struggle with dates but Todoist passes with flying colors. What gives?!

This is because the Todoist API can literally be passed “tomorrow” as a value. It has a semantic API and plain language can be interpreted against the interface.

AI models are largely trained on text and, while they can generally read JSON, the results aren’t usually as accurate as when you can interact with plain language. Where possible, we should use natural language to interface with AIs.

Broad or Conditional Interfaces are Trouble

Notion has a very broad interface space. MCP Servers I tried that connect with Notion, could easily create documents but had difficulty working with Notion’s database structure. The agent would error repeatedly and was unable to recover.

I believe this is because of how broad the database schema is in Notion. Notes are parents and children of database entries. This nested structure, and many other optional capabilities, provide a lot of flexibility in what users can create, but it also means that there are a lot of possibilities for what a good API call can look like. Worse, there are may possibilities for what a bad API call looks like.

As we build interfaces for MCP Servers, it’s a good rule of thumb that we make these interfaces obvious and clear without too many optional or conditional options. This complexity seems to be difficult for even the most sophisticated AI LLMS to fully grasp.

If complexity is truly required, offer function “steps” that break down the problem into a series of parts that can be done bit-by-bit to construct a complex step.

Room To Improve Configuration

As things are, MCP Servers are a “use as is” tool. You plug in your API keys to access different services, but there isn’t really a way to specify how you want to leverage that server.

For example, I have projects setup in my Todoist account and I have teams setup on Linear. When I create tasks, I want them to go in the correct places based on what project I’m working on.

As things are, the best way to add this configuration is by creating a Project in Claude Desktop or by adding custom instructions into Cursor for the project being worked on. As we continue to expand our ability to leverage these services, we’ll need to provide some details that pass through from the services and are not always configured on the MCP Client side.

The Approval Interface Feels Limited

As things are, the current interface for MCPs using agents is riding on the systems implemented by Claude, Cursor, and Windsurf. That is the “Approval Interface”. When an AI agent wants to use a tool, you need to approve the tool use and then let it run as desired.

However, I think we can easily do something better here. There are times when I’d love to edit the call at this point, make a clarification, or make a selection of options to pursue. I don’t just want the AI to make these choices, I want to interact.

MCPs Benefit from Self-Configuration

I think the MCP usage is cool BECAUSE I specified it. By contrast, I think I would hate to work with an AI agent that suddenly called tools that I didn’t know about. To some degree, I don’t like the ChatGPT memory for this reason.

When we’re not in control, AI feels scary. Imagine suddenly everything you just chatted with your AI about was going into an email to your colleague. It’s still in draft, but you didn’t even know this was a possibility or something to watch out for.

When you don’t know what tools exist, it’s also frustrating. Similar to trying to make Siri to turn off a light in a room that it doesn’t know about, you’ll spend a lot of time and energy just trying to get things to run. Users need some knowledge of these tools to know email is a capability and not text, for example.

When it’s known and our interactions are intentional, the experience amazing! You can do some interesting research and brainstorming about a topic and then craft an email all within the same AI chat window. These configurations being personalized to the tools we use is a major benefit to us.

As we develop applications that also leverage these sorts of tools, the knowledge of these tools existence is important to note. We’ll need to train users to be aware of these tools and find ways to let them know what is possible.

Setup is still Tricky

I find myself hitting weird issues regularly because we’re still in the first wave of these tools. Releases aren’t managed well and servers regularly break when versions update. Clients seem to have inconsistencies between them when trying to call these servers. And sometimes things just need to be restarted because something got in a weird state.

This also reminds me of being a superuser. Great capability comes with an increased possibility of everything going horribly wrong! Integration is still one of the most difficult challenges of building real systems and services. I’m sure we’ll continue to learn a lot as MCPS become a more widely used pattern for interfacing with AI chats.

Looking Ahead

Despite the current limitations, MCP Servers represent a significant step toward truly personalized AI assistants that work within our existing digital ecosystems rather than forcing us into new walled gardens.

As these tools mature, I expect we'll see improved configuration options, better semantic interfaces, and more intuitive agent workflows. The potential for truly personalized AI assistance is enormous once we solve these integration challenges.

For now, I'm enjoying the productivity benefits despite the occasional hiccups. Being an AI superuser today means embracing both the power and the occasional frustration of working with emerging technology. But the tool capabilities and personalized experience make it well worth the effort.

If you're considering exploring MCP Servers yourself, start small with one or two tools you use daily, and gradually expand as you become comfortable with the workflow. The journey to becoming an AI superuser is iterative—and that's part of what makes it so rewarding.

While just chatting, I usually ask one question at a time. I’m looking to explore what this expert knows. Their answers give me confidence that the AI understands the question that we’re looking to solve. Once I’m satisfied, I’ll start to craft a solution combining all the knowledge I’ve learned the expert has into a solution. Often several questions are merged into a single AI prompt/query given to the LLM.

These combined prompts might look something like this:

Act like an expert on personal productivity with specifically strong expertise around the Pomodoro technique based on the book {bookName}.

Based on the contents of the book can you give me:

1. a quote that references the Pomodoro Technique
2. two key facts that are interesting to note about the technique
3. a summary of the book

When asking about a number of different books, the AI has been able to chat with me and give fairly accurate answers. And, now combined, these questions makes a nice organized program to give me details about the Pomodoro Technique sourcing from any book we give it. Pretty neat!

However, this has process one annoying flaw. As we look at the output, it starts to be strangely coincidental that the summary always seems to be related to the quote and the facts that are referenced. We may even note that the AI expert made up one of the facts, AND that fact has leaked into our summary! That fact didn’t exist in the book at all but the expert seems confident enough to include it in both results.

To understand what’s happening here, let’s do a quick review of how AI LLMs think:

The “AI Brain” has a context (memory) that contains the prompt (setup) and the questions that we gave it. This helps the AI predict what the output should be. The AI does this by constructing parts of words that seem most likely to come next in a sequence. These product the outputs (or in our example, answers).

Now, this is a fine mental model, but what it doesn’t show is that the answers given are also included in the context as they are written! An “answer-context” for our purposes here. So while the AI is trying to reply to the question

2. two key facts that are interesting to note about the technique

it’s also referencing the answer it gave to the first question

1. a quote that references the Pomodoro Technique

You can see this represented here:

This is completely unexpected. We want the answers to all come out in the same way as before when we were just chatting. The AI should be able to output the same answers it gave us earlier! Unfortunately, that isn’t the case, and this is where the machine expert analogy starts to get in our way. It’s neither a classical machine program, nor an experienced expert.

AI don’t behave in a structured manner and are “creative” to some degree that actually seems to help them come up with more helpful answers than traditional programs in many domains. They’re constantly looking to take advantage of context to better inform their output. It just so happens, answers are part of that context and generally a great place to source information from. Just maybe not for our case.

While we’re trying to give the AI clear instructions, we also need to evaluate how it’ll interpret answers as each answer also becomes part of their programming. It’s strange to think of an expert acting that way… Imagine if you were on a call with your doctor and because he mentioned something about tennis earlier, he’s suddenly convinced that you might have tennis elbow.

Now, this “recency bias” isn’t always a bad thing, we can also use this answer-context to better inform our outputs too. Say we want to understand how relevant a quote is, we could instruct the AI with a prompt like this:

Act like an expert on personal productivity with specifically strong expertise around the Pomodoro technique based on the book {bookName}.

Based on the contents of the book can you give me a list of quotes that are in the book related to the technique. After each quote, tell me how confident you are that the Pomodoro Technique is directly related to the quote by giving me a confidence rating from 0-100%

This kind of prompt will have the AI return each quote followed by a rating of how confident it is in the choice of quote. This is a great way to use the answer-context because it allows the LLM to evaluate the output it just gave us and verify how confident it is in the result.

However, order those questions in the opposite order (ex. “give me a confidence rating and then the quote”) and the confidence rating stops meaning what we think it means. Instead, the prompt simply tries to be confident when giving the answer that follows the rating, which isn’t quite the same thing we were hoping to achieve.

I’ve been able to apply this technique of applying a confidence rating successfully to filter out bogus answers and generally arrive at more stable AI solutions. It does require a steerable model, and you may find some models more or less capable of creating these measures in their output. GPT-4 has been the most consistent at creating accurate answers in my testing.

As you can tell, prompt order is kind of a big deal when asking for multiple things. It’s something we’re not geared to watch out for when programming or speaking which makes it easy to overlook when trying to make a quick change. And this is where prompts can often get brittle, too.

Say that later, after some time has passed, I come back to make some changes to the prompt. I make a couple changes to generate a bit more data and happen to re-order the questions being asked. This simple change can completely change the accuracy and quality of the output. Everything being the same, this order change can result in a dramatic shift.

This leads to my practice of making “One Request, One AI Call”. Try not to mix contexts where possible, and request separately for each question that we’re looking to ask. Then later combine the results back into the list answers we were hoping to receive.

This one simple change allows each answer to be performed optimally, and the LLM can focus on the specific task that helps to arrive at each answer. This simplifies how many things are happening, improves accuracy, and can even allow us to downscale the size of the model we need to use for some answers.

But AI calls don’t come cheap. But they do when we can cache the responses we get back from an AI service. Context caching is one of my favourite features that has been rolled out by AI companies in the recent months. It allows us to store the context that the AI knows about so that when another call uses that same context, we can leverage the cache that we already have.

Both OpenAI and Anthropic have solutions available for context caching and it’s turned on by default on many OpenAI models. When making a request using an existing cache, we’ll save around 50% on the subsequent calls. This is a great tradeoff which allows us to get back some of the cost of making so many calls.

Next time you’re debugging your AI solution, try to take a look at how you’re setting up each part of your system. I’ve seen a lot of different teams get stuck on these parts in my time at Hint Services and it’s an easy spot to overlook. As we continue to find these issues it’s become easier to find where we can help and advise companies on better paths of action.

It remains unclear how this applies to thinking-class models like o1. Because a lot of the thinking happens under the hood, it’s difficult to really engineer solutions using their approaches. These tools create their own order of operations as they think through steps internally. At this point it may be safe to assume that there is a bit of logic around this kind of recency-bias that is baked into the step creations of those models. As things develop, we’ll be sure to update you.

Other Ways to Support Stable Discussion

If you’re interested, there are a number of companies that have made us affiliate members. We love these tools and are lucky enough to get a bit of a kickback if our users download them. Try them out and let us know what you think:

Wispr Flow 🎤 - easy voice to text app
Eleven Labs 🗣️ - excellent AI voice creations
Descript 🎬 - amazing AI video editing platform we use for our Youtube
Warp 🌀 - great replacement terminal

You can see the entire video here or look into my notes below if you want a quick summary.

Side note: If you liked seeing how I was able to prompt the AI with just my voice, you might enjoy trying out Wispr Flow. I’ve been using it for a while now and it’s been a huge productivity boost for me. Almost don’t have to type anymore!

Winsurf has a few things that are really going well for it:

1. I really love how Windsurf handles its ability to run cascades, which are these flows of changes over code.

2. I like how they show that they're analyzing, diffing, creating and running terminal commands. I think the distinction between those feels very good.

3. I like how it's able to retry commands when it fails and attempt to keep going even though something didn't happen quite right. It seems to be very advanced in that regard.

Good Workflows

This thing is the best terminal command runner I've used to date. It seems way better than a lot of the other terminal options that I've had before as it has way more context than most terminals.

Unexpectedly, it seemed to work pretty well with two projects open, but it did seem to be mainly because I prompted for one project or another. I worry that if you weren't specific, it may mingle the two.

Github Copilot Level Autocomplete

The Autocomplete is definitely worse than Cursor and feels a lot like Copilot.

I don't get the same tab-tab-tab auto-completion a bunch of code the way that I do when I'm using a cursor.

Bad Workflows

Conversation history is tied to the state of the chat, so there's no going back in time to ask something with just the right context. This severely limits how I generally work with AI models.

Specific tasks seem to work great, but I find the code generation that it does is not very creative. Code generally seems to be a better result when I'm using Cloud directly versus using this tool. Seems to align too closely with my code at times.

It seems like it can run pretty quickly until you've got these big files. Then it seems to really take forever. I'm not sure why. Maybe staying fast just means working with smaller files.

Bad Ergonomics

Asks for permission to run scripts other times it seems to just go wild and create a bunch of stuff. This can feel inconsistent and a bit annoying.

The feeling of waiting really sucks and I'd kind of get bored using it. Waiting for things to complete.

I can’t work while it’s working. When I do try and keep myself busy and make edits during that time, there's a diff which actually derails its ability to generate its own code, which just feels bad.

Adding contexts just feels pretty boring and uninspired. There isn't a preview and it doesn't have as many nice features as Cursor has when you're looking at the context you've included.

Additionally, the context you can include seems pretty limited compared to cursor.

The hotkeys are just a little bit different than cursor and it keeps messing me up. I keep having to hunt for a hotkey, which maybe is just a learning curve, but feels bad.

Summary

Windsurf represents an interesting step forward in AI-powered development environments, particularly in its terminal command handling and error recovery capabilities. However, its promise of maintaining developer flow states falls short for me due to long delays in responses and workflow interruptions.

For specific tasks and smaller projects, particularly those involving complex terminal operations, Windsurf can be a powerful tool. But for larger projects or when you need more creative code generation, you might find yourself reaching for other tools in your development arsenal.

“No matter how good the ghost, I am convinced that a book loses realism when an interpreter stands between the storyteller and his audience.” - Michael Collins, 1973

This stuck with me today. Upon reflection, we have many more interpreters of all forms than they did back in 1973. Capturing the authors intent may not matter for a refrigerator manual but it does when a human is actually expected to read and be persuaded to act or learn. These forms of human-centric writing from strategic reports to works of fiction contain an essential human element. An element that feels lost when given up to someone else who doesn’t share the same experience.

Novice authors in these spaces don’t notice that their voice was lost in interpretation. Professional authors can tell, it’s one of the most important aspects of their work. But those less accustomed to calling themselves an author often don’t look to see themselves in their words.

At the other end, even a poor reader can tell that a voice is absent. They discover that the incentive of the writing is not to connect with them but to simply present at the general “them”. This is similar to what you might read in the refrigerator manual and takes a good deal of the fun out of reading.

Professional ghostwriters attempt to disappear behind their subject and present from the subject’s perspective. Professional biographers bring themselves into their stories to help highlight what they’ve seen and learned about their subject in a more relatable way. AI generation brings itself into its storytelling as well, but unfortunately doesn’t have any connection to offer. It’s a bad biographer without much to add besides trying to act helpful.

I find even the most clever AI-assisted works of writing end up being more noise than signal. I slowly realize I’m looking for communication cues that don’t exist and get frustrated trying to interpret the ideas presented to me. Written words are communication, and it’s annoying to find the person I’m conversing with has outsourced their part to cold silicon.

But AI is just assisting. Shouldn’t it be able to surface this inner human voice that is prompting it? Can’t it find a way to surface the human element that conjured it? It seems not.

I wonder if this lack of AI capability is because engineers see words as they are and assume the meanings are direct. Perhaps those involved in this research don’t have a sense for the words behind other words. Or maybe because it’s such a difficult concept to find, capture, replicate, and present that the entire pursuit is abandoned before it ever really began… it’s not commercial enough.

While they may miss essential concepts, AI Summaries have a reasonable length and I don’t feel like they miss the sense of authorship. This writing can be skimmed and doesn’t ask for much time. By being short it doesn’t leave much room to assume someone is trying to say more than what has been said.

NotebookLM’s AI created podcasts however, have this same authorship problem. While listening, I’m feeling an energy from the narrators that sounds good, but eventually the ideas just don’t quite connect. When I look at the source material they’re referencing, I find that sometimes they’re just getting excited about random specs or features unrelated to the general purpose of the episode. An overall deflating experience.

This podcast tool is great for reading something that’s awful to read generally, like terms and conditions documents, but it’s poor at covering actually interesting stuff. It just misses the point of interest.

But that’s because there is no point of perspective. There is no incentive or personal stake in the creation. It’s simply a mass of generated content hastily constructed from available inputs aligned across a shallow sentiment. Words spoken based on a bare-bones command without thought for the inner workings of what we’re really trying to say. A meager interpretation.

I wonder if this is why AI feels more aligned when we voice our prompts… We say all of what we were trying to say and not just what we can easily regurgitate and have the energy and determination to type. I have been generally surprised that I’ve said more than expected when conversing with voice mode on the latest ChatGPT.

Perhaps we still haven’t captured our lightning in a bottle. We may still need more tools to understand and interpret our expression more fully so that it may be replicated truthfully. But still, I wonder if the AI community at large will be able to tell that the message has been lost on its way out the door. That the interpreter has mistaken our underlying meaning and disconnected us from those who we were most hoping to reach out to.

This opens up all-new, incredible opportunities for teams to prototype new ideas for their applications; specifically on websites. Never before has there been as powerful of a tool for combining developers, product managers, testers, and designers all together into one force to prototype ideas. It’s also great if you aren’t on a team but just want to try building something out!

At Hint Services, we recently were able to go through a workshop where we worked in Claude Artifacts to prototype an entire form flow with our team. Working at the speed of ideas we quickly aligned on a vision for the application that took ideas from everyone. With the experts in the room, they were able to provide their ideas in real-time without needing to have costly feedback loops or demos.

We find this tool incredible for our work and want to help more people leverage this tool in their day to day. A big part of that is how to get the prototypes that are created to feel like your application rather than a generic application. That “feel” is a big part of creating a great prototype.

Here’s an example of a failure I created while trying to generate a design system for Claude’s Website:

So today, we’re going to help Claude develop our own Design System definition for our application. This definition will help us better create prototypes that fit the style and aesthetic of our application or an ideal application if you just have screenshots to go off of. If you’re non-technical, don’t worry about it. I’ll be including a lot of prompts that will help you get there in no time.

If you’d like to follow along on YouTube, here’s the link to our walkthrough for this code:

Creating the Design Definition

For this example, I’m going to be generating a design definition for Starbucks. We get some benefit that Starbucks has a lot of design that has been shared with the design system community, but that also replicates some of the design details you know about your own site.

First things first, we need to get some screenshots of our existing application. I took a few screenshots on my phone and uploaded two of them alongside a prompt for us to get started:

Act like a design system expert. Analyze this screenshot of our application and help me extract the style variables that will be helpful to reproduce this style across other components in our application. Focus on font, colors, spacing, and rounding. Think of the CSS variables that might make sense to represent these. Output the results in groupings based on category and place in a table for readability

This immediately starts generating some great variables and descriptions for us to start using and thinking about:

But this is hardly complete. I’m going to upload another screenshot now with the following prompt:

Expand on the colors a bit more and be sure to define how these colors should be used exactly. Take this additional screenshot into account too

Great, now the colors feel a bit better and more related to the application’s design. The fonts now need to be added, and we need to make sure it knows to pull fonts from Google Fonts due to some limitations of working in Artifacts. We want to be able to see our designs in Artifacts so I’ve added some details of how to specify the fonts in a way that renders what we need it to:

Can you get the font that is most similar to this screenshot that is available on Google Fonts.

Once you get that, let's take that font and add a definition for it using a link tag and a basic CSS snippet that can be used to use the font in a website0

Now we’re pretty much set for our design definition, but it’s hard to see just from these code snippets and tables. Let’s create a preview of our design in Artifacts so we can see everything:

This looks great. Can you take our style sheet and use it to build a style guide page in React using tailwind to highlight the guide visually to display colours, spacing, and other properties listed?

I want to see the output in Artifacts and many tailwind features do not work in Artifacts. Define our designs system colors as css or `style={}` props rather than assuming that we can specify custom inline colors `bg-[#000000]` with tailwind or custom tailwind classes `bg-primary-500` or variables referenced in tailwind `bg-[--var-text-color])`. Many tailwind features do not work in Artifacts. Also output the font as a link and css definition as some imports may not work either.

Just output a single snippet rather than breaking it up into multiple

Now we have a really great rendering of our design system:

This is great for previewing the elements but doesn’t capture enough of the rationale for why we use each color, spacing, etc. So we want to also generate a text file that has some of these properties listed in it.

Great! That looks awesome.

Let's take this and now generate a markdown file with all of the details of our design system in it. Let’s get the full list of variables and list them all out with their usage as a note. Don’t need to group it in a table now let’s just do sections, variables, values, and usage notes about how these variables should be used

This will create a document we can also reference when we want to use our design definition to create new prototypes:

Now we’re ready to build out a new prototype using our design definition of our application!

Creating Prototypes

Now, we can download the code and our design system document to be used in creating a new component. Feel free to keep the same chat going or start a new one with these documents as you start creating new components:

Act like an expert React and tailwind developer proficient with using design systems. Can you take the design system definition I've created to create a new date picker component?

I want to see the output in Artifacts and many tailwind features do not work in Artifacts. Use our designs system colors as css or style={} props rather than assuming that we can specify custom inline colors bg-[#000000] with tailwind or custom tailwind classes bg-primary-500 or variables referenced in tailwind bg-[--var-text-color]). Also output the font as a link and css definition as some imports may not work either.

We’re now off to the races creating new prototypes and pages! While you may not get great results every time, you’re now in a position to better inform Claude of what looks right when building out new prototypes.

Have fun and be sure to follow us if you found this insightful or interesting!

Troubleshooting Errors Creating Prototypes

Lastly, I wanted to include a quick set of troubleshooting tips. Results may vary when creating prototypes, and there are a couple of things to watch out for if you have trouble along the way.

Sometimes it generates part of the code without the colors being defined, or where they are defined in a way that can’t be seen in Artifacts. That’s where the second part of the prompt comes in. Sometimes re-iterating that part can help ensure things output as expected.

Other times, Claude breaks prototypes into multiple blocks of code or generates too much data. This can cause some parts of the prototype to get ignored. Reminding it you want to see it all in one place for an Artifact can be helpful.

Eventually, you may also see errors if Claude generates a lot of code but gets cut off because the code is too long. Tailwind helps with this, but the size of the code can still grow too big. If you hit this issue consider breaking your prototype into smaller parts that can be rendered in Artifacts and then combine them into code after the prototypes have helped fully flesh out the ideas.

Leave a comment below if you find other helpful tips and tricks along the way!

Through the creation of the internet, we’ve become more connected than ever before. The ability for us to search for answers to our questions has helped us to sort and organize this information to be useful. Now many questions can be easily answered but it’s becoming more difficult to know if the answers we’re looking for actually exist.

Think about content services like Netflix. Do they make it easy to see that they don’t have a series of movies available? No, they show content they do have that might fit your tastes and only when searching for a specific movie will they say that they don’t have that title. Netflix then tries to immediately distract you from your displeasure that they don’t have the movie by showing a list of other eye-catching movies.

Netflix gives us the impression that they have every movie ever made but they can’t. They don’t have the rights to some movies across different countries. Some movies aren’t watched enough to be worth keeping available for ease of viewing. There are many reasons Netflix doesn’t have every movie although as a user you might forget that until you look for enough movies that aren’t included in their lineup.

Many digital products can easily present users with an abundance of content. Amazon has created one of the largest and most active digital stores. Navigating between categories you can basically teleport around the real-world equivalent of a store. By jumping directly to a product customers feel powerful and encouraged to purchase the product that’s right for them.

Still, Amazon doesn’t have every product. But it’s hard to remember that! It feels like they might have everything.

Recently I viewed an excellent visualization of Wikipedia’s content (shown above). Wikipedia is another site that could believably convince us that they have almost everything in their database. But even so, they have some distinct focuses on their content. With fans of Football and K-pop focusing their energies on Wikipedia at a larger scale than other interest groups, this graphing highlights the possibility that many niche topics are missing Wikipedia entries.

Important figures in many industries may be missing pages entirely. Key events that have shaped thousands of people might not have been of enough of a note to get their own Wikipedia page. These impactful people and events might never get entries without clear and credible sourcing.

If you could look at all of Amazon’s products from high above and sort their categories you might start to notice empty shelves or entire sections of the store that are vacant. Somewhat troubling in a traditional store, it’s all but invisible through the customer interface. How many other digital products are like this?

YCombinator, a leading startup incubator in Silicon Valley, mentioned that discovery apps helping people find things are one of the most unsuccessful categories of startups. Largely because people underestimate how difficult it is to collect the content, present it to people, and have consumers adopt it without large-scale marketing to bolster its adoption. The effort is larger than it looks and is a “tarpit” that will trap you if you get in close enough.

Furthermore, they go on to mention that there is a finite number of things to discover. Whether that’s videos or products, eventually you run out of new things to add to the site. That might imply that eventually you’ll have everything on your site but the actual implication is that eventually it will be too difficult or take too much effort to continue to find new things to add to the site to ensure you have complete coverage. Besides, as we’ve discussed, customers might not even be able to tell if you have everything.

AI products are no different and are perhaps even more difficult to map or understand. We have tests and leaderboards to understand the capabilities of AI models today but I’ve found those tests don’t map clearly to real-world scenarios. As companies push to achieve better and more generally useful AI, do expert use cases drop off and do any but a few people notice or care? After all, so many people bought Alexa devices despite only having a narrow set of useful features.

What’s becoming more complex, AI is now helping fill some gaps when you go looking. Using AI search providers like Arc Search, Perplexity, or Kagi you can generate a summary of any search you’d normally perform on a browser like Google. These tools take traditional search results and look to answer your query with the power of LLMs. It just feels so much better than the traditional browsing experience that I can’t help but use these features.

However, I worry about AI's difficulty saying no. Ask it a question that doesn’t make sense or give it a reason you believe something and it will only weakly, if at all, push back against you. More worrying, if you’re looking for an answer from an AI it may just make one up if an answer doesn’t actually exist.

So, we have a data problem. We have the issue that many sites and sources we use every day can’t clearly indicate gaps in their content space. New companies are unlikely to compete in the same space due to the difficulty and constraints of aggregation. And AI summarizers could look to fill these gaps with their own generations to keep us browsing and buying.

I think this is important to acknowledge and think about. We’re entering a weird bubble-like period of AI investment and being cautious is a good idea. Evangelizing too early, as seen with the Rabbit R1 and AI Pin, can result in customers bearing the costs of the optimism around the possibilities.

But we still need to invest in AI. There is the potential to do incredible groundbreaking things. We just need a healthy dose of caution and awareness as to what to look out for. Data gaps and experience gaps are a major concern and one that I think will sneak up on you if you’re not looking out for them.

Digital products are, almost by definition, marketed based on a kind of magical thinking that the software could provide for our every need. We’ll see what this next wave of AI services and features bring but I’m not optimistic this gap is going away anytime soon.