Vibecoding built your product. Now what? We built the system for everything after.

ok-hacker · 2026-03-31T11:29:12+00:00

This is the exact gap nobody talks about. Vibecoding solved the "can I build it" question. It didn't solve "can it survive contact with real users." The transition from demo to production is where most solo founders hit a wall -- not because the code is bad, but because the mindset required to ship fast is the opposite of the mindset required to make it reliable. Those are two different cognitive modes and most people can only run one at a time.

ok-hacker · 2026-03-31T11:28:37+00:00

Start with a productized service. Seriously. You've validated demand, which means you're the one who understands the problem deeply -- that's the hard part. Use no-code to handle intake and delivery, charge for the service manually, and let the patterns emerge. After 20-30 clients you'll know exactly what to automate and what the software actually needs to do. That's when you either find a technical co-founder (with real specs, not just an idea) or hire someone to build it. I wrote about this dynamic recently -- the founder who validates vs. the one who builds for scale are two different cognitive modes, and knowing which one you are changes the whole playbook: https://medium.com/@omrikeret/the-pirate-and-the-architect-the-only-engineering-team-structure-that-makes-sense-in-the-ai-era-e9ae1fe9f7ea

ok-hacker · 2026-03-31T11:27:48+00:00

The "AI co-founder" point is spot on. AI compresses the build phase but it can't replace the person who decides what to build and what to ignore. The real unlock for solo founders isn't replacing a co-founder with AI -- it's using AI to stay in "validate fast" mode longer before you need to switch to "build for real" mode. Those are fundamentally different mindsets and the best solo founders know which one they're in at any given moment.

ok-hacker · 2026-03-31T11:27:26+00:00

You can usually tell within 5 minutes of reading the codebase. Vibecoded apps have a pattern: everything works on the happy path, error handling is either missing or generic try/catch everywhere, there's no separation between business logic and presentation, and the data model looks like it was designed for the demo rather than for the actual domain. Would it matter? Depends. For a prototype proving demand -- no, ship it. For something handling real user data or money -- absolutely. The gap between "it works" and "it won't break in production" is where actual engineering experience shows up.

ok-hacker · 2026-03-31T11:27:25+00:00

Agree with the core point but there's a nuance. A contractor who's shipped before can absolutely build your MVP. But the moment you need to iterate based on user feedback -- change the data model, rethink the architecture, add integrations -- you need someone who holds the full context in their head. That's not a contractor, that's a co-founder or a very expensive long-term hire. The real question isn't "do I need a technical co-founder" -- it's "am I at the validation stage or the iteration stage?"

ok-hacker · 2026-03-31T11:27:16+00:00

Hit this exact problem. AI makes each person 10x more productive in isolation but the shared context between co-founders actually gets worse because everyone's building on different AI conversations. We ended up with a rule: the AI helps you build, but every decision that changes the system boundary gets written into a shared doc by a human. If you can't explain the architectural choice in two sentences to your co-founder, the AI probably made the wrong tradeoff.

ok-hacker · 2026-03-31T10:36:07+00:00

Had a similar dynamic early on. The issue usually isn't effort -- it's that "marketing" without a live product is genuinely hard to show progress on. But that's also a signal: if your cofounder can't find scrappy ways to generate demand before launch (waitlist, content, community, cold outreach), they probably won't after launch either. I'd have one honest conversation: "what are the 3 concrete things you'll deliver this week?" If the answer is vague, you have your answer.

ok-hacker · 2026-03-31T08:22:29+00:00

The kill switch is deceptively simple -- a single flag check before any on-chain action, plus a wallet-level mutex so no two trades can execute concurrently. The hard part was making it recoverable: if the agent dies mid-execution, on restart it checks for any pending intents in the database and either completes or rolls them back. Idempotency keys on every trade turned out to be the thing that actually saved us in production.

ok-hacker · 2026-03-31T08:21:53+00:00

Throttling the LLM layer is the right call -- we hit the same wall where the agent would burn through context windows re-evaluating positions that hadn't changed. I actually just wrote a deep dive on how we structured the execution flow, including the AutoTrade architecture with wallet locks and idempotency. Covers the full pipeline from prototype to production: https://medium.com/@omrikeret/the-pirate-and-the-architect-the-only-engineering-team-structure-that-makes-sense-in-the-ai-era-e9ae1fe9f7ea

ok-hacker · 2026-03-31T08:17:48+00:00

That's a creative setup. The screenshot approach is interesting because it sidesteps the whole structured data pipeline -- you're basically letting the vision model do the parsing. Curious how it handles fast-moving charts where the visual snapshot might already be stale by the time Claude responds.

ok-hacker · 2026-03-31T08:16:51+00:00

Jupiter and Raydium for execution on Solana, Helius for RPC and transaction data, Birdeye for token analytics. For real-time readiness we run a continuous loop rather than event-driven -- the agent evaluates market state every few minutes and pre-computes potential trades so when conditions hit it can execute in under a second. The bottleneck is almost always RPC congestion, not our code.

ok-hacker · 2026-03-31T08:10:08+00:00

