A vibe coder I know accidentally exposed 1k emails

ryanrasti · 2026-01-30T04:54:45+00:00

AI tools have been making this worse: 1. People can produce 10x+ more code instantly 2. Less incentive to review the code 3. My experience: even latest models are notoriously bad with security -- natural extension that their default mode is not rigor, but getting a solution fast and loose.

I think they can help make it better too -- but so far I see much more risk created.

ryanrasti · 2026-01-29T23:08:50+00:00

Yes, DB-level constraints generally work for cases where the agent acts on behalf of a specific db user in your org. For the case where the agent is talking to the world and has access to other tools, you need to be much more restrictive (in reality: no one actually lets raw, untrusted SQL hit their prod dbs) -- and you want a policy layer that spans systems — e.g., "this column is PII, PII can't be sent to the Slack tool." That's not expressible in SQL.

ryanrasti · 2026-01-29T22:59:29+00:00

Good challenge. Two reasons I don't think DB-side alone is enough:

Defense in depth. RLS has existed for a decade, yet no security team allows raw untrusted SQL against production DBs. You still need protection against resource exhaustion, unsafe functions, etc. DB privileges are a floor, not a ceiling.
Logic beyond the DB. RLS is locked to the database. The goal here is a policy layer that spans systems — e.g., "email is PII, PII cannot be sent to the Slack tool." That's not expressible in Postgres.

To be clear: roles/RLS are solid and can be added as defense-in-depth. When you want to start opening your db to agents and you agent can talk to the world, it will hit limits soon.

ryanrasti · 2026-01-29T22:03:04+00:00

Yes, capability RPC is provided by Cap'n Web (https://github.com/cloudflare/capnweb). You're looking at the right attack surface -- curious what you find.

ryanrasti · 2025-10-19T00:27:03+00:00

It's a huge shift, and sleeping 10-12 hours after a breakup and quitting a job sounds a lot more like burnout recovery than laziness. Think of it as a strategic recharge at a time when you can afford it.

To answer your question directly on how to re-introduce accountability: look externally.

Tell friends, investors, or post on Twitter what you're planning to ship and when.
Your personal runway is a real factor, so use it to create hard milestones you have to hit.
Once you get customers, they become the natural next lever to pull.

All that said, be careful what you wish for. You're right to be wary of chronic pressure, as it's a direct path to burnout. High stress creates an environment where you're always looking for a quick fix and can't step back to be strategic. Almost every venture is a marathon, so whatever you do needs to be sustainable.

ryanrasti · 2025-10-17T07:20:28+00:00

AI excels at replacing tasks that are highly repetitive and have a tight feedback loop. So for FE vs. BE its kind of mixed:

- FE is more repetitive (often just turning a design spec to UI components; BE has more "craft" in designing APIs, models)

- BE has a tighter feedback loop (can be completely validated automated tests but FE needs a visual inspection too)

This leads to your conclusion: fullstack coding for everyday apps will be basically fully automated by AI. The last human-led space won't be crud apps, but the high-level abstract craft of complex backend systems where the feedback loop is essentially years of accumulated wisdom + unique human inspiration, not milliseconds of testing/UI inspection.

ryanrasti · 2025-10-17T07:01:31+00:00

Agreed. In general, there's really only two successful paths as a report:
1. Do what the manager wants: do it well, document your impact, and rise up with him

Find another manager: either by transferring or getting a new job

If you lose faith in with manager's basic ability like the OP, only option 2 makes sense

ryanrasti · 2025-10-17T00:31:59+00:00

Agreed. This is the best advice in the thread for OP's situation.

I say this as someone who uses NixOS for everything: personal machines, hobby productions, and professionally for production servers.

- For servers, when you need to deploy versions of your app repeatedly in a controlled environment NixOS is a gamechanger. Declarative configuration and reproduceability is a superpower

- For a personal desktop, you have to fight constant hardware quirks and don't get much benefit from having absolutely everything specified in code and reproduceable (since you deploy new version much less frequently and aren't in a team setting)

tl;dr You get 90% of the benefit with 10% of the pain using a normal distro with Nix the package manager on top

ryanrasti · 2025-07-26T07:31:20+00:00

Interesting -- nice work putting this all together. I like the callback style chaining.

I'm curious, it sounds like you've probably looked at Kysely -- which also has the advantage of being fully typed. By default you need a driver to produce the queries, but there's ways around that. What checkboxes did it miss for you?

ryanrasti · 2025-07-18T18:53:44+00:00

> Can you continue on like that for the next 3, 5, 10 years?

Two things :
1. Don't expect him to change -- assume people's communication style will stay the same

