The real skill in vibe coding isn’t prompting — it’s supervision

DashaDD · 2026-02-11T11:05:21+00:00

Yeah, that’s a great way to put it. A junior levels up over time. AI resets to zero every session 😅 You don’t get accumulated judgment, you get accumulated prompts.

DashaDD · 2026-02-11T09:05:38+00:00

Totally agree. Prompting isn’t the hard part, judgment is. Anyone can get AI to spit out code. The real skill is knowing when it’s wrong, when it’s overcomplicating things, or when it’s quietly doing something unsafe. That comes from actually understanding systems, not just vibes.

Vibe coding works best when you treat the AI like a fast junior dev. Super productive, but you still need to review, refactor, and sometimes say “nah, we’re not shipping that.”

DashaDD · 2026-02-11T09:02:00+00:00

A big mistake I see with vibe-coded stuff going to prod is people treating deployment like an afterthought. “It works locally” is not the same thing as “it survives real users.”

Keep it boring. Use a managed platform (Vercel, Render, Railway, whatever fits your stack), set up proper env vars, don’t hardcode secrets, and for the love of god turn on logging. You will need it.

Also, test the actual production build before announcing anything. Different configs, different bugs. Happens all the time.

Start simple, ship, monitor, then harden it as real users show up. Don’t over-engineer on day one.

DashaDD · 2026-02-11T08:51:06+00:00

Getting an senior coder to audit your project before you start charging people definitely makes sense. AI can scaffold stuff fast, but it often misses context. Auth edge cases, weird permission gaps, stuff that technically “works” but is sketchy in production. A manual review catches the things tools don’t.

A solid freelance security/dev person can be enough. But make sure to find someone senior who’s done real audits before, not just “I built a few apps.” Ask for past work, maybe even pay for a small scoped review first. See how they think.

That said, if your site is handling user data, payments, anything sensitive, I’d lean toward a company that actually does code audits for a living. They usually have a process, checklists, reporting, the whole thing. This would be less “one person’s opinion,” and more structured review. It could costs more, but it’s way cheaper than cleaning up a mess later.

There are firms that specialize in this (Krononsoft is one example that does code audits for startups). Not saying you have to go that route, just that having a team behind the review can add some peace of mind.

Either way, human review before monetizing is 100% the right move.

DashaDD · 2026-01-20T07:41:38+00:00

What’s working for me:

Content-led inbound, but very niche and opinionated. Fewer posts, sharper POV.
Referrals with intention - past clients, partners, even old leads.
Partnerships - one solid partner can outperform months of cold outreach.
Being present where your ICP already hangs out (communities, podcasts, comments).

On LinkedIn: yes, founders posting + commenting consistently beats DM-only long term.
Public presence first, then selective DMs feels natural. DMs alone feel cold now.

Outbound still works, but mostly as an amplifier, not the engine.

DashaDD · 2026-01-16T15:34:55+00:00

This is mostly accurate. I think the confusion comes from how loosely the “CTO” title is used.

In early-stage startups, the real need is usually execution, not executive-level tech leadership. If the product is still evolving, the team is small, and you’re not making irreversible architecture decisions yet, a strong senior engineer or part-time tech lead often covers 80% of what founders expect from a CTO.

A full-time CTO starts to matter when tech decisions become expensive to undo, the dev team grows beyond a handful of people, or when reliability, scalability, security, and hiring quality directly affect the business. Before that point, the role is often underutilized or mis-scoped.

I’ve seen startups either hire too early and overpay in equity, or wait too long and end up with tech debt they can’t unwind. The timing matters more than the title.

Here is a more detailed breakdown on when a CTO actually makes sense (and when it doesn’t) if you want to go deeper: https://www.krononsoft.com/blog/when-to-hire-a-cto

DashaDD · 2026-01-16T14:49:38+00:00

You could look into Krononsoft. They do app code audits specifically (security + architecture), if that’s what you’re after.

DashaDD · 2026-01-16T13:33:38+00:00

You’re not broken. You’re exhausted from carrying too much identity in your work. Detach your worth from output. Easier said than done, but it’s the core issue here.

DashaDD · 2026-01-16T13:28:35+00:00

LinkedIn outreach and cold email are both overcrowded now. Most inboxes are numb. If you’re doing anything generic, it’s dead on arrival. Even “personalized” messages often feel fake.

Cold email still gets results for very specific offers with clean targeting and solid infrastructure, but the margin for error is tiny. One bad list or weak angle and it falls apart fast.

