In my early days as a developer, I remember working on a prototype to show our stakeholders to demonstrate the solution we were planning to build. I was polishing the user interface, tweaking fonts, margins, alignments of items on the page, ensuring the transitions were smooth, and making the filters look "pixel-perfect."

A more senior engineer noticed what I was doing and asked why I was doing it. I then explained I wanted to make the prototype look polished. They told me not to do it.

At first, I was confused, but the engineer clarified: if stakeholders see a polished prototype, they will think the project almost finished. They won't see the duct tape and the hardcoded strings holding the backend together. They’ll think we’re a week away from shipping when we haven’t even touched the database indexing yet.

He wanted the prototype to look "scrappy" because scrappiness is a vital communication signal. It tells the world that this is an idea, not an infrastructure.

Today, we’ve hit a version of this problem that is much more subtle. We’ve entered the era of Vibe Coding.

The Paradox of the Vibe

In my workflow, Vibe coding is the spiritual successor to those scrappy prototypes, as I treat vibe-coded code as a disposable medium for thought. When I’m in "vibe mode," I’m using AI as a fast prototyping tool that allows me to quickly experiment and iterate on concepts, significantly accelerating that process.

When doing this, I don't care about the folder structure, the variable naming, or whether the state management follows a strict pattern. I also don't care about performance, reliability or security. I just want to see if the concept has legs. In this phase, the AI is the lead, and I’m just the "vibe checker." If the result looks like it works, it’s a win.

But here is the catch: modern LLMs are too good at the polish. Unlike my old prototypes where I had to manually add the "shine," AI agents produce shippable-looking UI/UX by default. This creates a false sense of "readiness" that ignores the invisible 90% of software engineering.

Switching to AI Assisted Engineering

When it’s time to move from a concept to "serious" code that I actually want roll out to production, my relationship with the AI flips. This is where I move into AI Assisted Engineering.

In this mode, I’m the Lead Architect, and the AI is a high-output Senior Engineer who still needs strict guardrails. To manage this, I follow a three-component process:

1. The "Contract of Truth" (Design Doc): Before touching the implementation, I work with the AI to draft a design doc. This isn't just about features; it’s about non-functional requirements. We define the data schema, error handling strategies, and security constraints.
2. Chunked Implementation: I never ask an agent to "build the feature." Instead, I work with the agent to break the implementation into manageable chunks. This makes the code review process actually possible. I’ll read the code as it’s generated, stopping to provide feedback the moment I see a potential issue, then review the change as a whole before accepting.
3. The Feedback Loop and Memory: When a decision is changed during the implementation, I ask the agent to update the design doc. For certain issues, like a specific way we handle API auth, I also update the agent's memory file. This ensures that the agent actually "learns" the project's constraints over time.

A Hybrid Future

Does this mean we should force AI agents to produce "scrappy" prototypes? Not necessarily. We should take advantage of the AI’s ability to create high-fidelity prototypes, but we must be the ones providing the reality check.

As stakeholders' expectations for polish increase, our role shifts from "building the UI" to "managing the truth."

The most effective engineers in 2026 won't be the ones who just "vibe" their way through a project, nor the ones who refuse to use AI. They will be the ones who know exactly when to let the vibe rip and exactly when to pull out the design doc and start engineering.