Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

Let's retire "vibe coding." The phrase is already fading, and for good reason: it describes an approach where you don't look at the code, don't care much about quality, and just prompt until something works. That's a fine way to throw together a prototype. It is not how serious software gets built, and using the term tends to signal that the speaker has never had to keep a production system alive on a Friday night.

The work that matters is agentic engineering: handing real, scoped tasks to a coding agent and trusting the output without manually reviewing every line. That trust is the whole game. And here's the uncomfortable truth most of the current tooling glosses over: a coding agent is only as good as the environment and the architecture it operates inside. The thing that makes today's vibe-coding platforms feel magical is the same thing that makes them unsafe for an enterprise.

This post is about that gap, and about why an opinionated architecture isn't a constraint on agentic engineering. It's the precondition for it.

The magic trick is the environment

Tools like Lovable, Replit, Bolt, and Base44 are genuinely pleasant to use. Drop in a prompt, watch an app appear. But the reason they feel effortless is subtle: they put you inside a sandbox. You never have to describe the environment, set constraints, or explain how anything is wired together, because the environment is fixed, small, and implicit. The agent isn't making good architectural decisions. It's operating in a world so narrow that there are barely any decisions to make.

That works right up until the environment stops being trivial. At a real company, the environment is the hard part. You have databases with history, runtimes with constraints, services that depend on each other, security boundaries that exist for legal reasons, and a blast radius that includes actual customers. The interesting question was never "can the agent write code that runs?" It's "can the agent select the right frameworks and make sound architectural decisions inside a real system?"

And on that question, agents are still weak. They get meaningfully better only when they understand the architecture they're working in: what database they're using, what the runtime looks like, what connectivity is available, how things are meant to be structured. Give an agent that context and it makes good decisions. Leave it to guess and it improvises — which is exactly what you don't want near production.

This is the core of it: a coding agent needs an opinionated architecture to reach scale. Harper provides one.

Shared context beats per-developer context

