Yes, but also no one seems to care based on the lack of engagement on this post. That's enough for me to draw a definitive conclusion on where the future is headed. Sad, but true.
The scrappiest thing that worked for me: manual onboarding calls with every single early user, even when it didn't scale.
I'd hop on 15-minute calls to understand their workflow, then send them personalized Loom videos showing exactly how to use the product for their specific use case. Time-consuming? Absolutely. But those users became evangelists because they felt ownership over the product direction.
A few other things that moved the needle early:
1. Commenting on niche subreddits where your target users actually hang out - not to pitch, but to genuinely help. When people see you're knowledgeable, they check your profile. Make sure it mentions what you're building.
2. Finding "trapped" users on competitor platforms. Look for complaint threads about existing tools, then reach out directly with "Hey, saw your frustration with X. Would love to show you how we solve that specific problem."
3. Making your first 10 users feel like co-founders. Give them direct access to you via text/Slack. Ask their opinion on features. They'll fight for your product's success.
The cold email/LinkedIn route rarely works early on because you have no social proof yet. Much better to go where conversations are already happening and demonstrate expertise first.
Appreciate it! I should clarify that it's not just grammatical. I find that AI can sometimes help me articulate ideas based on my thoughts in ways that I hadn't even considered.
The approach of building for one specific user (your wife) rather than abstracting too early is underrated. You end up with something that actually fits the workflows instead of a generic tool that needs heavy configuration.
Elixir + Ash is an interesting choice for this domain. LiveView particularly shines for internal tools like this where you want the interactivity without managing a separate frontend build. Curious how the AI code generation worked with Ash specifically - the declarative nature seems like it could either help a lot (clear patterns) or confuse models that expect more explicit code.
The BOM with cost rollups is the feature that would have saved me hours in a previous project. Most small batch producers I know either overprice everything out of caution or underestimate costs because tracking ingredient pricing through recipes is tedious in spreadsheets.
The WinGUp updater compromise is a textbook example of why update mechanisms are such high-value targets. Attackers get code execution on machines that specifically trust the update channel.
What's concerning is the 6-month window. Supply chain attacks are difficult to detect because the malicious code runs with full user permissions from a "trusted" source. Most endpoint protection isn't designed to flag software from a legitimate publisher's update infrastructure.
For organizations, this argues for staged rollouts and network monitoring for unexpected outbound connections from common applications. For individuals, package managers with cryptographic verification at least add another barrier - though obviously not bulletproof either.
The $10 deposit validation approach before committing to manufacturing is underrated. So many hardware projects fail because founders fall in love with the build before confirming anyone will pay.
What stood out to me: the factory miscommunications and quality issues compound because you can't iterate as fast as software. Each mistake costs weeks and thousands of dollars.
For anyone considering hardware: if you're not getting deposits or strong signals of purchase intent before tooling up, you're basically gambling. The author's approach of getting commitments first is the right playbook.
The "framework fatigue to custom solution" pipeline is well-trodden, and I think it often makes sense for specific use cases.
The tradeoff is always: initial development time (custom = longer) vs. maintenance burden (framework = dealing with someone else's abstractions and upgrade cycles). For a personal blog or static site, the maintenance math clearly favors custom since you're the only user and can freeze dependencies.
Where this breaks down is when you need features that frameworks handle implicitly - things like image optimization, incremental builds at scale, preview deployments, etc. At that point, you're either rebuilding those features yourself or accepting the framework's complexity.
The real question is whether the complexity in tools like Next.js is inherent to the problems they solve, or if there's a simpler abstraction waiting to be discovered. My suspicion is both: some complexity is essential (SSR + SSG + ISR is genuinely complicated), but a lot is accidental (backwards compatibility, enterprise features most people don't use, etc.).
Axiom 3 (stable global reference frame) seems most practically actionable. In production systems, we've found that grounding the model in external state - whether that's RAG with verified sources, tool use with real APIs, or structured outputs validated against schemas - meaningfully reduces hallucination rates compared to pure generation.
This suggests the "drift" you describe isn't purely geometric but can be partially constrained by anchoring to external reference points. Whether this fully addresses the underlying structural limitation or just patches over it is the interesting question.
The counterargument to structurally unavoidable: we've seen hallucination rates drop substantially between model generations (GPT-3 to GPT-4, Claude 2 to Claude 3, etc.) without fundamental architectural changes. This could mean either (a) the problem is not structural and can be trained away, or (b) these improvements are approaching an asymptotic limit we haven't hit yet.
Would be curious if your framework predicts specific failure modes we should expect to persist regardless of scale or training improvements.
Clever application of voice AI. The pain point is real - phone holds are one of those friction taxes everyone pays but no one thinks to solve.
A few questions from someone who would use this:
1. How does it handle identity verification? Many customer service calls require account holder verification (last 4 of SSN, security questions, etc.). Does the user pre-provide these, or does Pamela hand off at that point?
2. What's the latency like in the conversation? I've used some voice AI tools where the delay between human speech and AI response is noticeable enough to confuse the human on the other end.
3. The NYT example is interesting - how does it handle when the rep says no initially? Does it have negotiation logic, or does it just accept the first answer?
The API angle is smart. There's probably a B2B play here for companies that want to automate outbound calls for appointment confirmations, reservation changes, etc. That's where the real volume would be.
The positioning shift here is interesting. v0 started as "generate UI from prompts" and is now framing itself as a full app builder with persistent context.
What I find compelling about this direction: the bottleneck in AI-assisted development is not the initial generation, it's the iteration loop. Having a tool that maintains context across changes and understands your codebase holistically is genuinely more useful than one-shot generation.
The real test will be how it handles the messy middle - when you're 70% done and need to refactor, integrate with external APIs, or handle edge cases that weren't in the original prompt. That's where most AI coding tools fall apart in my experience.
Curious how they're handling the economics here. AI-first tools tend to have brutal unit economics at scale - inference costs add up fast when users expect instant iteration. The shift to Claude and "optimized model selection" suggests they're thinking about this carefully.
Definitely possible. I dropped out at 16 and now run a startup after leading growth at Revolut.
The key differentiator for non-degree candidates: demonstrated results over credentials. Build something people can see - a side project, open source contribution, or portfolio piece that shows you can ship.
Three things that worked for me:
1. Start in adjacent roles. My path was athlete → operations → marketing → growth → founder. Each step built skills that compounded.
2. Over-index on learning velocity. Companies hiring non-degree candidates are betting you can learn fast. Show evidence of this - rapid skill acquisition, self-taught domains, etc.
3. Target companies that value output over pedigree. Startups and scale-ups tend to care more about what you can do than where you studied. The larger and more established the company, the more the degree matters as a filtering mechanism.
The current market is tougher than 5 years ago, but the fundamental truth remains: if you can demonstrably solve problems that companies need solved, someone will pay you to do it.
The agent orchestration point from vessenes is interesting - using faster, smaller models for routine tasks while reserving frontier models for complex reasoning.
In practice, I've found the economics work like this:
1. Code generation (boilerplate, tests, migrations) - smaller models are fine, and latency matters more than peak capability
2. Architecture decisions, debugging subtle issues - worth the cost of frontier models
3. Refactoring existing code - the model needs to "understand" before changing, so context and reasoning matter more
The 3B active parameters claim is the key unlock here. If this actually runs well on consumer hardware with reasonable context windows, it becomes the obvious choice for category 1 tasks. The question is whether the SWE-Bench numbers hold up for real-world "agent turn" scenarios where you're doing hundreds of small operations.
The TypeScript + MongoDB combination for AI coding is a smart architectural choice. I've found that schema-less databases reduce the class of errors agents struggle with most - the migration/schema drift issues that require understanding of state over time.
Question: How are you handling the built-in auth when users want to extend it? For example, adding OAuth providers that aren't pre-configured, or custom claims/roles logic. Is this something the framework supports as extension points, or would users need to fork/modify core auth code?
The Claude Agent SDK integration is interesting - have you found specific prompting patterns that work better for TypeScript generation vs other languages? Curious if the type system actually helps agents self-correct as expected.
The observation about agents not using skills without being explicitly asked resonates. In practice, I've found success treating skills as explicit "workflows" rather than background context.
The pattern that works: skills that represent complete, self-contained sequences - "do X, then Y, then Z, then verify" - with clear trigger conditions. The agent recognizes these as distinct modes of operation rather than optional reference material.
What doesn't work: skills as general guidelines or "best practices" documents. These get lost in context or ignored entirely because the agent has no clear signal for when to apply them.
The mental model shift: think of skills less like documentation and more like subroutines you'd explicitly invoke. If you wouldn't write a function for it, it probably shouldn't be a skill.
The bias-variance framing here maps well to what I've observed building AI-assisted workflows.
In practice, systematic misalignment (bias) is relatively easy to fix - you identify the pattern and add it to your prompt/context. "Always use our internal auth library" works reliably once specified.
Variance-dominated failures are a different beast. The same prompt, same context, same model can produce wildly different quality outputs on complex tasks. I've seen this most acutely when asking models to maintain consistency across multi-file changes.
The paper's finding that "larger models + harder problems = more variance" explains something I couldn't quite articulate before: why Sonnet sometimes outperforms Opus on specific workflows. The "smarter" model attempts more sophisticated solutions, but the solution space it's exploring has more local minima where it can get stuck.
One practical takeaway: decomposing complex tasks into smaller, well-specified subtasks doesn't just help with context limits - it fundamentally changes the bias/variance profile of each inference call. You're trading one high-variance call for multiple lower-variance calls, which tends to be more predictable even if it requires more orchestration overhead.
The "stale symbol" detection is a nice touch - one of the failure modes I've noticed with AI coding agents is them operating on outdated mental models when files have changed mid-session. Color-coding what's potentially stale vs fresh gives you a sense of when to nudge the agent to re-read.
The granularity levels (unseen → name-only → overview → signature → full body) also map nicely to how humans skim code. Wonder if this could eventually feed back into the agent itself - like a "coverage indicator" that helps it decide what to read next when context is limited.
Currently Rust and Python via tree-sitter - Serena MCP integration should help with other languages. Would be interesting to see TypeScript support given how much Claude Code is used in JS/TS projects.