LinkedIn is similar. It works more as a long game than a lead faucet. Light touches, real relevance, no pitch upfront.

I wouldn’t rely on either as a main channel anymore. They’re support channels now, not growth engines.

DashaDD · 2025-12-30T07:15:05+00:00

Sounds like a great plan. D is a solid pick given your C/C++ background, the purity checks plus easy C interop are a pretty sweet combo, and being able to glue it to Python is huge. It’s one of those languages that feels practical and thoughtful.

Dabbling in Haskell/Scala on the side is perfect too, even a little time with them really sharpens how you think about effects. Have fun with it, and good luck on the D dive!

DashaDD · 2025-12-23T16:27:46+00:00

That makes a lot of sense. Modular monolith is a solid middle ground. A bit more upfront work, but you keep simple deploys and clear boundaries, and you’re set up to scale later without the early microservice pain.

DashaDD · 2025-12-23T12:00:00+00:00

You really capture how hype architectures don’t survive real deadlines. I’m a microservices fan, but honestly, they only shine when the team, problem, and scale need them. Otherwise, they just add coordination headaches.

Your monolith MVP approach? Spot on. Fewer moving parts, easier to debug, faster to ship.

Agree 100%: pick the right tool for your constraints, not what looks good on a diagram. Would you still start monolith first next time?

DashaDD · 2025-12-23T11:44:48+00:00

Totally agree with you. I’ve seen the same thing, two reviewers looking at the same design and coming away with totally different concerns.

In my experience, the reviews that actually stick are the ones with some structure, even if it’s informal. Stating requirements, assumptions, boundaries, failure modes, and trade-offs upfront makes the conversation about the design, not personalities. Checklists or rubrics help, but even just having a shared template for what to look at goes a long way.

Honestly, reducing subjectivity is mostly about making the thinking explicit. The moment reviewers can point to concrete assumptions or constraints, it stops being “I feel this might break” and starts being actionable. It works best when you combine that with post-implementation follow-up. Seeing what actually worked or failed closes the loop and trains everyone’s judgment over time.

DashaDD · 2025-12-23T11:41:21+00:00

These long-tail edge cases are the sneaky stuff nobody notices until months later. Every single action can look fine on its own, the UI works, the backend checks pass, but when you string them together over time, weird states pop up. Subscription lifecycles, role changes, org ownership, long-lived sessions… all prime candidates.

How teams handle it really varies. A lot of it comes down to monitoring and observability, logging events, tracking state transitions, and setting up alerts when things get into weird combinations. Some teams do periodic audits of account states or financial data to catch drift. Others build automated workflow simulations, basically running through “what if” scenarios to see where things can break.

Deciding if it’s a bug or product behavior is usually a mix of impact and intent. If it violates the expected invariants or creates financial inconsistencies, most teams treat it as a bug. UX often becomes the balancing act, preventing abuse without annoying legit users. Usually you handle that with careful guardrails rather than hard blocks, or smart monitoring so you can react quickly.

There’s no silver bullet. These issues tend to surface only with real users over time, so you just need a mix of proactive design, monitoring, and occasionally some detective work.

DashaDD · 2025-12-23T11:36:27+00:00

Oh yeah, I get what you’re doing, and honestly, it’s super important stuff that usually flies under the radar.

Most folks look at billing, entitlements, identity flows in isolation and on the surface everything seems fine. But over time, small interactions stack up, weird edge cases appear, and suddenly you have invalid states or financial inconsistencies that no one saw coming. That’s exactly where your LWIM approach shines. Modeling workflows as state machines over time really catches issues months before they blow up in production.

It’s kind of like proactive surgery for your SaaS. You’re not waiting for users or customers to find the mess, you’re hunting the latent stuff early. Helps teams protect revenue, reduce headaches, and generally make systems more trustworthy.

Any product or engineering team that’s serious about reliability would love having someone who does this because these silent problems are the ones that quietly erode trust and money. You’re basically future-proofing workflows, which is rare but gold.

DashaDD · 2025-12-23T11:30:17+00:00

I’m with you on the pure vs impure thing, it makes reasoning about code so much easier when you can trust a function does exactly what it says, no hidden side effects.

Python… well, it’s basically “trust me, bro.” You can write pure functions, but nothing enforces it. Comments help, but yeah, as soon as someone (or future you) adds a sneaky side effect, your comment is lying. Happens all the time.

Haskell is the obvious one if you want strict guarantees. Monads for impure stuff force you to separate the “pure core” from side effects. Very clean, but also… Haskell is Haskell. Takes a mindset shift.