There's a difference between context that lives in one developer's head (or one developer's prompt) and context that's codified once and shared across a team.

In a sandbox, you don't need shared context because the environment is implicit. In an enterprise, the absence of shared context is precisely the problem. Every developer ends up re-teaching their agent the same things about the same environment, slightly differently each time, and those small inconsistencies compound into divergent architectural decisions across a codebase.

The better model is an environment definition that the whole team — and every team member's agent — can read. Define the shape of the environment once, declaratively, and the decisions made downstream become consistent. There's an emerging pattern here of structured, layered context: information organized so you can scope it, with some facts relevant to the entire organization and others specific to a single application. Harper's schema and configuration files are exactly this kind of declarative, shareable context. The structure of the system isn't folklore passed between engineers. It's on disk, versioned, and legible to both humans and agents.

When a local coding agent already understands how it's going to structure things, it makes good decisions by default. Harper makes "how things are structured" explicit and shared, instead of improvised and private.

What makes Harper opinionated and why agents benefit

Harper is an open-source Node.js platform that fuses the database, cache, application logic, and messaging layers into a memory optimized process. Where a conventional stack stitches together a database, a separate application runtime, a messaging layer, and a backend API tier — each with its own network hops and failure modes — Harper collapses them into one memory-optimized process.

That collapse is why being opinionated makes Harper fast. Because the platform takes a strong position on how the pieces fit together, it can be one of the fastest Node.js runtimes available: sub-millisecond server responses in scenarios where a traditional stack takes well over 100 milliseconds, pages loading several times faster, all at a scale that already handles a meaningful slice of global e-commerce traffic. Opinion, here, is what buys performance.

It's also what gives an agent a surface it can actually reason about. In Harper, the things an agent works with are declarative and small: a schema (schema.graphql), configuration (config.yaml), and JavaScript resource files. Annotating a schema with @export turns it into REST, GraphQL,  MQTT, and WebSocket endpoints automatically — no manual route wiring. The agent edits config and schema files rather than firing arbitrary queries at a database.

The result is a tight, legible, deterministic surface. The schema and the config are right there, on screen, in version control. The agent doesn't have to invent an architecture or guess at structure, because the architecture is already expressed in files it can read and modify. You've removed most of the opportunities for it to make a bad decision.

Narrow scope is what keeps agents safe

Here is the failure mode that should keep enterprise engineers up at night. A coding agent, working autonomously, finds a script on the file system. The script has production credentials hard-coded into it. The agent uses them, logs into the production environment, and runs a DROP TABLE. You're left staring at the wreckage asking why production credentials were sitting in a script in the first place.

This isn't a far-fetched scenario. It's the predictable consequence of giving an agent broad access and no separation between what's allowed in development and what's allowed in production. Lone developers moving fast do this constantly. Enterprises cannot.

Harper's answer is narrow scope and granular control. The agent can edit a config file or change a schema locally— without needing to send arbitrary SQL commands to the database potentially wreaking havoc to your environments. It has a way to make the schema changes you want it to make, and with a well designed AISDLC, no way to drop the database or do the things you never authorized. Sandboxing and firewall-style rules constrain what the agent can reach and what it can talk to.

Crucially, Harper makes the separation between development, staging, and local environments easy as a matter of workflow, not heroics. That control surface — the boundary between "you can do this here" and "you absolutely cannot do that there" — is exactly what distinguishes a startup that moves fast from an enterprise that moves fast and keeps significant controls on what can be done. You still get build-it-run-it autonomy. You don't get drop-the-production-database autonomy.

Reframed properly, the sandbox isn't a limitation. It's the feature. Limiting what a tool can do — what it can change, what it can connect to — is precisely what makes it safe to put in more hands. The narrower the scope, the more confidently you can let an agent run.

Let the agent propose, let a deterministic tool dispose

There's a related principle that makes all of this hold together. The agent is non-deterministic by nature. So let it do what it's good at — reading and writing configuration, infrastructure-as-code, and schema-as-code — but have a deterministic tool make the actual changes. You read what the agent proposes, you know exactly what will happen, and a deterministic process applies it.

Why insist on this split? Because a non-deterministic tool, no matter how reliable it's been in the past, will eventually try too hard to please you. At some point it will work too hard to solve the problem you handed it and make things worse than they were before. Deterministic rules don't have that failure mode. A deterministic layer with rules that forbid dropping tables simply won't drop a table, however persuasively the agent argues for it.

Harper makes this separation natural. The agent authors config and schema; Harper's deterministic machinery applies them within guardrails it cannot talk its way around. That is, in effect, a harness: the agent reads and writes, a reliable system makes the changes, and the rules hold. You can build a harness on Harper that ensures scale — and teams already have, making Harper the foundation of their agentic workflows.

Redefining scale: speed, performance, reliability, security

When people say "scale," they often mean only throughput. It's worth being precise. Scale is speed, performance, reliability, and security together. A system that's fast but fragile doesn't scale. One that's reliable but insecure doesn't either. Harper addresses all four in a single opinionated platform.

Speed and performance come from the fused, in-memory runtime — sub-millisecond responses, no cross-service hops on the hot path. Reliability comes from collapsing the stack into one process with far fewer moving parts and external dependencies to fail, with multi-node replication available for production deployments. Security comes from everything in the previous two sections: narrow agent scope, real dev/prod separation, sandboxing, and no loose production credentials waiting to be misused.

The deeper point for anyone responsible for an engineering organization: the hardest, lowest-level scale decisions have already been made for you, by engineers who are among the best in the world at making them. That's what an opinionated platform is — a set of expert decisions baked in so your team doesn't have to relitigate them on every project. The opinion is a gift, not a cage. It's how your people build performant applications at scale without each of them needing to be a runtime specialist.

Who this is really for

Look at where the craft of software engineering is heading. Engineers are moving up the stack. Increasingly the job is to define the shape of the solution — the entities and their relationships, the test and acceptance criteria, the performance and security requirements — while agents handle the low-level code underneath. It's becoming requirements and specification engineering more than hand-writing loops. The valuable skill is describing the puzzle piece precisely enough that an agent can build something that fits the hole.

The engineers who thrive in that world aren't the two-years-of-experience generalists. They're the people with real architectural backgrounds — folks who came up through Java or Ruby on Rails, who sit at the confluence of systems thinking and architecture, who already understand in their bones that a prescriptive stack delivers performance and scale gains you can't get by wiring everything together by hand. They want things done fast and done well.

For exactly those people, an opinionated platform is the unlock. It's what lets a seasoned architect safely delegate the low-level work to an agent without ever losing control of scale. The opinion does the part the agent is bad at — architecture — so the human can focus on the part the agent can't do: deciding what to build and why.

The takeaway

Agents don't reach enterprise scale through cleverness. They reach it through environment and architecture. The sandbox tools give you the easy version of that — implicit, trivial, impossible to take to production. Harper gives you the enterprise version: shared context your whole team and their agents can read, an opinionated architecture that makes good decisions the default, narrow scope that keeps agents away from the things that can hurt you, and a deterministic layer that applies changes you can trust.

Give your agents an opinion. Harper is the harness that turns agentic engineering into scalable engineering.

Try open-source Harper, read the docs on schemas, config, and resources, or talk to us about building an agentic harness on Harper.