You’re Still in the Loop: 10 Frontier Engineering Principles for the AI Agent Era

Frontier Engineering: Ten Principles for Software Engineers in the Age of AI Agents

At eleven p.m., you are still waiting on a chat window.

The cursor blinks in the input box. You paste the error message you just got, hit Enter, and stare at the screen. Sixty seconds later, code appears. You paste it into your editor, run it, and it still fails. Copy again, paste again, wait again.

This is the daily routine for many developers using AI coding assistants. You are using it, yes, but your shipping speed has not changed. Or the change is so small you can ignore it.

The loop is the problem. You are always in it.

Frontier developers do not work this way. They hand-write less than one percent of their total output. The rest is produced by AI agents they instruct, constrain, and review. Their job is no longer to write code. They write intent, set direction, and tune the system.

The following ten principles come from Kiro’s observations of frontier engineering practice. They form a system that unfolds step by step. First change your role. Then change how agents run. Then change the codebase, the quality bar, and the entire development lifecycle.

1. You Are an Architect, Not a Typist

In the past, the core action of a software engineer was writing code. Now, the core action is writing intent.

This sounds like a slogan, but it changes how you spend your time every day. You no longer spend most of your time on syntax, framework APIs, repetitive CRUD, and debugging details. What you need to define is:

• What counts as done?

• What are the constraints?

• Which edge cases must be handled?

• How do you verify correctness?

• What behavior must never happen?

“Add auth to this API” is not clear intent.

Clear intent is: Which roles can access which endpoints? What happens when a token expires? What status code is returned for unauthorized access? How do you test privilege escalation? Are audit logs required? Should rate limiting be considered at the same time?

When you write these things clearly, agents have a chance to write code that matches expectations. Otherwise, they can only guess on your behalf. Every architectural decision they guess may later become technical debt you need to undo.

The work of frontier developers comes down to two things: defining what done should look like, and verifying whether the output matches intent. You still need to go deep into technology, but the way you go deep has changed. You are an architect, an editor, and an acceptance reviewer now.

2. Maximize Agent Time, Minimize Your Involvement

Many developers use AI assistants like this:

Prompt the agent, wait sixty seconds, get code, test manually, find an error, paste the error back into the chat box, wait another sixty seconds, test again.

This loop has a fatal problem: you are always in it. Every minute the agent works, you are occupied. Your output ceiling is how many chat windows you can watch at the same time, not the agent’s capability.

Frontier developers do it differently. They assign longer tasks to agents and build clear validation steps into them:

“Implement this feature, write tests, run the tests, make sure they all pass, and get the new code to ninety percent coverage.”

Then the agent works for thirty minutes, an hour, or longer. The developer goes off to do something else. It is normal for the agent to make mistakes along the way. The key is to let it loop, self-correct, and converge on the right answer.

A further step is to run multiple agents in parallel, handling a steady stream of tasks. You review output asynchronously instead of waiting for it synchronously. Your productivity limit is how many agents you can keep meaningfully busy at the same time, not typing speed.

A further step still is to let agents run for hours or overnight, let agents launch other agents, and review the results the next morning. The goal is to gradually remove yourself from the execution loop until your involvement is limited to setting direction and validating results.

This requires trust, but trust is not blind. It needs the later principles to support it: a clear codebase, fast feedback loops, and reliable boundaries.

3. Build Your Codebase for Agents

The ceiling on what agents can do depends on the codebase they work in.

A codebase that is friendly to human developers is usually friendly to agents too: a complete README, architecture docs, tests that describe expected behavior, clear module boundaries, strong typing, informative error messages, and a fast build process. These foundational tasks were always worth doing, but in the agent era their returns are much higher.

The reason is simple: a human team member only needs onboarding once, while an agent needs onboarding every session. The context humans carry in their heads, including conventions, standards, tacit knowledge, and past pitfalls, is not known to agents. You have to make it explicit.

This means you need to build a context infrastructure for agents:

• Steering files: define code standards, architectural conventions, and technology selection principles.

• Skills: task-specific procedures loaded only when needed.

• Scripts: automate environment setup, dependency installation, and database migrations.

• Command-line tools and MCP servers: let agents obtain context and perform actions.

• Documentation and comments: let agents record design decisions for future sessions.

In a large legacy codebase, do not start by exposing the entire repository to agents. Handle one module at a time and limit the agent to a prepared area. First make one module agent-friendly, then expand gradually.