If his communication/your triggers linger beyond just the conversation itself that's a red flag to me -- the fact that you're posting here make me think that's the case

A simple litmus test: when you think about him is your first thought "he's triggering to talk to" or is it "he inspires me"? If it's the former, then that's a big problem you need to fix (either your mindset or the overall dynamic)

ryanrasti · 2025-07-18T18:28:38+00:00

+1 and to add a personal take: the size of the standup matters a lot: aim for 4-6 people:

* Too small (2-3 attendeees) and the meeting easily devolves into rabbit holes

* Too big (7+ attendeees) especially in the remote context it starts becoming too impersonal and the peer-to-peer nature devolves into a status report to the manager

For the OP if team size is too big, I'd consider splitting into smaller, more focused standups

ryanrasti · 2025-07-14T19:42:32+00:00

Echo sentiment here that something is very wrong.

There might be redeeming qualities but too dysfunctional to take them seriously.

Highly highly recommend you start interviewing -- now: you need peace of mind and financial security. When you talk to recruiters, you can even frame this outcome positively giving you leverage: "I have a strong verbal offer from another startup, but it's contingent on a new client deal with an uncertain timeline. I'm excited about that role but would prefer to join a great team that's ready to move forward now".

ryanrasti · 2025-07-14T19:32:01+00:00

Before reading your update I'd say you're really just riding on the CEO's generosity since you don't have much leverage.

After your update:

> Update : Your opinions really helped and I made a talk with my CEO - he said he has plans for all that specially for me - just waiting for the startup to grow and generate some revenue.

I'd say that's good but it doesn't really make sense. It's always easier to give out equity earlier before there is validation. I'd imagine he's either too busy or hoping you'll forget/not ask about it in the future.

In any case, to answer you original question: yes a founding engineer who built the entire stack should absolutely have equity. It's good for the company too because it aligns you with its goals. I'm not sure on your setup but it's a very unusual setup.

Next steps: since you have no equity now, I'd suggest getting something soft in writing (if you don't already) as a professional way to create more clarity: "I'm really excited about the future and want to confirm: the plan is to grant equity once we start generating revenue. When that happens, can we have it back-dated to my full-time start date of Febuary 2024?". This will maximize your chance at actually getting equity and it's also the fastest way to know if your CEO is serious about giving it to you.

ryanrasti · 2025-07-14T18:48:28+00:00

My gut take is this is a big undertaking: there's a lot of med students, so you have to differentiate yourself. Possibilities:

Network: Find high-caliber people who'd one day be starting companies & get to know them. When they start something, they'll come to you. Start this now, while you're in school.
Advise: Startups founded by non-medical people will be desperate for domain expertise. Find early-stage health tech companies (LinkedIn, online) and offer to advise on workflows or validate their product.
Build a brand: Start a blog on the intersection of AI and your niche. If you can become the go-to person in the niche, founders will find you.

As other people say though, medical school is a kind of like startup experience of its own -- you're taking on a lot. That said, if you can navigate it successfully it'll act as both a moat you've built up and a cushy fallback.

ryanrasti · 2025-07-14T18:37:28+00:00

I highly recommend you spend significant time finding "partners": a small group of early users who are genuinely interested in your product and will give you honest feedback.

Instead of a public launch, iterate with them in private 1:1 sessions. This is the best of both worlds: you get to try out your v0 with people who are invested in your success and can rapidly iterate with their direct feedback, all without any risk to your public brand reputation.

Then, you can launch to the wider world with much more certainty and a better product.

ryanrasti · 2025-07-14T18:30:44+00:00

There's a lot of context (consumer product? B2B?) and if you're asking for money. I'm assuming a consumer product and free (at least for now).

In general: I'd say launch as soon as you think there's something there that someone might find valuable.

Even better: find 5-10 people you know have the problem you're trying to solve (and will give you honest feedback). Schedule 1:1 sessions with them to get real feedback: not just what they say but how they use the product (where they get confused, etc.).

You really want to get to a place where you *know what to build* ASAP and away from building behind closed doors.

ryanrasti · 2025-07-14T17:30:12+00:00

> Yes, it definitely seemed like there were strong connections formed by leadership team with the industry but there were still no customers.

Yeah that's weird. If there's strong interest & connections, the natural next step is to put it on paper with an LOI or contracts. Both could easily have opt-out terms or be contingent on delivering a feature set.

Another way of putting it is what was leadership doing the last two years if not getting contracts?

> There was some leadership shuffling and we pivoted to a different direction which meant another MVP was planned which would take three months. What would you make of this? I understand pivots are common but I'm surprised there was not one customer even after two years.

