AI-assisted coding in the terminal — 8 things that need to be in place

We recently walked through this with a customer team. These eight controls should be in place before an agent runs on autopilot — and why this is a company risk, not only a developer habit.

1. Do not trust a single language model

Use two models against each other: one writes the plan and the code, the other reviews it before anything is implemented. Asking a salesperson how the week went and hearing “great” is not the same as asking whether they called anyone. Models do not challenge their own work by default. They will challenge each other if you make that the job.

In practice one model writes the plan and the code. The second model only reviews the plan before a line is written. It adds a few minutes per task and cuts the repair loops that actually burn tokens and time.

2. Pick the model for the job, not from habit

Models really do differ. Finnish copy and code comments show it clearly. Coding is the same: one model is stronger on architecture, another on debugging. Forcing one model onto every task is like asking the bookkeeper to do the sales work as well. It can work. It is not the best way.

3. Never expose API keys or .env files to the terminal

This is where most of the damage happens. When an agent runs in the terminal and reads environment variables or .env files directly, every key is in the agent’s hands — and in every request that passes through it. If someone injects hostile instructions into the agent (see point 6), they do not need to break in. They ask politely. The key is already there.

By default no model warns you in advance that it is about to use your licences or keys in a way you would not like.

4. Use a password manager and an SSH agent — not keys on disk

The fix for point 3 is simple: a vault such as 1Password, used with an SSH agent over the CLI. The terminal never sees the password or API key in clear text. The agent asks the vault for a one-time grant. Nothing sits on disk or in command history.

It also gives you an audit trail of who used what and when — the same idea as keeping vouchers for the accounts. Keys live in one vault, not in notes or Google Drive.

5. Put everything in GitHub — context, not only code

An Agents.md file, a work log and commit history in GitHub mean every change is traceable: who did it, what they did, and where the keys were at the time. That is not a developer convenience. It is what you need if you later have to reconstruct what happened.

6. Do not use auto-approve or YOLO mode without reading the code

If the agent commits or runs commands without anyone reading the diff, you notice a prompt injection only when it is too late. This is not theoretical. In summer 2026 a hidden prompt injection in web content made an agent we know of try to reach Google credentials — because the page text included an instruction aimed at the agent, which no human saw before the agent had already acted on it.

If the agent suddenly asks for permission to do something you did not request — stop. Do not approve it.

7. Remember that memory does not sync between models

An Agents.md file or similar context file does not move automatically from one model to another when you switch mid-project. That sounds like a technical detail. The business consequence is slower work and a higher chance the agent does something it no longer “remembers” was forbidden. Keep context in version control, not in one model’s memory.

8. Keep the basics in place — they are still the largest risk

About 95% of WordPress site break-ins still happen through outdated plugins, not exotic AI attacks. Automatic backups, two-factor authentication, login throttling and current updates still stop most of the attempts. Sites are probed in the hundreds every day whether they have traffic or not. Read WordPress plugin vulnerabilities and the website security checklist.

Regulation follows the same pattern. If your company sits in a supply chain that serves a critical operator, cybersecurity duties can reach you as a supplier even when you are not directly in scope. In Finland that is NIS2; elsewhere the legal label differs, but the supplier question is the same. See the small-business cybersecurity guide.

Why this is not only a developer problem

AI agents have made coding faster than ever. They have also made one badly configured terminal the weakest link in the company’s security. The same logic applies to a website: on cheap hosting, updates, backups and monitoring stay on you — exactly the risks listed above.

When we analyse sites before a move to ResaHost we keep finding the same things: outdated plugins, public admin usernames and backups that are months old. See our 2026 audit study, which reviewed 209 retained reports and listed 20 statistical findings on the actual state of the sampled sites. That work belongs in WordPress maintenance and firewall and monitoring, not in a terminal YOLO mode.

Summary

AI speeds the work up sharply. Every key you give an agent without supervision is a key you also give to anyone who can reach that agent. Build the process so that no single mistake — yours or the model’s — becomes a disaster: two-model review, keys in a vault, auto-approve off, and the basics (updates, backups, firewall) in place no matter how modern the rest of the toolkit is.

Is your website maintenance and security in place regardless of who writes the code — a person or an agent? Talk to ResaHost or see the plans.