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.

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.