Vibe Coding: Why Less Is Often More (and How to Avoid the Agentic Trap)

We are living in a time when developers often confuse complexity with productivity. Teams build huge orchestration systems for AI agents, define complicated protocols, and stare at pull requests instead of shipping software.

Inspired by the “Agentic Engineering” philosophy from Peter Steinberger, the creator of OpenClaw, we concluded that we must reduce complexity aggressively to gain real speed.

This is how we move from the complexity trap toward 600 commits per day.

1. Escaping “Slop Town”

Many teams fall into the Agentic Trap. They can spend weeks or months building elaborate agent infrastructures: mayors, observers, dozens of sub-agents that all talk to each other.

The problem is simple: these systems often create slop instead of progress, because they forget the most important element — human taste and vision. More agents do not automatically mean better code.

Less orchestration and direct contact with the model usually brings results faster. We need to stop building managers for our agents and start being the pilot again.

2. Why CLIs beat modern MCPs

A clear example of “less is more” is the technical interface. The industry pushes the Model Context Protocol (MCP), which injects huge JSON blobs into context and can overwhelm the model.

Our approach is simpler: use plain CLIs. Instead of complex APIs, we give agents short terminal commands. An agent can already use tools like curl or jq to pull exactly the data it needs.

In this area, the old UNIX mindset — text in, text out — often wins over bloated modern protocols because agent models are very good at using terminals.

3. “Prompt Requests” are the new pull requests

In traditional workflows, the process itself becomes a bottleneck. We wait for cloud CI/CD, human code review, and handoff friction.

Less-is-more thinking requires a shift:

• Read less code: For routine tasks, reading every line is often unnecessary. What matters is system architecture and where components live.
• From PR to Prompt Request: A request is often about intent. When the intention is clear, the agent can verify, fix, or even rewrite the implementation.
• Close the loop: Instead of waiting for external review cycles, we let the agent validate locally and, when green, merge much more directly into main.

4. The setup: high-end minimalism

This setup is surprisingly unglamorous. We do not need futuristic VR tools. We need the oldest computer interface of all: the terminal.

• Control room: Steinberger often works on two Macs at the same time (a MacBook Pro and a Mac Studio via Jump Desktop). Multiple agent sessions run in parallel across terminal tabs, like a small team handling different tasks at once.
• Tech stack: For web work we use TypeScript. For CLIs we favor Go — not because we worship the syntax, but because the ecosystem is huge and agents can write Go code very reliably.
• Default models as daily driver: Instead of exotic wrappers, we use GPT-5 Codex for heavy refactors and Claude Opus for creative writing and rhythm-driven ideation.

5. Do It Yourself: three rules against the “Ralph Loop”

We do not need to wait for enterprise tooling to apply this approach. Three rules keep teams from entering a costly endless loop of broken fixes:

Rule 1: Fight context rot and MCP obsession

Many developers overload the model with dozens of MCP servers. It is expensive and often confuses the model.

• Use CLIs: An agent already knows how to call gh pr create when needed, without an extra abstraction layer.
• Cross-referencing trick: Instead of explaining new concepts from scratch, point to existing code in neighboring folders. A prompt like “Look in ../another-project and implement logging the same way” is often stronger than pages of documentation.

Rule 2: Stop the Ralph loop through dialogue

It is tempting to keep an agent running in a “run until tests are green” loop. That is often the fastest way to burn budget.

If the agent does not truly understand the problem, it begins guessing, and guessing creates expensive noise.

• Just Talk To It: We stay in the loop as pilots. We have a Socratic conversation first and give the explicit command “Build this” only after alignment.

Rule 3: Use visual communication

We no longer describe CSS issues purely in text.

• Screenshot the issue: A single screenshot with “Fix padding” can save thousands of words and eliminate many ambiguities.

Conclusion

For us, optimization today is not adding yet another tool.

It means removing friction between idea and execution:

• less bureaucracy
• fewer complex protocols
• less manual coding

Our job is no longer to type every line of syntax. It is to shape the work like a sculptor shaping stone: define the direction, feel the resistance in the process, and steer continuously.

The person who opens the terminal, keeps context clean, and starts building wins.