Since LLMs became widely available around mid-2021, it was only a matter of time until they integrated more and more into our daily work. What we didn’t expect was such rapid adoption across nearly every sector. Since then we’ve seen Codex, Copilot, Claude and, day by day, we’ve been heading to the scenario we see today: agents capable of building whole applications using natural language.
The popularization of vibe coding
Applications using “vibe coding” — a term popularised by Andrej Karpathy, OpenAI co-founder, in early 2025 — have become common in many developers’ routines. For many, this was sold as a great enabler. The idea was simple: anyone could make code; just talk, be willing, and you’d have a million-dollar application in your hands. At first glance, this can even seem true. After all, in programming it’s common for something to work even if it’s not done ideally.
Well, if a query takes 1200ms or 25ms, both are working, right?
How long does “making it work” really work?
This is precisely where the risk lies. When the idea that “working” is enough is sold, discussions about architecture, performance, security, maintenance and best practices start to seem secondary. And they are not. In the past few months we’ve had several cases of influencers claiming “it’s over for devs”, and being hacked shortly after. And that’s not the only case.
The security warning
Escape Research Team found, among 5,600 publicly available apps, over 2,000 vulnerabilities, more than 400 exposed secrets and many other sensitive user data leaks. This type of finding highlights a simple point: speeding up delivery without technical criteria has a cost.
What this scenario demands from us
We cannot know everything, nor can we always expect to have enough time to deliver in the ideal way. But it must be clear that, now more than ever, we need solid knowledge of architecture fundamentals, best practices, system design, Big O and so on. To achieve good results we need to guide agents well. But not only that. We must also review, question, validate and sustain technically what has been generated.
Facilitator or compromiser?
In this scenario, it’s up to us, developers, to understand how to take advantage of LLM advances without giving up maintainability, security and delivery windows. In the end, vibe coding can be a facilitator. But without technical foundations, it becomes a compromiser.
Spec Driven Development helps answer this question — but that’s a topic for another post.
References
- Cloudflare | What is vibe coding?
- Andrej Karpathy | Vibe coding
- Escape | The State of Security of Vibe Coded Apps
Agents have evolved — when will you?
Early AI-driven development was chaotic: chats were separated from code, prompt engineering wasn’t taken seriously and the context given to the bot was often “just fix it”. Then Copilot integrated into our workflow and things got simpler, mainly thanks to autocomplete. The integration wasn’t entirely seamless, but it helped having an LLM closer to the code.
Cursor then launched and provided a much stronger integration: dragging files, easier references, choosing models, and an editor that understood adjacent files. Today, with Cursor 3.0, code takes a secondary role: the goal is to converse, explain, correct, improve, and everything happens behind the scenes.
The evolution of the flow
Unlike a few years ago, our problem is no longer purely technological capability: agents aren’t dumb or incapable — quite the opposite. The point is that we also need to modernize. Mature our processes, improve methodology. What’s the next step?
Spec Driven Development
Agents work better when given clear, unambiguous directives: success cases, edge cases, invalid results and well-defined problem specifications.
Specification-driven development, as the name suggests, structures the process so that before implementation there is a clear specification of the problem, what to do to solve it and how we will implement solutions. It’s not a formally defined approach so names may vary, but the idea is consistent. The point is to remove doubts that commonly arise during development because the briefing wasn’t clear. Better yet: produce documentation of that implementation for internal discussion or as a record for future specs.
The spec cycle
In broad lines the spec cycle is defined as:
Specification: define the problem, base context, and what to fix.
Planning: define how to solve it — technologies, architecture, libraries and contracts, models/entities, etc.
Analysis: review the plan to find gaps, ambiguities or defects.
Break into tasks: split the solution into small implementable tasks.
Implementation: execute the process: at this stage all requirements, scenarios, tasks and technologies are documented for the agent.
With this process we can reach faster, documented, testable and more predictable results. In future posts we will look at different frameworks and how they differ.
