What is a function? (and why your AI keeps extracting them)

What it actually is

A function is a named block of code that takes some input, does work with it, and hands back a result. The inputs are called parameters, the placeholder names written into the function’s own definition. When you actually call the function, the real values you hand it are called arguments. The result it hands back comes from a return statement.

Think of a function like a recipe card. The card has a name (“Banana Bread”), a list of ingredients it expects (the parameters: flour, bananas, eggs), and a set of steps. Bring different ingredients (different arguments) and you still follow the same steps, but the loaf you get out matches what you brought. In code, the same idea looks like this:

function totalPrice(price, quantity) {
  return price * quantity;
}

totalPrice(12, 3); // 36

totalPrice is the function’s name, price and quantity are its parameters, 12 and 3 are the arguments you pass in, and 36 is the return value. The name plus the parameter list, totalPrice(price, quantity), is the function’s signature. Read left to right, a signature tells you what to hand a function before you call it: how many values, in what order, and in a typed project, what kind of value each one expects.

One mix-up worth heading off early: this code-level function shares its name with function calling, how an AI model uses tools. A model can’t run code itself: it emits a request naming a tool and the values to hand it, and the app hosting the model runs that request and returns the result. Functions are code you or your agent write; function calling is how a model asks one to run.

Why your AI just did this

Your agent reaches for functions constantly for two reasons: reuse and testing. If three parts of your app calculate a total, format a date, or validate an email the same way, writing that logic once and calling it from all three spots means one fix updates every caller. Copy-pasted logic drifts apart as each copy gets patched separately; a shared function can’t drift, since there’s only one copy to fix.

The agent also narrates this move as “extracting” code, because that’s literally what it’s doing: pulling a chunk buried inside something bigger, often a long function, out into its own named function. This has a real name in software engineering, Extract Function, one of the standard refactoring techniques catalogued by Martin Fowler. See refactoring for the wider pattern.

Functions also make code easier to test. A small function with clear inputs and a clear output can be checked on its own: feed it known values, confirm the result matches, without running your whole app.

If you build with React, you meet this idea from the other direction: components are functions. React’s own docs describe a component as a JavaScript function, one that takes props as its input and returns the markup to display as its result. When your agent writes function Button({ label }) { return <button>{label}</button>; }, label is a prop arriving as a parameter, just like price did above.

When you’ll run into it

You’ll see functions written a few different ways in your agent’s code, all defining the same kind of thing: function totalPrice(price, quantity) { ... }, or the shorter arrow form, const totalPrice = (price, quantity) => price * quantity. You’ll also meet async function, a function whose body can pause on slow work like a network request, covered in async and await.

The classic runtime error looks like this:

TypeError: document.getElementByID is not a function

That means the name you called doesn’t currently hold a function. A common cause is a typo, like calling getElementByID when the real method is getElementById. Another is calling a method that only exists on one kind of value, an array method called on a plain object, for instance.

What to check

• When an error says something “is not a function,” check for a typo in the name first (getElementByID versus getElementById is the classic mismatch), then confirm you’re calling it on the kind of value it actually works on
• Read a signature’s parameters left to right before calling it; that order is what your arguments must match
• If a function is supposed to hand back a value but nothing downstream ever receives one, look for a missing return statement
• When your agent extracts a function out of bigger code, ask it to confirm every call site that used the old inline version now calls the new function with matching arguments
• Ask for named, labeled parameters over a long list of positional values; unlabeled arguments are easy to pass in the wrong order

Say it like a dev

Instead of: “the agent broke something when it pulled that code out” Say: “You extracted calculateTotal into its own function. Can you check every place that used to have this code inline now calls it correctly?”

Instead of: “it says something ‘is not a function’ and I don’t know why” Say: “I’m getting TypeError: X is not a function on this line. Is X actually defined as a function here, or is there a typo in the name?”

Instead of: “why does it keep making a new tiny function for everything” Say: “Only pull this into its own function if we call it from more than one place, or if it makes this file easier to test.”