๐Ÿค” What do you consider โ€œvibe codingโ€?

Originally published on LinkedIn

๐Ÿค” ๐—ช๐—ต๐—ฎ๐˜ ๐—ฑ๐—ผ ๐˜†๐—ผ๐˜‚ ๐—ฐ๐—ผ๐—ป๐˜€๐—ถ๐—ฑ๐—ฒ๐—ฟ โ€œ๐˜ƒ๐—ถ๐—ฏ๐—ฒ ๐—ฐ๐—ผ๐—ฑ๐—ถ๐—ป๐—ดโ€?

โ€œVibe codingโ€ when originally coined was meant to mean non-technical people building software with AI, with little concern or no care about code, architecture, implementation details, or code quality.

That definition for me is too narrow and creates an unnecessary divide between โ€œtechnicalโ€ and โ€œnon-technicalโ€ people and can hide problems with AI.

Engineers often criticise vibe coding because the generated code can be fragile or unmaintainable, I'd argue engineers can generate as bad.

If an engineer is throwing prompts at AI without structure, review, or directionโ€ฆ is that really different?

To me, the distinction isnโ€™t technical vs non-technical.

๐—œ๐˜โ€™๐˜€ ๐—ฝ๐—น๐—ฎ๐—ป๐—ป๐—ถ๐—ป๐—ด.

My definition of vibe coding is:

โžก๏ธ ๐—š๐—ฒ๐—ป๐—ฒ๐—ฟ๐—ฎ๐˜๐—ถ๐—ป๐—ด ๐—ฐ๐—ผ๐—ฑ๐—ฒ ๐˜„๐—ถ๐˜๐—ต ๐—ถ๐—ป๐˜๐—ฒ๐—ป๐˜, ๐˜„๐—ถ๐˜๐—ต๐—ผ๐˜‚๐˜ ๐—ฎ ๐—ฐ๐—น๐—ฒ๐—ฎ๐—ฟ ๐—ฝ๐—น๐—ฎ๐—ป ๐—ผ๐—ณ ๐—ต๐—ผ๐˜„ ๐˜๐—ผ ๐—ฎ๐—ฐ๐—ต๐—ถ๐—ฒ๐˜ƒ๐—ฒ ๐—ถ๐˜.

That intent can still be detailed: โ€ข Features โ€ข User experience โ€ข Performance goals โ€ข Architecture constraints โ€ข Testing requirements โ€ข Scalability concerns

But the implementation path is discovered dynamically through AI interaction rather than fully designed upfront. I enjoy it and use this mode as well as planned and spec based approaches, and I'm an engineer, but I would say I "vibe coded" it as followed my engineering instincts more than a plan.

Thatโ€™s why I think both non-engineers and experienced engineers can absolutely be vibe coding.

A founder might say: ๐Ÿ’ฌ โ€œI want a dashboard that does X, Y, and Z.โ€

An engineer might say: ๐Ÿ’ฌ โ€œRefactor this area, improve test coverage, separate concerns, and reduce technical debt.โ€

In both cases, the intent is clear.

In both cases getting there is figured out by AI, you start at a prompt, not design, the danger of the output drifting through random iteration is exactly the same.

๐—ง๐—ต๐—ฎ๐˜โ€™๐˜€ ๐˜„๐—ต๐˜† ๐˜ƒ๐—ถ๐—ฏ๐—ฒ ๐—ฐ๐—ผ๐—ฑ๐—ถ๐—ป๐—ด ๐—ฟ๐—ฒ๐—พ๐˜‚๐—ถ๐—ฟ๐—ฒ๐˜€ ๐—ฎ ๐—ฑ๐—ถ๐—ณ๐—ณ๐—ฒ๐—ฟ๐—ฒ๐—ป๐˜ ๐—บ๐—ถ๐—ป๐—ฑ๐˜€๐—ฒ๐˜.

You need checkpoints. You need to review constantly. You need to know when to revert code, recognise dead ends, and stop chasing ideas that only appeared during iteration.

Because AI is excellent at maintaining momentum.

โš ๏ธ That does not mean it is moving in the right direction. As an architect I use direction alot and I know that those decisons are backed by a longer term plan and goal.

My biggest concern is that people assume: โ€œAn engineer produced it, so it must be engineered properly.โ€

Thatโ€™s simply not true.

Weโ€™re already seeing huge amounts of poor-quality AI-generated code entering production systems, from engineers and non-engineers alike, because of weak planning, weak review, and too much trust in iterative AI output.

So it's critical to know when you are winging it and "vibing" especially as an engineer.

๐—ช๐—ต๐—ฎ๐˜ ๐—ฑ๐—ผ ๐˜†๐—ผ๐˜‚ ๐—ฐ๐—ผ๐—ป๐˜€๐—ถ๐—ฑ๐—ฒ๐—ฟ ๐˜ƒ๐—ถ๐—ฏ๐—ฒ ๐—ฐ๐—ผ๐—ฑ๐—ถ๐—ป๐—ด?

#AI #SoftwareEngineering #VibeCoding #ArtificialIntelligence #Programming #TechLeadership #Architecture #Developer #Coding #TechDiscussion