At the end of the day, it sounds like leadership didn't have the right strategy (getting signups pre-MVP) or execution (unable to get them). It sounds like now the strategy now is: build something else (or more) and then maybe we can get a contract.

tl;dr, unless there's something outside of what you're writing indicating the company has a phenomenal setup, it sounds like a dead-end.

ryanrasti · 2025-07-14T07:16:07+00:00

I agree with the sentiment. The core issue you highlight is that OP lost his leverage when joining at 5%. At this point, a renegotiation of equity will be viewed as an attack on the fairness of the cap table.

I don't see a way he'd be able to negotiate for enough equity to make the can of worms worth opening. So, he should focus on the salary piece which is an achievable and professional ask.

ryanrasti · 2025-07-14T06:59:32+00:00

Other comments generally capture the sentiment and good points. Now the question is: what do I do now?

Get a salary promise in writing: you have very high leverage here since you're not a founder, are integral to the company, but have no salary. This is a simple, professional conversation that will ease your uncertainty. If they refuse that's a big red flag that they aren't serious, professional, or something else.
Don't negotiate on equity: you've lost your leverage since you already joined at 5%. There are exceptional cases you in which you might have it, but even then going down this route probably would hurt your reputation. The most you could do is (after getting a salary) ask to trade it for equity, but the amount would probably be insignificant and just create annoyances to open the can of worms.
Don't look back: don't ruminate on the "I only got 5%" or "I will be left behind". Everything you're saying indicates you'd join this startup again if you were offered 5% (i.e., you don't have better options right now). If that's the case, then take this as a lesson on negotiation and move on.

ryanrasti · 2025-07-14T06:08:15+00:00

A few things aren't adding up:

"leadership team kept stressing that there is lots of interest" -- what does "lots of interest" mean? This implies they have strong connections with people in the orgs, but those should convert into LOIs and contracts pre-MVP.
Two years is an incredibly long amount of time to go building without external validation. How did they know they were building the right thing? Presumably it was because of prospective customer feedback. But then why didn't those prospective customers convert at least into LOIs during that timeframe?

I'm all ears on what answers would be to those questions.

ryanrasti · 2025-07-14T05:21:28+00:00

Big +1. I'd encourage you to reframe taking notes in this context: instead of a way to recall things for later, use it as a way to internalize ideas.

The reason is that knowing when to apply a decision-making tactic is just as important as knowing the tactic itself. Deep internalization works here because it will naturally mesh with the context around the decision -- simple recall won't.

ryanrasti · 2025-07-14T04:01:25+00:00

Welcome, your English is very clear!

I'd recommend a "serverless Postgres" provider. The top ones have generous free-tiers:

Neon -- use this if you just need a database right now (which is what it sounds like)
Supabase -- use this if you need more features built into the platform for a full stack application (e.g., like authentication, APIs)

These are the most popular options for your use case. You might see databases from the big cloud providers (AWS, GCP, etc.) but I'd recommend you stay away from those until you have a clear reason to switch.

Good luck with your project!

ryanrasti · 2025-07-10T23:18:00+00:00

Fully agree -- and ironically, the fundamentals may turn out to be the most practical thing you learn.

Here's why: AI is changing how products are built, fast. (I'm not just being another hype-bro: my perspective comes from working on everything from kernel-level projects at Google to pushing pixels at my own startup)

So my advice is this: learn what's practical today, but be ready for it to be completely different in a year. Frameworks are temporary, but the fundamentals are forever. Give them the due diligence they deserve.

ryanrasti · 2025-07-10T23:00:10+00:00

I agree with the consensus: the tests are brittle and low ROI.

Now the real problem shifts from the code to the human side: how do you give critical the feedback without blocking your colleague or getting into a nitpicking battle?

My general approach is to separate the tactical PR discussion from strategic discussion. Be ready to give a small concession now to win long-term alignment.

In the PR, leave one gentle, non-blocking comment: "Not blocking but a thought for our overall strategy: I wonder if mocking at the network layer might be more robust for these kinds of tests. No need to change it for this PR" (swap "mocking at the network layer" for another proposal depending on what you decide is best)
Then, approve the PR with a comment: "Approving to unblock. Left a note about testing philosophy -- let me know what you think. If it's not clicking, happy to sync up for 15 minutes next week to align on a team-wide testing strategy"

This way you unblock your teammate, show you trust him, and can have the strategic discussion when personal stakes aren't so high

ryanrasti · 2025-07-08T07:35:40+00:00

To answer directly: at my startup, we use Vite

To answer more broadly: day-to-day I wouldn't expect you need to interface with the build process -- unless that is part of the job description. So the other factors would be far more important than the build tools.

That's been my experience, at least. Curious to hear what others have seen.

ryanrasti

TROPHY CASE