One more point: let agents record their work for future sessions. Agents should record design decisions and add abundant code comments that can serve as persistent memory. The next agent session inherits not only the code, but also the reasoning behind it. This is how an agent system compounds over time instead of starting from zero every time.

4. Give Agents a Fast Feedback Loop

If an agent cannot run tests in your local environment and self-correct, then the bottleneck is you.

Many teams introduce AI coding, and code generation gets faster, but broken builds and bugs also increase. Agents cannot validate their own code, so humans become the only test runner.

Frontier developers invest heavily to make validation fast, local, and automatable. Agents should be able to use:

• linters and unit tests;

• a browser to render and visually verify UI changes;

• local mocks of dependent services for integration tests;

• the ability to start a full stack on a laptop and run end-to-end tests;

• static analysis, type checking, and security scanning.

If you use a tool to validate your own work, agents should be able to use it too. That way they can self-validate instead of making you copy and paste output between tools.

Property-based tests are especially valuable. Traditional unit tests verify the cases you thought of; property-based tests verify whether the implementation matches your intent and can catch edge cases that agents would not think to write explicit test cases for. Agents should be able to validate their own work, find failures, and fix them without your involvement.

If you do not make this investment, faster code generation will only mean more broken builds and more bugs. If you do, the overall quality of the codebase may improve, because agent validation is more thorough and more consistent than the validation many humans are willing to do.

5. Execution Is Cheap; Direction Is Everything

When code can be written in an afternoon, the hard part is no longer implementation.

The hard part is deciding what problem to solve, what to build, and when to change direction.

Implementation details are easy to change. How a function is written, how a component is split, how an interface is named. Agents can quickly redo all of it. But system design, API contracts, dependencies, and architectural tradeoffs are durable decisions. Once they are wrong, no matter how fast the later code is written, you are only accelerating in the wrong direction.

Put your energy into these durable decisions.

During the design phase, treat agents as brainstorming partners. Let them research options, explore alternatives, and point out holes in your thinking. When two designs are both reasonable, have agents prototype each one, then compare based on evidence rather than debate. Choices that used to require several rounds of meetings can now be validated with runnable code.

Once the direction is set, practice spec-driven development. Work with agents to write clear specs and requirements, reducing ambiguity before they start generating code. Give an agent a vague prompt, and it will decide all kinds of tradeoffs on its own. The time you later spend undoing those choices is often more than the time you would have spent writing a good spec at the start.

During iteration, focus on what matters most: whether the architecture can withstand production load, whether the design tradeoffs need to be reevaluated, and whether the product is ready to put in users’ hands.

Execution is cheap. Direction is everything.

6. Treat Code as Disposable

Code is cheap now.

This sounds harsh, but it is liberating. You can spend a day building a prototype and then abandon it. You can spend two weeks pushing something close to production-ready, then start over after realizing it is not the right product.

In the past, throwing away code was hard for two reasons: you had spent months writing it, so you felt personally attached; and starting over meant spending months again. Both reasons are gone now. What matters is shipping the right thing, not carefully pushing a first draft into production, and not avoiding re-architecture because of sunk cost.

Discard code that no longer serves you. Agents can build the next version before the end of the day.

But there is one exception: tests at the boundaries.

Unit tests are discarded along with the code, but the tests that make starting over safe should remain:

• end-to-end integration tests that verify behavior;

• property-based tests that verify invariants;

• load tests that verify performance and concurrency at scale.

Together they form the contract that any rewrite must satisfy. Code can be disposable; contracts cannot. This is the balance point between speed and stability in frontier engineering.

7. Hold AI Output to Human Standards

Speed without quality only creates more production risk.

No matter who or what generated the code, code shipped in your name is your responsibility. You cannot lower the bar just because it was written by AI. Instead, you need to hold AI output to the standards of a human team, or higher.

Early on, this means reviewing agent output line by line to build intuition about model capabilities: where it does well, where it tends to fail, and which patterns it always gets wrong. This stage cannot be skipped, because you need to know what to trust and what to check.

But over time, line-by-line reading does not scale. You need to build an AI reviewer to carry part of the burden, checking the things the team values:

• correctness;

• security;

• maintainability;

• test quality;

• common bug patterns;

• architectural consistency.

Run the AI reviewer before local changes create a pull request, and run it again in CI. As the AI reviewer matures, let it handle the first few rounds of feedback. Human attention should focus on what you are best at judging: whether the design and architecture are correct, how changes will affect upstream and downstream systems, and whether security boundaries are solid.

Also extend the agent loop beyond merge. Let agents monitor deployments, verify production behavior, and automatically start fixing regressions when they appear. Being responsible for outcomes means accompanying changes through production, not stopping at the pull request.