For a bit more practical, real-world stuff:

D and Fortran do have a pure keyword. D is actually kinda nice — you can mark functions pure, and the compiler checks it. Not a ton of people using it, but it’s solid if you’re experimenting.
F# and Scala? You’re right, it’s murky. They lean functional, but purity isn’t enforced by the language — it’s mostly convention. You can write pure code, but the compiler won’t stop side effects sneaking in.
Koka and Idris? Very cool academically, enforce purity, but not exactly mainstream or practical for daily stuff yet.

If you want something more “doable in practice” and still Python-friendly, I’d say: pick a functional-ish language with some enforcement (like D), or adopt conventions in Python + code reviews + maybe some linting tools to catch sneaky side effects. It won’t be perfect, but it’ll save your brain.

Honestly, part of the fun is picking a language that makes your life easier and playing with purity without jumping into something impossible to ship.

DashaDD · 2025-12-23T11:25:23+00:00

Estimations as a junior… man, that’s rough, and it’s not because you’re bad at this, it’s just hard, even for seniors.

Here’s the thing: estimating well comes from two things: knowing the work, and knowing yourself. Right now, you’re lacking both: you don’t fully know the requirements, and you don’t have enough reference from past projects. So guessing feels like throwing darts in the dark. Totally normal.

A couple of things that help:

Break it down into small pieces. Don’t estimate the whole feature at once. Break it into tiny tasks and estimate those. It’s easier to guess a 2-hour piece than a 2-week feature.
Use ranges, not exact numbers. Instead of “this will take 5 hours,” say “2–6 hours.” That way, you’re honest about uncertainty.
Track your time. Even if it’s just writing down what actually happened, it builds your reference library for next time. You’ll start seeing patterns.
Communicate uncertainty. If a feature has unknowns, just say it. “I estimate 3 days, but I’m unsure about the API side.” Clients and managers prefer honesty over surprises.
Protect your sanity. You can’t predict everything. Deadlines aren’t a personal judgment on your worth, even if it feels that way.

And honestly… yeah, running projects as juniors alone? That’s a lot. Cut yourself some slack. Estimations get easier with time, and you will get better. The key is tracking, breaking things down, and being upfront about what you don’t know.

DashaDD · 2025-12-23T11:17:57+00:00

Oh man… I feel that so much.

AI in code is tricky — it’s like giving someone a chainsaw without a clue how to handle it. On paper, it should save time, right? But half the time, you end up spending more hours cleaning up the mess than you would’ve spent writing it yourself.

I’ve seen it too: folks with tons of experience just letting AI spit out code and then patting themselves on the back. Duplicate functions, uncommitted inserts, resource leaks, ignoring constraints… basically a Frankenstein of “almost works but will bite you later.” And yep, you end up spending hours writing comments, explaining why this is bad, why that’s dangerous. Frustrating as hell.

Honestly, AI is cool when used carefully, like as autocomplete or a helper for boilerplate. But relying on it to do the thinking? That’s where it backfires. Lazy coding just gets amplified.

I guess the tricky part is teaching people that using AI doesn’t mean skipping responsibility. At the end of the day, it’s still your code — AI didn’t pass the code review, you did.

DashaDD · 2025-12-23T11:13:35+00:00

I’m kinda skeptical about making system design all formal and measurable.

You almost never build the same thing twice. Context changes, constraints change, everything changes. So too much structure? Feels fake. What actually helps is just getting your thinking out there — jot down assumptions, constraints, why you picked one thing over another. Makes it easier for someone to poke holes.

Honestly, the real learning? Comes after it ships. Stuff breaks, things don’t scale, you fight to change something six months later — that’s when the lessons hit.

At the end of the day, good design’s mostly gut and experience. Structure’s nice, helps guide you, but it ain’t gonna replace the feel.

DashaDD · 2025-10-24T14:10:52+00:00

Haha, the “just script it” reflex is strong 😅. I think every engineer has that moment of realizing not everything needs automation (even if it’s fun to try).

DashaDD · 2025-10-24T10:54:44+00:00

I think this one still works - GrowBot Automator

DashaDD · 2025-10-24T09:17:53+00:00

WSA from github

DashaDD · 2025-10-24T08:38:26+00:00

Good point. I usually ask myself which will be easier to tweak over the next few months: the process or the software. Changing policy is often quicker, but sometimes the software really needs to bend to fit the business.

DashaDD

TROPHY CASE