Devibecoding 🔧
-
Devibecoding
In my last post I defined vibecoded code as code nobody on your team has fully understood. But what happens when you take that code and make it yours?
I think we need a term for this: devibecoding.
Devibecoding is the process of taking code you don't fully grasp — whether AI generated or not — and systematically working through it until you truly own it. Understanding it, restructuring it, making it maintainable.🧠 This is not just code review. It's a mix of reverse engineering, refactoring and deep comprehension — without being able to ask the original author about their intent. Because there was no human author.
Someone in the replies to my last post described exactly this: putting in the effort to understand and reformat AI output until it becomes their code. That's devibecoding in practice.
And here is my take: this will become its own discipline. With its own tools, its own best practices, maybe its own specialists. Think tools that don't just lint but explain. That visualize where your understanding gaps are. Possibly even AI helping you understand AI code — ironic but inevitable.
The more vibecode exists in the world, the bigger the need for people who can devibecode it.What do you think — is this already part of your workflow? And what tooling would help you most?
#SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #Refactoring
-
R relay@relay.infosec.exchange shared this topic
-
Devibecoding
In my last post I defined vibecoded code as code nobody on your team has fully understood. But what happens when you take that code and make it yours?
I think we need a term for this: devibecoding.
Devibecoding is the process of taking code you don't fully grasp — whether AI generated or not — and systematically working through it until you truly own it. Understanding it, restructuring it, making it maintainable.🧠 This is not just code review. It's a mix of reverse engineering, refactoring and deep comprehension — without being able to ask the original author about their intent. Because there was no human author.
Someone in the replies to my last post described exactly this: putting in the effort to understand and reformat AI output until it becomes their code. That's devibecoding in practice. And here is my take: this will become its own discipline. With its own tools, its own best practices, maybe its own specialists. Think tools that don't just lint but explain. That visualize where your understanding gaps are. Possibly even AI helping you understand AI code — ironic but inevitable. The more vibecode exists in the world, the bigger the need for people who can devibecode it.What do you think — is this already part of your workflow? And what tooling would help you most?
#SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #Refactoring
@marcelschmall it's similar to taking over a legacy system I guess, but it feels very different. With an old battle tested codebase, no matter how gnarly, there's something there to respect and trust. A theory of the system, a culture, a story. I enjoy the work involved in understanding a real codebase, it's like archaeology. I do what I'm paid to do, but I'm not looking forward to devibecoding. I'd rather just see the spec and write a new one than try to understand the plausible looking code puree
-
@marcelschmall it's similar to taking over a legacy system I guess, but it feels very different. With an old battle tested codebase, no matter how gnarly, there's something there to respect and trust. A theory of the system, a culture, a story. I enjoy the work involved in understanding a real codebase, it's like archaeology. I do what I'm paid to do, but I'm not looking forward to devibecoding. I'd rather just see the spec and write a new one than try to understand the plausible looking code puree
@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.
