What is shifting now

Vibe Coding Was Just the Beginning

Vibe coding may be the first visible form of a larger shift: from manual configuration to intent-driven engineering across software, workflows and processes.

Why natural-language intent may become the universal configuration interface for software, workflows and enterprise processes.

Vibe coding is usually described as a new way to build software: tell an AI what you want, let it generate the code, run the result, correct it, and keep going.

That description is accurate — but too narrow.

The interesting part is not that AI can write code. The interesting part is that a human can increasingly describe an intended outcome without specifying every implementation step.

Once you look at vibe coding that way, code becomes only one possible output.

A person facing generations of computers and configuration screens, asking why they still have to configure systems manually

The same interaction model can configure a Jira workflow, build an approval process, connect systems through APIs, create an automation in n8n, provision infrastructure, assign work to AI agents, or orchestrate a business process that combines software, humans and machines.

The larger shift is not from manual coding to AI coding.

It is from manual configuration to intent-driven configuration.

The interface is changing from “how” to “what”

Traditional software and process configuration requires users to translate business intent into implementation details.

A person wants something simple:

New employees must receive access to the right systems before their first working day.

But implementing that intent usually means deciding which forms to create, which fields are mandatory, which workflow states are required, who approves what, which identity system is called, what happens when an approval is late, where exceptions are logged, and how the process is monitored.

The business requirement becomes a long sequence of configuration decisions.

Vibe coding demonstrates another model.

A user can say:

Build an onboarding process for employees and contractors. Require manager approval for privileged access, create the required tasks automatically, escalate overdue approvals, and keep an audit trail.

An AI agent can then translate that intent into implementation artifacts.

Some artifacts may be code. Others may be:

  • workflow definitions;
  • Jira issue types, statuses and automation rules;
  • forms and validation rules;
  • API integrations;
  • n8n workflows;
  • cloud resources;
  • agent instructions;
  • permissions and policy controls;
  • monitoring and audit rules.

From the user's perspective, these are all variations of the same activity: describe the desired system and let an AI construct the configuration.

Vibe coding is one instance of a larger pattern

The current definition of vibe coding remains strongly tied to software development. IBM describes it as an intent-driven development approach in which AI generates code from natural-language instructions. The 2025 Stack Overflow Developer Survey used an even narrower definition — generating software from LLM prompts — and found that 72% of respondents said vibe coding was not part of their professional development work.

That number is useful precisely because it shows how young and narrow the concept still is.

There is no good evidence yet for the percentage of engineers who see vibe coding as a general model for configuring systems and processes. The question is rarely asked that way.

But the underlying direction is becoming visible.

Camunda, for example, has discussed AI agents as builders of process automation solutions, arguing that agents need programmatic interfaces such as APIs, SDKs, repositories and test frameworks rather than interfaces designed only for humans.

Google's guidance for coding agents also moves beyond the idea of a single clever prompt. It recommends separating intent, requirements, specifications, implementation and verification, often involving multiple agents.

Those are important signals.

As soon as AI agents can operate tools, APIs and configuration interfaces, the boundary between “coding” and “configuring” starts to disappear.

From Vibe Coding to Vibe Configuration

A useful term for the broader pattern might be Vibe Configuration.

Traditional configuration looks roughly like this:

Business intent → human interpretation → configuration screens / scripts / rules → system

Vibe Configuration changes the middle:

Business intent → AI agent → tools / APIs / configuration → system

The human is no longer required to know every menu, schema, syntax or implementation detail.

That does not mean expertise disappears.

It changes where expertise is applied.

Instead of spending most of the effort on mechanical configuration, experts can focus on requirements, constraints, architecture, exceptions, governance and verification.

This is already familiar from modern AI-assisted development. The strongest results rarely come from saying “build me an application” and blindly accepting the output. They come from defining what the system should do, giving the agent the right context and tools, reviewing the result and testing whether the implementation matches the intent.

The same principle applies to business processes.

The next step: Vibe Process Engineering

The more interesting evolution is Vibe Process Engineering.

Imagine describing a process rather than configuring a particular application:

We produce short advertising videos. Every video starts with a campaign brief. An AI agent should create three concepts. A human selects one. Another agent produces the script and storyboard. Legal must approve regulated claims. Production creates the final asset. Nothing may be published before legal approval, and every decision must be traceable.

The implementation could span several systems.

A process agent might create work items in Jira, store knowledge in a shared repository, trigger an n8n workflow, call video-generation services, invoke specialist AI agents, request human approval and write evidence to an audit store.

The user does not necessarily care which part is implemented as code, which part is a workflow and which part is an agent prompt.

The unit of design becomes the business outcome.

That is a much bigger idea than AI-generated source code.

The dangerous version is “just vibe it”

There is an obvious problem with taking the analogy too literally.

A casual vibe-coded prototype can fail and be rebuilt. A production business process may move money, grant permissions, communicate with customers or make legally relevant decisions.

Enterprise Vibe Configuration therefore cannot mean:

Describe something vaguely and trust whatever the AI creates.

It has to mean:

intent + constraints + tools + verification + governance.

The agent needs to know not only the desired outcome but also what it is allowed to change, which policies are mandatory, which actions require human approval and how success will be tested.

This is why the evolution from vibe coding to agentic engineering matters. As AI systems gain more autonomy, specification and verification become more important, not less.

A new universal interface to systems

For decades, every application has taught users its own configuration language.

Some use code. Others use forms, workflow designers, YAML, BPMN, SQL, visual automation builders or hundreds of administration screens.

AI creates the possibility of adding another layer above all of them:

natural-language intent.

That layer will not eliminate the underlying technologies. Someone — human or machine — still has to produce precise configuration.

But humans may increasingly interact with those systems indirectly.

We will describe the desired outcome, constraints and policies. Agents will translate them into executable configurations. Other agents will review and test the result. Humans will remain responsible for the decisions that matter.

What we currently call vibe coding may therefore turn out to be the first popular example of something much larger.

Vibe coding was never really about code.

It was about discovering that intent itself can become an interface.

And once intent becomes an interface, almost anything configurable becomes a candidate for the same model.

Sources