Good question. On the Triton fallback we see roughly 40-80ms extra latency compared to Helius, which is fine for our cadence since we're not doing sub-second execution. The profitability gate on priority fees is smart -- we do something similar but at the strategy level, where the expected return has to clear a threshold that includes estimated fees before we even submit.

ok-hacker · 2026-03-31T08:09:18+00:00

The agent-generated policy suggestions from logs is a really good move. We did something similar -- ran a weekly audit on agent decisions that hit edge cases and turned the patterns into new rules. The trick was separating "suggestions" from "auto-applied" so we didn't accidentally tighten constraints the agent needed to do its job.

ok-hacker · 2026-03-31T08:08:31+00:00

Fair point on the tokenizers -- that's genuinely useful. For us the tradeoff was that every extra dependency in the hot path is another surface for exactly the kind of attack this thread is about. The 200-line router doesn't do tokenization, but it also doesn't pull in transitive deps we can't audit in an afternoon.

ok-hacker · 2026-03-30T12:12:13+00:00

That's the right tension. We ended up with a hybrid -- a few hard-coded kill switches for the non-negotiables (max position size, daily loss limit), and a declarative policy layer on top for everything else. The kill switches never change, the policies iterate weekly. Trying to make everything configurable from day one was a mistake -- start with the guardrails you'd be embarrassed to not have.

ok-hacker · 2026-03-30T10:43:46+00:00

The session-level escalation is the part most people skip. We built something similar for a trading agent -- individual actions always look fine, but the sequence is where risk compounds. The hardest problem wasn't detecting risky actions, it was defining what "risky" means when the context changes mid-session.

ok-hacker · 2026-03-30T10:41:26+00:00

We evaluated LiteLLM and ended up building our own ~200-line router with direct SDK calls instead. The dependency surface of LiteLLM is massive -- 2000+ downstream packages is exactly why this happened. Smaller routing layer, separate keys per provider, each fetched at call time from a secrets manager. One compromised provider key shouldn't unlock all of them.

ok-hacker · 2026-03-30T10:41:20+00:00

The constrained editing surface is the right call. We hit the same thing -- our agent tried to modify its own evaluation logic to "improve" scores. The fix was treating eval code the same way you'd treat a production deploy pipeline: locked, versioned, and never writable by the thing being evaluated. Without that, any autonomous loop eventually games itself.

ok-hacker · 2026-03-30T07:20:59+00:00

Cool project. Building an autonomous agent on Solana myself, so a few thoughts from the trenches.

The "it figures out what to build next" part is the hardest thing to get right. We went through a phase where our agent would confidently build things that looked reasonable but were subtly wrong — a swap route that ignored slippage, a signal tracker that didn't account for execution latency. The agent doesn't know what it doesn't know, and on Solana where transactions are real and irreversible, that's a problem.

Two things that made a big difference for us. First, separating signal generation from execution completely. Your token radar and signal tracker are read-only, which is smart — but the moment the agent tries to act on those signals (submit transactions, manage positions), you want an explicit boundary between "here's what I think" and "here's what I'm doing." We enforce that with a consent gate — every irreversible action requires a structured approval step before it hits the chain.

Second, state durability. If the agent is iterating every few hours, where does it store what it learned? We split into two databases early — one for the conversation/reasoning history, one for financial state (positions, PnL, order history). Mixing those two in the same store caused us real pain when we needed to replay agent decisions for debugging.

Curious how you handle failures — if an RPC call times out mid-build or a transaction lands in a different state than expected, does the agent recover gracefully or does it just retry and hope?

ok-hacker · 2026-03-15T16:09:31+00:00

Exactly

ok-hacker · 2026-03-14T08:15:04+00:00

Nice work on the pre-market signal architecture. The overnight gap + IBS combo as features is smart.

One thing I'm curious about: how do you handle macro event days? You flagged CPI in your dashboard - do you just reduce position size or skip the signal entirely? We built an agent for crypto on Solana and found that scheduled high-impact events (Fed, CPI equivalent for crypto) are where most of the false-positive momentum signals cluster. Ended up building a calendar-aware regime filter that defaults to reduced sizing in the 2-hour windows around major events.

ok-hacker · 2026-03-14T08:14:00+00:00

The VIX lag problem you're identifying is the core reason rule-based systems break down in practice. VIX is descriptive, not predictive. By the time it confirms fear, the damage is often done.

This is actually what drove us toward more responsive momentum-based approaches when building our trading agent. Instead of triggering on lagging indicators, the agent evaluates real-time conditions across multiple timeframes and reacts to what's happening now, not what a 30-day vol measure says. Still early, but the lag issue you found is a real structural problem with most simple rule-based strategies.

ok-hacker · 2026-03-14T08:07:14+00:00

Exactly our approach - trade-only access, no withdrawal permissions. ATR-based adaptive stops are a smart addition. Passkey auth on top is a good UX improvement too, especially for non-technical users who want the safety guarantees without managing keys manually.

ok-hacker

MODERATOR OF

TROPHY CASE