The human is still the integration layer
Generate the code. Ask another tool for tests. Explain the architecture again during review. Find the deployment instructions. Reconstruct the reason for a constraint when the next agent starts.
Each task can become faster while the engineer remains responsible for carrying intent between disconnected activities. The apparent automation depends on someone remembering what the tools cannot see and reconciling what they produce.
My approach is to engineer that surrounding system. Don't just use AI to build the product. Build the machine that knows how the product is meant to be built, how to judge a change, and where its authority ends.
Begin with a source of intent
I use a canonical product and engineering Bible to record the problem, users, domain, constraints, architectural decisions, and definition of a successful release. It is the starting contract for the work, not a collection of slogans.
The document matters only if it corresponds to the system. A requirement that never reaches an interface, test, or operating procedure remains easy to ignore. A decision that changes without updating the record gives the next engineer or agent durable misinformation.
Keep the source of intent versioned and navigable. Let an agent load the relevant decision and its context rather than repeatedly handing it an undifferentiated pile of documents. Persistent context needs maintenance as much as persistent code.
Turn principles into interfaces and checks
Architecture gives work boundaries: which component owns a decision, what crosses its interface, and which dependencies it may use. Separation of concerns, SOLID principles, and design patterns are useful when they make those decisions explicit. Reciting their names does not create the boundaries.
A rule that publishing requires approval should live in the use case that performs publication. A data contract should be validated at the boundary where it enters the system. A user-interface change should not require reinventing the persistence rules.
This is what makes a system operable by AI. The agent can discover where a change belongs, make it within a bounded area, and run checks capable of rejecting it. Discipline becomes more valuable as the agent becomes capable of changing more of the system.
Give agents roles and skills with usable contracts
A role describes a responsibility and the decisions it may make. A skill provides a repeatable way to perform a bounded kind of work. Both need inputs, outputs, evidence requirements, and limits.
An agent assigned to review a migration should know what it is reviewing and which facts establish compatibility. It should not infer authority to apply the migration. An agent preparing a release should know how to verify the target and recover from a failed check before it is handed deployment access.
The number of agents is not the measure of maturity. Add a role when it separates useful judgment or responsibility. Add a skill when it captures a repeatable capability. Otherwise the coordination itself can become another system to debug.
Carry the contract through production
The engineering machine extends beyond generated code. Domain rules shape APIs and data. The interface expresses those rules to people. Infrastructure, security, tests, deployment, cloud configuration, and DNS determine whether the intended behavior reaches the intended users.
Observability then closes the loop. A build result is not a production result. A deployment ID does not prove the correct domain serves the change. A provider accepting an email does not prove delivery. Each consequential transition needs evidence suited to the claim being made.
This website illustrates a bounded version of that approach: shared content contracts, server-side publication rules, a separate persistence layer, explicit deployment settings, and checks of the resulting public behavior. It is an inspectable example of the operating discipline, not evidence that every workflow is autonomous.
Why this is not vibe coding
Vibe coding can let an implementation evolve while the person accepts or rejects the visible result. The engineering approach described here requires an explicit model of what is being built and independent ways to judge whether the result satisfies it.
An attractive interface is not enough when authorization is wrong. Passing tests is not enough when the tests merely repeat the implementation. A confident agent report is not enough when the resulting state was never checked.
AI supplies speed and breadth. The operating model supplies continuity, boundaries, and evidence. The engineer remains responsible for the architecture and for the claims made about the result.
Build only the machine the work needs
There is a real counterargument: systematizing the process can become a way to avoid building the product. Too many agents, documents, frameworks, or gates can consume more effort than the repeated work they were meant to improve.
Start from recurring failure or repeated coordination. Make the smallest reusable capability that addresses it. Keep the architecture proportionate to the consequence and complexity of the system.
The same standard applies to the machine itself. Can another engineer or agent find the relevant intent, perform a bounded change, and produce evidence of the result without a human reconstructing the whole project? That is a more useful test than how quickly the first draft of code appeared.
More questions. Better conversations.
Bring this perspective to your event