Fundamentals You Still Need

A coding agent writes code fast and explains it confidently. It does not tell you when it is wrong. The knowledge that lets you catch a wrong result is the part the tool cannot supply, and it is exactly the part that decides whether the output is worth anything.

This page does not teach those fundamentals. What you need depends on your field and your stack, and it is far too broad for one page. Instead it lists the areas of knowledge that let you make best use of an agent and check what it produces, and it names, for each, the failure it protects you from. Treat it as a map of where to be competent, not a course.

The one rule underneath all of it: delegate only what you can check. When the agent hands back a result you cannot judge, the gap to close first is your own understanding, not the next prompt.

On the coding side: enough to read and check the code

You do not need to write the code by hand. You do need to read what the agent wrote and see whether it does what you asked.

• Control flow. if/else, loops, early returns. Enough to spot an inverted condition, an off-by-one, or a branch that never runs. This is where a filter silently keeps the wrong rows. See Control Flow.
• Variables, types, and scope. What a value is, when it changes, and where it is visible. Enough to catch a silent type coercion, an integer where you meant a float, or a global mutated inside a function. A wrong dtype produces numbers that look fine and are not.
• How code is organized. Functions versus objects, pure transformations versus mutable state. You do not need to prefer one style; you need to follow the data through whichever the agent chose, and judge whether the structure fits the task or just looks tidy.
• Reproducibility. Random seeds, pinned dependencies, an environment you can rebuild, no hidden state from a previous run. An agent will happily write code that works on its machine today and nowhere tomorrow. This is the difference between a result and an anecdote. See why it matters and containers.

On the analysis side: enough to check the result is right, not just runnable

Code that runs is not code that is correct. The harder check is whether the analysis answers the question and whether the numbers are believable.

• Test assumptions. Every standard test assumes something about the data, and an agent will reach for the familiar test regardless. You need to know when the assumption is violated so you can tell a correct choice from a plausible-looking wrong one.

  Test	Key assumptions	If violated, use
  t-test, two groups	roughly normal, similar variance, independent, unpaired	Welch’s t-test for unequal variance; Wilcoxon rank-sum for non-normal
  Paired t-test	normal differences, genuinely paired design	Wilcoxon signed-rank
  One-way ANOVA	normal residuals, equal variance across groups, independent	Welch ANOVA; Kruskal-Wallis for non-normal
  Pearson correlation, linear regression	linear relationship, normal residuals, constant variance, independent observations	Spearman correlation; a transformed or robust model

  Knowing the row that applies, and checking it, is the whole game. See checking assumptions and comparing two groups.

• The right method for the design. Paired data analyzed as unpaired, repeated measures treated as independent, the wrong multiple-testing correction, leakage between train and test. These are correct code running the wrong analysis. The agent cannot see your experimental design; you have to hold it.

• Plausibility. Is the effect size, the p-value, the count, the matrix dimension believable for your system? A fold-change of 400, an AUC of 0.999, a p-value of exactly zero: the agent will report these without a flinch. Domain knowledge is what flags the number that is too good to be true, usually a leak or a bug.

• Field knowledge. Units, batch effects, controls, expected ranges, what a normal result looks like in your assay. This is the least transferable and the most valuable. It is why two people running the same agent get results of very different quality.

Where this leaves you

The agent shifts the bottleneck. Writing the code is no longer the slow part; judging the output is. That judgment runs on the fundamentals above, and the tool does not provide them. Keep the agent on tasks whose output you can check, and when a result lands that you cannot check, treat that as the signal to learn the thing, not to trust the model. For the specific mistakes agents make often enough to be predictable, see Common LLM Pitfalls.