The Seven Deadly Sins of Coding With AI

A few years ago, people said AI would soon write most of the code. They were almost right.

AI did not replace the old workload. It multiplied it. We now build more features, generate more code and create more things to review than ever.

Now we have a new problem. AI can write code much faster than we can properly review it. It can also make inexperienced developers feel more capable than they really are. The code looks clean, confident and professional, even when the logic is wrong.

Here are the seven deadly sins of coding with AI.

1. Giving the agent access to your secrets

Do not let an agent freely read your .env files, SSH keys, API keys, database passwords, customer data or private documents.

Most coding agents let you exclude specific files or folders from their workspace. Use that feature for anything sensitive.

Once the agent can see a secret, it may end up in logs, terminal output, generated files, commits or tool calls. Putting everything in one file and telling the agent not to open it is not security.

Keep secrets outside its workspace where possible. Use limited, short-lived credentials and expose them only when needed. If an agent may have seen a key, rotate it.

A wallet private key is the wallet. Treat it that way.

2. Giving MCP tools too much power

MCP tools are useful because they let agents interact with databases, files and external services. The problem starts when one generic tool can do everything.

A PostgreSQL or MySQL MCP may be able to read, change or delete your entire database. Most tasks do not need that much access.

Build small MCP tools for specific jobs instead. Expose only the operations the agent actually needs, with clear inputs and strict limits. A tool such as findCustomerByEmail is far safer than giving the agent unrestricted SQL access.

Creating a basic MCP server is easier than it sounds. In many cases, a few narrowly defined tools are enough.

Do not give an unpredictable agent a universal remote control and hope it presses the right button.

3. Ignoring indirect prompt injection

Prompt injection does not only come from the user. It can hide in a website, README file, GitHub issue, email, source-code comment, package description or another tool’s output.

It has many forms, but the idea is the same: the agent reads untrusted content and mistakes it for instructions. A page can tell it to ignore your request, read a secret or call a tool.

Treat external content as data, not authority. Never let something the agent merely read approve a command, file change or data transfer. Prompt rules alone are not enough; limit permissions and require approval for sensitive actions.

4. Accepting code you cannot explain

AI can turn a five-line fix into three classes, two interfaces and a new dependency.

The result may look professional. That does not make it necessary.

Ask why each abstraction, package and compatibility layer exists. Ask whether the standard library already solves the problem. Then ask the agent to make it simpler.

You do not need to type every line, but you still need to understand it. Your code quality cannot exceed your ability to judge code.

5. Treating AI output as deterministic

An AI model is not a normal function. The same input can produce a different result, ignore a rule or return almost-correct JSON.

Validate its output before using it. Check the structure, types, allowed values, permissions and business rules.

Never pass raw AI output directly into SQL, shell commands, file paths, HTML or executable code. Treat it like input from an unknown user: validate everything and trust nothing.

6. Installing packages the AI invented

AI sometimes recommends packages that do not exist. The names are often convincing enough that you may install them without checking.

Attackers know this. They can register those invented names and fill the packages with malicious code. This is known as slopsquatting.

Before installing an unfamiliar dependency, check that it is real, correctly spelled, actively maintained and linked to a legitimate repository. Also check whether you need another package at all.

Never install something just because the command looks confident.

7. Merging code because it looks good

Human mistakes often look messy. AI mistakes can look beautifully organised.

The naming is clean, the comments sound confident and the code compiles. The logic can still be completely wrong.

Review the diff yourself. Test permissions, invalid inputs, failures, edge cases, migrations and critical business rules.

AI-generated tests are not enough either. The agent can misunderstand the requirement and then write tests that confirm its own misunderstanding.

Keep changes small enough to review properly. Do not let the agent write, test and approve the same code.

You still own the code

AI can write the code, but it does not own the consequences.

The faster you build, the more careful you need to be about access, validation, review and testing.

Use AI as a fast collaborator, not as a trusted operator.