Developer Tips 2026: Lint, Types, and Tests Before the Agent

Give a 2026 coding agent one sitting and it may invent a route, a schema, and a “temporary” API key. What protects a team at that speed is not a smarter prompt but a boring gate: formatters, types, tests, and a scanner already in place before the agent opens a pull request.

I am Vishvajeet Shukla. I review Next.js and Node PRs that were half-written by tools. These tips are what I now require before an agent is allowed to touch main. They match how serious 2026 write-ups talk about assistants: tests first, then the agent, then security — because attackers use the same class of tools.

Related: Node vs Python vs Go · LangChain RAG.

Tip 1: Install the gate before the agent

A practical 2026 toolkit for TypeScript looks like this: Prettier (or the formatter your repo already runs), ESLint, TypeScript itself, a test runner, and npm audit in CI. Python people use ruff and pytest. Go people use gofmt and the built-in test command. The names matter less than the rule: nothing merges if the gate is red.

If you add Copilot, Cursor, or Claude Code to a repo with no tests, you are generating debt at token speed. Guides this year are blunt: put a real suite in place before you ask an agent to add features.

Tip 2: Make the command list one line each

Agents follow commands you write down. Put them in the README and in CI:

• npm run lint
• npm run typecheck
• npm test
• npm run build

If “test” is a script that echoes “no tests specified,” you do not have a gate. Add even ten tests around money, auth, and slug uniqueness. That is enough to catch the worst agent mistakes.

Tip 3: TypeScript is context, not fashion

Typed APIs give the model fewer ways to guess. 2025–2026 language write-ups keep tying TypeScript’s rise to AI: compile errors show up early, and annotations reduce ambiguous suggestions. For a Next.js app that means: typed route handlers, zod on the boundary, no any in the lead form. The agent can still be wrong. It is wrong in a smaller box.

Tip 4: Never let the agent commit secrets

A GitHub study quoted in 2026 spec-writing advice said the single most helpful constraint was “never commit secrets.” Put it in the agent file. Put .env in gitignore for real. Rotate anything that ever landed in a chat log. I have seen “temporary” OpenAI keys in READMEs written by a model that was trying to be helpful.

Tip 5: Review diffs like a hostile intern

Agents write plausible comments. They also delete an auth check while “cleaning unused code.” Read the diff, not the summary. If you cannot explain a hunk, revert it. Speed is worthless if you shipped a public /api/admin with no cookie check.

A Monday morning setup

1. Add lint, types, and tests to CI. Make them required.
2. Add a one-page “how we run this app” with exact versions: “Next.js 16, React 19, Tailwind 4,” not “a React project.” Specs for agents work when they name the stack.
3. Ban --no-verify in the team chat. The hook exists because the agent will skip it.
4. Run npm audit weekly. Agent-written lockfiles drift.
5. Keep a human on the merge button.

An agent is a fast junior. Juniors do not merge to production unreviewed. Neither should a model.

A story I now tell juniors

An agent once “fixed” a slow admin table by removing the permission check that loaded extra fields. The table got faster. Every logged-in user could see every org. The PR description said “performance.” The test suite did not include a second-user case, so CI was green. That is why the gate includes at least one test where Alice cannot read Bob. If you do not have Bob, you do not have a suite.

Another week, the agent upgraded a lockfile and a transitive package started logging query strings. Nobody read the changelog. npm audit had warned; someone used --force because the agent said the warning was noisy. Noise is not a reason. Read the CVE one-liner. If you cannot, do not upgrade on a Friday.

Keep a /docs/incidents.md with five lines each: what happened, which test was missing, which command would have caught it. Agents can read that file. That is more useful than another paragraph of “write clean code” in the README.

What I stop doing

I no longer paste a 400-line error into a chat and accept the first patch. I reproduce the failing test, then ask for a patch that makes that test pass. Smaller loop. Fewer surprise files. Same lesson as measuring vitals before you “optimise everything.”

How to brief the agent without writing a novel

Four bullets are enough: the user story, the file you think changes, the test name, and what not to touch. If you cannot name a test, write the test first by hand. That ten-minute test is cheaper than a 200-line hallucinated helper.

Paste logs, not feelings. “It’s broken” wastes a turn. “POST /api/contact returns 500, stack on line 42” does not. Agents are pattern matchers. Give them the pattern.

FAQ

Which coding agent is best in 2026?

The one your team will review. Cost, privacy, and whether the code leaves your machine matter more than a leaderboard. Compare those, then pick.

Do I need 90% coverage?

No. You need coverage on auth, payments, and the functions the agent keeps rewriting. Vanity percentages hide untested routes.

Can I skip TypeScript for a weekend prototype?

Yes. Do not skip it the weekend the prototype gets a domain and a client.

Is npm audit enough?

It is the floor. Add a real scanner when you handle money or other people’s data. Attackers use AI too; the window between a disclosed bug and an exploit is shorter than it was.

Where do I put these rules?

README for humans. AGENTS.md (or your tool’s instruction file) for the model. Both. The next post on this blog is about that file.

Next step

If your Next.js repo has an agent and no CI, send the package.json scripts. I will tell you the smallest gate that would have caught last week’s incident.

Contact · [e-mail] · More guides

---

Originally published at vishvajeetshukla.in. Need a developer? Hire me.