If you look at the modern "software engineer" workflow, a massive chunk of the day is spent playing roles in TDD (Test-Driven Development) or BDD (Behavior-Driven Development) ceremonies. It’s often more about the ritual of red-green-refactor than it is about actually thinking through the logic. We've been drowning in boilerplate and mechanical processes that don't actually touch the core complexity of the problem.
The trap of "vibe coding" #
With the rise of LLM agents and tools like Claude Code, we are seeing the birth of "vibe coding." This is where a developer feeds a loose prompt into an agent, watches the code fly by, and hopes the resulting output "feels" right. This is dangerous because it bypasses the essential complexity of the task.
When you outsource the "rituals"—the typing, the basic structure, the standard patterns—you aren't actually being freed from work. You are being stripped of your distractions and forced to face the raw, unadulterated logic of your system. You can no longer hide behind a failing test suite or a complex directory structure. You are left with the actual problem: Does this logic hold up? Does this change introduce side effects in a distant module?
You are the actual harness #
In machine learning, a harness provides the framework that allows a model to perform reliably. In the new AI workflow, the programmer is the harness. The model provides the raw power, but the quality of the output is strictly bounded by the constraints, the edge cases, and the architectural rigor you impose on it.
If you provide a vague, "vibes-based" prompt, you get a brittle, "vibes-based" implementation. If you provide a near-formal specification, you get high-quality code.
To move away from the "vibe" trap and toward a real AI workflow, I've found that shifting from TDD to a more robust verification approach helps. Instead of just writing unit tests for happy paths, I’m leaning harder into fuzzing and property-based testing.
A practical approach to verification #
When using an LLM agent to generate a complex function, don't just ask it to "write tests." That's just more ritual. Instead, use a more aggressive verification method. For example, if you're working in Python, don't just settle for unittest
. Use something that explores the state space more aggressively:
import hypothesis
from hypothesis import given, strategies as st
@given(st.lists(st.integers()))
def test_complex_logic_property(data):
result = my_ai_generated_function(data)
assert is_valid_transformation(data, result)
By using tools like Hypothesis, you aren't just checking if the code "works"; you are attempting to break the logic the AI just handed you. This is the real work of a senior engineer in the age of LLMs. We aren't here to write code anymore; we are here to define the mathematical and logical boundaries that the code must live within. If you can't define those boundaries, you aren't an engineer—you're just a spectator watching an LLM hallucinate a system into existence.
Next I got sucked into a coding challenge that turned into a →