Vibe coding or software engineering? How AI is redefining value in software projects

AI-generated code is already part of how projects get built, not some future trend. And it's changing something deeper than just how code gets written: it's redefining where value is created in a software project. At Nephila, we're rethinking our workflow from analysis to delivery, and what we're learning is worth sharing.

***

Not all uses of AI in development are equal. There's a distinction we're finding increasingly useful, and it comes down to two phrases: vibe coding and software engineering.

Vibe coding is hammering at the problem: prompt after prompt, output after output, hoping the system eventually converges on something that works. It works, sometimes. But it doesn't scale, it's not controllable, and it doesn't accumulate value.

Software engineering, even in the AI era, means building the project in your head first and then having it built. The distinction sounds subtle. The implications aren't.

If code loses centrality, what takes its place?

We've always held that code is not the point of our work. It's the means by which we deliver value, but value doesn't live in lines of code. Three lines in Rust and a million lines in Python can produce the same result for the end user.

With generative AI, this becomes even more apparent: an LLM can write React, Django, FastAPI or any other stack with comparable efficiency. Framework choices remain relevant (you can't validate code in a language you don't understand), but the stack becomes less decisive than it once was.

What gains centrality is the knowledge asset that makes up a project: the entire process of information work that takes an idea and turns it into something a user can actually use. This process serves two purposes:

• during the design phase, it allows everyone involved to align on what needs to be done and why;
• during implementation, it provides the context passed to the AI to generate code.

For a technology partner, one that designs and builds custom software for clients, often on an ongoing basis, there's an additional implication: the code goes to the client. The knowledge asset built to produce it stays in-house. It’s the real asset that compounds over time, project after project.

What you can't delegate to AI: architecture

An LLM left to its own devices may make smart technical choices on project A and completely different ones on project B, simply because it starts from scratch each time. No consistency across projects, no accumulation of experience.

Architectural decisions (what kind of API to expose, how to distribute responsibility between frontend and backend, how to model data, which patterns to adopt) cannot be delegated. Responsibility shifts to defining the rails: not excessive constraints, but a clear boundary within which the LLM can operate deterministically and consistently across all projects.

In a similar vein to spec-driven development, we don't think "the prompt is the new code" is the right framing: what's needed is something more structured, building a comprehensive view of the project in natural language, with the level of detail required to ensure consistency, and then delegating code writing to a set of agents guided by that spec.

Documentation as operational practice, not overhead

Where knowledge lives also changes. Oral knowledge is a liability: it's held by whoever holds it, it can't be shared transparently and, increasingly relevant, it's not accessible to an LLM.

When a system's documentation exists in a structured, centralised form, an AI agent can draw on it: know how deployment is configured, where the critical dependencies are, which architectural decisions were made and why. The quality of available context becomes directly proportional to the quality of the generated output.

This changes our relationship with writing documentation. Writing more documentation means shifting effort from implementation to design, rather than adding overhead, bringing two concrete benefits: 

• less implementation work: code generated from a well-written spec requires fewer iterations and fewer corrections;
• value over time: six months from now, revisiting a feature means reading the documentation, not reconstructing the reasoning from code.

The real challenge is about discipline, not technology. Code and documentation tend to drift apart, and keeping them aligned requires a system and ongoing review.

Accountability: generated code is still a human responsibility

One point that admits no ambiguity: it doesn't matter whether the code was written by an LLM or a human, the person who used it is responsible for it.

The infrastructure of rules and conventions we're building is designed to make that responsibility exercisable in practice, not as a statement of principle, but as a verifiable practice. Engineers who use AI must be able to understand and validate the output. If they can't, they can't sign off on it.

It works today

These are not theoretical considerations. On several recent projects, working from a structured project document first, even in situations of initial informational chaos, dramatically reduced feedback cycles and implementation work. In other cases, having structured documentation in place allowed the team to test and approve features without constant realignment.

The benefits are not expected a year from now. They're already visible, in the projects where this approach has been applied with discipline.

Worth stating clearly: this holds even when AI isn't involved. Structured documentation helps human developers work more effectively and more fluidly, according to traditional development practices, before any AI-centric workflow enters the picture. A well-built knowledge asset is an advantage in itself, regardless of who or what, uses it to write the code.

***

We're still building this workflow: some parts are consolidated, others in progress. What's clear is the direction: value shifts from writing code to building context. Those who start working on this now will have a concrete advantage over those waiting for the landscape to settle.

If you'd like to learn more about how we're structuring this approach, or compare notes on how your own development workflow is evolving, get in touch. More reflections on AI and workflow are coming to this blog.

***

We wrote this article with the support of AI. If you’re interested in how we use these tools as part of our writing process, you can read more here.