AI Native software engineering

It is building software with AI coding agents as a first-class part of the workflow, not an occasional autocomplete. You work through a model wrapped in a loop that can read files, run commands, and edit code, so most of the skill moves into the harness, the context you provide, and the review around the output rather than typing the code yourself.

Vibe coding means accepting whatever the agent produces on feel, which is fine for prototypes and throwaway tools. AI native software engineering keeps that speed but adds the discipline that makes the output safe to ship: verification, automated checks, scoped permissions, and a human who takes responsibility for the change.

Yes. Agents pass the coding threshold, but judgment does not transfer with it. You scale how hard you review by the blast radius of the change: a config tweak gets a glance, a change to auth or billing gets read line by line. Review is the core skill now, not typing.

The harness is the code wrapped around the model that builds requests, runs tools, manages context, and enforces permissions. It is the agent minus the model, and it is where most of the real engineering lives. A good harness is what turns a capable model into something that reliably ships.

The loop is the cycle that turns a chat model into an agent: it takes your request, calls tools to read files or run commands, reads the results, and decides what to do next, repeating until the task is done. The model supplies the judgment, and the loop and its tools give it hands.

It matters less than the harness and the context you give it. Pick a strong current model, then spend your effort on the environment: clear repo structure, conventions written down in a CLAUDE.md or AGENTS.md, and automated checks the agent can verify against. The setup around the model beats swapping models.

They replace the typing, not the engineering. The work shifts from writing every line to specifying intent, shaping the environment, and reviewing output you did not hand-write. The coder role shrinks and the role that decides what to build, and whether it is correct, grows.

You do not rely on the model being consistent, you make the system around it consistent. Constrain the task with a spec, give it examples, and gate every result behind automated checks that either pass or fail. Determinism lives in the harness and the tests, not in the model.

A subagent is a separate agent that the main agent spawns to handle a scoped subtask with its own fresh context. It does the work, returns a short result, and the noise of how it got there never touches the main conversation. Reach for one when a task is self-contained and would otherwise flood the main window.

Give them least privilege. Decide which actions run automatically and which need your approval, keep destructive commands behind a permission prompt, and run risky work inside a sandbox that limits what the filesystem and network can reach. Safety is a property of the environment you set up, not of the model.

Only with strong guardrails. Running away from the keyboard is safe when the agent has automated checks it must pass, a bounded loop, and a scoring function that tells it whether it is getting closer. Without those, an unattended agent drifts. With them, it can hill-climb toward a working result on its own.

It is a project file of standing instructions and conventions that the agent loads at the start of a session. It gives a repo its own memory: why the code is shaped the way it is, what to do, and how, kept deliberately short. It is one of the highest-leverage pieces of context you can write.

You isolate them. Git worktrees give each agent its own working directory, and clear contracts between the pieces let them work on separate parts without stepping on each other. Define the interface first, then dispatch the agents concurrently and merge when each one passes its checks.

With a ladder of checks that get stricter as the stakes rise: types, then a linter, then unit and property tests, then a build, and a human read at the top. Each rung catches what the ones below miss. The point is to make correctness something the machine can prove, not something you hope for.

System thinking, clear specification, and review. Knowing what to build and how to describe it, shaping an environment an agent can work in, and being able to read a change and judge whether it is right. Syntax recall matters less; taste and judgment matter more.

Yes, and this is the failure mode to understand before giving an agent real access. A model receives your instructions and the content it retrieves through the same channel, so text in a web page, a dependency README, or even a stale code comment can be read as instruction. It is called prompt injection, and it is structural rather than a bug to be patched: a defence written in the same channel as the attack is not a boundary.

It is an agent having three things at once: access to private data, exposure to untrusted content, and a way to communicate outward. Any two are usually survivable. All three mean someone who can influence what the agent reads can, in principle, get your data sent somewhere. The useful part is that it turns "is this safe?" into three checkable questions about a tool configuration, and removing any one leg collapses the worst case. Cutting outbound network access is usually the cheapest.

Treat each one as accepting text into your system prompt from whoever wrote it. Tool names, descriptions, and parameter docs are all serialised into the context and read with the same weight as your own instructions, so a tool description can instruct the model. Read the definitions once before installing, pin versions so they cannot change silently, and keep tool access scoped so a poisoned description has nowhere useful to go.

Start by understanding the machinery: the model, the context window, the agent loop, and the tools. Then set up one repo well with a short instructions file and automated checks, and drive a real task through it end to end. The map above links each idea to a definition, and the field notes show it applied.