I've been watching the OpenAI Dot conversation with genuine interest, and honestly, it hit something I've been frustrated about for months. Last Tuesday, I asked Claude to help me set up a new Postgres migration, and after thirty minutes of back-and-forth, I realized the assistant had lost context three times. We were doing the exact same task, but I kept having to re-explain myself. That's when I thought: "Why is this so hard?"
The original article nails something real that I think gets glossed over in the hype cycle around AI assistants. It's not that these tools are bad, they're genuinely useful. It's that there's this massive gap between what sounds cool in marketing and what actually works when you're trying to ship code from your phone at 11 PM before a deadline.
The Promise vs. The Friction
What intrigues me about the Dot experience is that it actually acknowledges the friction exists. Too many AI products pretend their integration is seamless when it absolutely isn't. The author describes hitting walls with Claude integration, Unity workflows, and deployment previews, these aren't hypothetical problems. These are the actual blockers I encounter too.
The core issue is this: AI assistants are designed for conversation, but real development workflows are designed for continuity. When I'm coding, I don't want to restart context every time I switch from my IDE to a terminal to a browser. I want one thread of understanding that persists. The Dot can start a coding session with Claude, but then you're stuck. You can't easily send follow-up instructions into that same session without breaking the conversation. That's the gap.
Where AI Assistants Actually Help (And Where They Don't)
Here's where I agree with the original perspective: being able to dump ideas into a system and have it organized back to me is legitimately useful. I do this with Cursor AI in my editor, I'll paste a problem description, iterate on it verbally through the chat, and get actual code back. That works because it's all in one interface.
But then try to take that result and test it on your phone. Try to open a live preview of a prototype you just built. Try to trigger a GitHub action and wait for feedback without polling manually. Suddenly you're back to context-switching and troubleshooting the meta-problem instead of solving your actual problem.
The author mentions paying $200 to OpenAI and $200 to Anthropic because they serve different purposes. That statement alone tells me the real issue isn't the AI, it's the orchestration. We're at a point where the tools are good, but the workflow around them is broken.
What Actually Needs to Change
I'd implement this differently. Instead of having an AI assistant that starts tasks on your computer, I'd focus on giving it real-time context about what you're building. Here's what that might look like:
// Instead of asking your AI to "open my app and test it"
// You give it actual context about your current project
const assistantContext = {
currentProject: "PocketQuests",
activeServices: ["localhost:3000", "postgres://db"],
recentFiles: ["components/Quest.tsx", "api/quests.ts"],
lastDeployment: {
url: "https://pocketquests-staging.vercel.app",
status: "ready"
},
capabilities: {
canRunCommand: true,
canAccessFiles: true,
canAccessDeployment: true
}
};
// Now when you ask "test the quest interface"
// The assistant knows exactly where to test it
// and what it's allowed to do
This removes the guessing game. The assistant knows what it can and can't access, and it delivers results in formats you can actually use.
My Real Frustration
What gets me about the current state is that we're so close. The technology works. Claude writes solid code. GPT-4 understands complex systems. But they're all wrapped in these chatbot interfaces that were designed for Q&A, not for collaborative development work.
The voice interaction point resonates with me too. I'd genuinely use an assistant more if I could voice-command the workflow instead of typing between three different interfaces. But that's only valuable if the voice conversation can actually persist through the development process, not just initiate it.
What I'd Do Differently
If I were building this, I'd start by mapping out actual developer workflows, not generic ones, but real sequences of actions. Then I'd work backwards from "what would make this seamless?" instead of forwards from "what can our AI do?"
That might mean tighter integration with IDEs, or it might mean building an actually-useful plugin ecosystem, or it might mean admitting that some tasks need a human in the loop.
Do you use AI assistants in your development workflow? What's the one thing that constantly frustrates you about how they work? I'm genuinely curious if my experience is widespread or if I'm just using them wrong.
Source: This post was inspired by "Things I wish my Dot could do" by Dev.to. Read the original article
