AI for Writing Python Code: Specify, Test, and Review

An AI assistant can write a working Python function in the time it takes you to open an editor. The question is whether the function does what you actually need, handles the inputs you will actually give it, and fits the codebase it is going into. The answer depends almost entirely on how clearly you specified those things before the assistant started writing.

The decisions you make about how to structure Python code in a project, such as which libraries to use, how to handle errors, and how tests are organized, apply across every function the assistant writes. Tools like fenbs store those decisions outside any one chat, so each session starts from the same agreed foundation. See reviewing AI-generated code for the review side of this workflow.

Writing a useful brief for Python code

A useful brief tells the assistant what the function does, what inputs it takes and what types they are, what it returns, and what it should do when something goes wrong. Without the error handling requirement, the assistant will write happy-path code. Without the type information, it will guess.

• Function purpose: what it does in one sentence, not what you want it to produce.
• Input types and ranges: what the function accepts, including edge cases like empty lists, None values, or negative numbers.
• Return type and shape: what a successful call returns, including the type and any relevant structure.
• Error conditions: what the function should do when inputs are invalid, an external call fails, or a dependency is unavailable.
• Libraries and style: which libraries are already in the project, and any coding conventions the function should follow.

Paste the relevant existing code alongside your task description. If the function will call another function you already have, show it that function. If it will extend a class, show it the class. The assistant cannot see your codebase; everything it needs has to be in the conversation.

Specifying Python requirements clearly

Be specific about which Python version and which library versions apply. A function that uses f-strings and walrus operators requires Python 3.8 or later. A function that uses match statements requires Python 3.10. Libraries change APIs between major versions; the assistant may use the API from the version it knows best, which may not be yours.

If performance matters, say so. "This function will be called ten thousand times a second" changes the right implementation. The assistant will not optimize for performance unless you say it matters. A solution that works in a test is not always a solution that works in production.

Reviewing generated Python code

Read the generated code before you run it. Check that it uses the APIs and libraries you specified, handles the error cases you listed, and returns the type you expected. A function that compiles and runs once is not necessarily a function that handles the inputs it will see in production.

Look for the common failure modes in AI-generated Python: missing error handling for external calls, unchecked assumptions about input types, incorrect use of mutable default arguments, and synchronous code where the caller expects async. These are not rare; they appear regularly in otherwise correct-looking output.

For a systematic review approach, AI code review tools covers tools that can check generated code automatically. The AI code generators guide compares the tools you can use to write Python in the first place.

Writing meaningful tests

Ask the assistant to write tests alongside the code, not after it. A test written at the same time as the function catches specification errors: if the assistant's tests do not cover the edge cases you listed, the specification was not clear enough.

Check that the tests actually test behavior rather than implementation. A test that calls a function and asserts the function does not raise an error is not a useful test. A test that provides a specific input and asserts a specific output, including error cases, is.

Run the tests. It sounds obvious, but generated tests can have their own bugs. A test that always passes because the assertion is wrong gives false confidence. Read the test, understand what it is checking, and verify that the assertion would fail for an incorrect implementation.

Keeping implementation decisions

Python projects accumulate small but consequential decisions: whether to use dataclasses or TypedDict for structured data, how to handle configuration, which logging approach to use, how exceptions flow across module boundaries. When these are not recorded, different sessions make different choices and the codebase diverges.

Record each significant decision with its reason. "We use pathlib.Path throughout rather than os.path for consistency" is the kind of decision that prevents a future session from mixing the two. "We raise specific exception types rather than catching all exceptions at the boundary" prevents a future session from swallowing errors silently.

How to do this with fenbs

1. Create a free account. Add a Python project with the Python version, key libraries, and testing framework.
2. Record coding conventions as standing rules in Decisions and rules: error handling approach, type annotation requirements, testing patterns, naming conventions.
3. Add tasks for each function or feature to build. Attach any relevant specification notes to the task.
4. Connect your assistant over MCP from Integrations. Ask it to read the project context before each session.
5. When you make a new architectural decision during a session, record it immediately in Decisions and rules before continuing. Decisions made in chat and not recorded do not reach future sessions.