When Is 100% Vibe Coding OK ?

Recently, I lost a lot of time reviewing and would have lost even more implementing, what I can only describe as vibe-written specs.

Requirements that felt coherent while saying almost nothing concrete. The kind of document where every paragraph sounds reasonable until you scratch the surface a bit and realize the thing is not applicable in the existing ecosystem.

To be clear: I am not against vibe coding.

I use it myself all the time.

If I need:

• a one-off script,


• a throwaway visualization,


• a temporary parser,


• a document nobody else will maintain,

then speed matters more than rigor.

But maintenance changes the equation completely.

This weekend accidentally gave me a good example of where vibe coding actually shines. During my usual Saturday clean-up, I knocked over one of those wooden cube puzzles:

25 identical pentacubes that are supposed to fill a perfect 5×5×5 cube.

Specifically this one:

A planar pentacube of which there are 25 instances.

At first the challenge was not the algorithm. It was the representation or the domain specific language (DSL).

Even explaining the puzzle to ChatGPT took multiple iterations. We had to establish:

• coordinate conventions,


• slice notation,


• legal piece states,


• rotation semantics,


• and eventually a labeling system for pieces.

Once the model stabilized, the rest followed naturally:

• generate transformations,


• normalize orientations,


• recursively place pieces,


• backtrack on collision.

Classic brute force.

I fully expected to need serious optimization eventually:

• pruning,


• bitboards,


• placement precomputation,


• maybe even Algorithm X.

But modern hardware is absurdly efficient.

The naive recursive solver found solutions fast enough that optimization stopped being necessary and became optional engineering curiosity instead.

Somewhere in the middle of this, the project accidentally became a generic mono-pentacube solver.

computing unique orientations for default piece...

unique orientations: 24

solution found



z = 0

1 1 1 1 2 

3 1 4 2 2 

3 3 5 6 2 

3 7 8 9 2 

3 8 8 8 8 



z = 1

A B C D E 

A 4 4 4 4 

A A 5 6 6 

A 7 F 9 9 

G H H H H 



z = 2

I B C D E 

I I C D J 

I 5 5 6 J 

I 7 F 9 J 

G 7 F H J 



z = 3

B B C D E 

K K K K E 

L M 5 6 J 

G 7 F 9 N 

G O O O O 



z = 4

L B C D E 

L M K P N 

L M P P N 

L M F P N 

G M O P N 

Then I wanted visual output.

So we added OBJ/MTL export and grouped the generated geometry by piece so the solutions could be inspected directly in Blender.

At that point I left the chat entirely, opened Codex, cleaned the implementation up, packaged it properly, and turned it into something reusable for solving this entire family of problems.

Solution	Exploded View

Not bad for roughly two hours of vibe coding.

But I think the important part is this:

My attempt only worked because I already knew the problem itself was solvable.

That certainty let me push through:

• incorrect assumptions,


• hallucinated constraints,


• broken code generation,


• malformed OBJ output,


• and multiple rounds of ChatGPT confidently misunderstanding the puzzle.

That is where I think vibe coding genuinely works well:

When the human already owns the invariants.

If you know:

• the problem is solvable,


• the constraints are real,


• and the output is verifiable,

then AI becomes an accelerator and vibe coding is 100% OK in my book.

But if the requirements themselves are "vibes", then the system has nothing solid to converge toward.

You do not get speed.

You get, well, nonsense.

PS:

should you knock over your puzzle, or ever need to fill a 5x5x5 cube with a planar pentacube, while also needing to visualise the solution...

I got you: vibe coded go implementation