CIRCLE WITH A DOT

Three levels of AI in software development 🧠After my recent posts about vibecoding and devibecoding I want to zoom out a bit. I think there are three levels of using AI in software development — and they are really about risk.🟢 Level 1: passive AI usage. Autocomplete, code review, planning, answering coding questions, writing documentation. You stay in full control, AI just saves you time. Almost zero risk, immediate productivity gains.🟡 Level 2: vibecoding non-production code. Tests, internal tools, CI/CD scripts, prototypes. This is the sweet spot most teams underestimate. The upside is high but the blast radius is small — if a generated test is wrong it fails, if an internal tool has quirks nobody outside your team notices. Great place to learn what AI can and can't do. Level 3: vibecoding production code. This is where it gets real. By my definition from the earlier post: vibecoded code is code nobody on your team has fully understood. Shipping that to production is a conscious risk decision. The key insight: these aren't steps you walk through sequentially. It's a risk assessment. Level 1 and 2 are almost always worth it. Level 3 depends on your situation — a startup that needs an MVP in three months has a different equation than an enterprise with compliance requirements. And when level 3 code needs to grow up? That's where devibecoding comes in — turning code nobody fully grasps into code your team truly owns.Where does your team sit on this spectrum right now? #SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #RiskManagement

@radicalabacus Love the archaeology metaphor. And I think you nailed the core difference — legacy code has a story, vibecode doesn't. Digging through an old codebase you can always ask "why did they do this?" and find an answer. With vibecode that question leads nowhere.Which makes me wonder: is devibecoding even the right response in every case? Maybe your instinct is the pragmatic answer — treat vibecode as a disposable draft. Use it to understand the problem space, extract the spec, then write it properly from scratch.That might actually be the most efficient form of devibecoding — not saving the code but saving the knowledge.

@Blf_tpe Totally agree — the intent is real and the community should meet that with openness, not defense. The people coming in through vibecoding are potential long term contributors and supporters. Your mom donating to Debian is living proof of that.The YouTube tutorial idea is exactly right. The technical barrier to contributing is lower than ever thanks to AI. But nobody teaches you how to write a good commit message, how to read contributing guidelines, or when NOT to open a PR. That cultural onboarding is the real gap.Maybe that's actually a community project worth vibecoding — an interactive guide for first time open source contributors.