Template — a new function

the most frequent request in daily work

What it is

New functionality is what people ask an AI for most often. This request has a stable shape: name the place, describe the behaviour, draw the boundaries, set the check.

The template below is not a form to fill in but a reminder. In time you say it without thinking, but early on it is worth looking at.

What it looks like in code

The template

Where: <file or module; how the neighbouring code is built>
What: <behaviour — what goes in, what comes out>
Boundaries: <what not to do; what not to touch>
Done when: <a checkable condition>

Bad

I need a function for working with user subscriptions

"Working with subscriptions" means adding, deleting, checking and listing. The AI will choose for you, and will most likely write a two-hundred-line class with all four operations, half of which you don't need.

Good

Where: storage.py, next to load_subs(). Data is in SQLite,
connection via get_conn() from db.py.

What: a function add_sub(user_id: int, city: str) -> bool.
Adds a subscription. Returns False if that subscription already
exists, True if it was added.

Boundaries: only this function, don't touch the others.
Don't add new dependencies.

Done when: a repeat call with the same arguments returns False
and no second row appears in the table.

The result is predictable: one function, a clear signature, checkable behaviour.

What to tell the AI

What is required

The signature. The name, the arguments with their types, what it returns. This is the cheapest detail and the most useful: it removes half of all ambiguity. If you don't know what to call it, describe it in words and the AI will suggest something.

The behaviour in the unhappy case. What to do when the data isn't there, the network dropped, the argument is empty. Don't say and the AI chooses for you — and most often it chooses to return None quietly.

The boundaries. The sentence "don't touch the other functions" saves more time than anything else. Without it the AI happily "improves" the neighbouring code too, and the diff grows from ten lines to two hundred.

What is optional

There is no need to spell out the algorithm when it is obvious — that is the AI's job. There is no need to ask for a comment on every line: they clutter the code and are the first thing to go stale.

When there are several functions

Don't ask for five functions in one prompt. Ask for the first, read it, accept it — and then get the rest with one sentence: "do the same for delete_sub and list_subs". The AI picks up the style of the code you have already accepted, and checking is easier.

What to look for

The function does more than was asked. The sign: logging, caching, retries and validation have appeared inside, none of which was discussed. Not harmful in itself, but it is code you did not order and did not check.

Silent error handling. return None instead of an exception, except: pass, defaults where there should be an error. The code doesn't crash and therefore looks fine — and later you go hunting for where the None came from.

A signature convenient for the AI, not for you. Seven arguments, five of them optional, a dictionary instead of explicit parameters. If the call reads badly, rework it right away.

The function doesn't fit the project. Its own database connection instead of get_conn(), its own log format, its own naming style. Most often this is reason 2 from article 3.1: the AI simply never saw how the neighbours are built.

Cheat sheet