8. Trust Boundaries, Not Agents

For agents to run autonomously for long periods, you need guardrails that do not depend on your constant supervision.

Many people fall into a false choice: either let agents run wild on your laptop, or manually click accept on every tool call. The former is dangerous; the latter is inefficient. Neither is frontier engineering.

The right approach is to limit agent access to the files, tools, network, and credentials it actually needs, then let it run without supervision.

Start with a narrow scope. As your confidence in the boundaries grows, gradually loosen them until the only things that need a gate are actions that cannot be undone. Be especially cautious with production: unless you explicitly and intentionally grant permission, agents must never access your production accounts or deployment credentials.

Add deterministic checks to catch problems regular testing is unlikely to find:

• static application security testing to flag vulnerabilities;

• credential scanning to catch leaked secrets;

• automated reasoning to mathematically verify that agent output matches intent;

• policy engines to block unauthorized actions.

Every automated guardrail is one more reason you do not need to stay in the loop.

Trust boundaries, not agents. Boundaries are deterministic; agents are not. Good boundaries let agents act boldly while keeping the system safe.

9. Use Agents for Everything, Not Just Code

Once you have established the habits and foundations above, apply the same pattern to everything.

Design docs that used to take a week can now be done in an afternoon. Operational investigations that used to take hours can now be done in minutes. Status updates, sprint summaries, on-call reports, and documentation all follow the same process:

Provide context, define the outcome, let the agent draft, then review and refine.

The acceleration comes from applying agents across the entire development lifecycle: planning, development, testing, deployment, and operations.

This also means you should not build an environment only for coding agents. Pipeline agents, on-call agents, documentation agents, and third-party integration agents should all share most of the same setup and context. Give them the same steering files and the same tools, so they maintain consistent behavior no matter what task they perform.

When agents are used for everything, your role rises another level. You become the designer of the entire system, not the executor of one part of the process. You define how agents collaborate, how they share context, how they hand off work, and how they are reviewed. You are building an agent work system, not just an agent.

10. Continuously Tune Your Agent Setup

Whenever an agent goes in the wrong direction, or unnecessarily pulls you back into the loop, ask yourself one question:

How do I prevent this from happening again?

The answer might be a new steering rule, a skill that records a process the agent once got wrong, a command-line tool that automates a manual step, an MCP server that collects the right context, or expanded access to a tool or system that was previously off-limits.

Every mistake and interruption from an agent is an opportunity to extend its autonomy further.

This is the new daily habit of frontier engineering: you are not just building the product; you are continuously improving the system used to build the product.

Over time, this habit compounds. At first, you only run agents after explicit prompts, and you often need to provide input. As steering and tooling mature, agents become more autonomous and can run in the background: discovering and fixing bugs, cleaning up technical debt, and improving code quality without you initiating the task.

As models improve, a new generation of agents can clean up what older models produced. When a new model is released, reevaluate whether the workarounds you built to compensate for the old model’s weaknesses are still necessary. Your steering files and tools are living artifacts, evolving as quickly as the models.

Do not set it and forget it. Keep tuning, keep compounding.

Conclusion: Frontier Engineering Is Not Vibe Coding

Frontier Engineering is not vibe coding.

It is not pasting prompts into a chat box and hoping the result is good enough. It is a disciplined, methodical practice that uses AI agents to enhance engineering rigor.

Over the long term, one key skill you will keep developing is managing your own attention.

As agents take on more execution, you need to carry the cognitive load of switching between multiple agents, consciously maintain the quality bar while everything accelerates, and resist the urge to check on agents repeatedly during dinner and late at night.

The work is deciding, again and again, what needs your attention and what does not.

We are still in the early-adopter phase of frontier engineering. Not many developers work this way yet, and the practice is still maturing. No one has fully solved how to review agent output most effectively, or how to design tools and test infrastructure for agents rather than humans.

Adopting this way of working still requires intuition: knowing what to delegate, how to scope it, and when to step in. That intuition comes from practice: the first few weeks spent writing steering files, refactoring the codebase, and learning how to break work down for agents.

Once that intuition is built, your shipping speed will increase dramatically. At that point, you can take on work that was previously out of reach: features that were out of scope, re-architecture you kept postponing, or tests and tooling you never had the capacity to complete.

From then on, the gains compound: every leap in agent capability builds on what you have already learned.

This way of working is still being defined. And the people adopting it now are the ones defining it.

Start changing how you work today.