# Chapter 14. Structuring Programs in the AI Era: Objects, Data and Async (/building-ai-workers/structuring-programs/overview)

---
type: Document
title: "Chapter 14. Structuring Programs in the AI Era: Objects, Data and Async"
description: "Read and review the structured code agents and SDKs produce, in TypeScript and Python: modules, types you write down, classes and objects, schemas, errors as design, JSON and REST APIs, async and await, and SDK-shaped code."
status: stable
order: 314
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-09T15:49:29Z
chapter: "14"
part: III
expert_status: builder-only
objectives:
  - { id: CCDV-F.D2.S4, label: supporting }
  - { id: CCDV-F.D5.S2, label: supporting }
word_budget: 10000
prerequisites: [ "01", "02", "03", "04", "05", "06", "07", "08", "09", "10", "11", "12", "13" ]
build_step: "Invoice and Vendor models with schema validation, a loader that reports every bad row, and a small async client for a local sample AP API, in TypeScript and in Python, each with tests, then one tests-first change ported to Codex and OpenCode"
artifact: "brightline-ap with src/schemas.ts and py/brightline_ap/schemas.py, the loaders, the API clients and their tests, the zod, pydantic and httpx dependencies with lock files, NOTES.md and ports/ch14.md, branches remit-tests, port14-codex and port14-opencode, tag ch14"
lab_data: "https://github.com/panaversity/agentfactory-v2-resources/releases/latest/download/brightline-lab-ch14.zip"
field_guides: [ "E.code-toolchain" ]
delta_entries: []
concepts: [ "14.1", "14.2", "14.3", "14.4", "14.5", "14.6", "14.7", "14.8", "14.9" ]
last_verified: 2026-10-30
sources:
  - id: panaversity-python-crash-course
    title: "Python in the AI Era (the first edition's course) (Panaversity, accessed 2026-10-30)"
    resource: https://agentfactory1.panaversity.org/docs/python-crash-course
generated:
  at: 2026-11-09T15:49:29Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e
dirty: true
ksor_version: 0.0.60
---

## The point

**What does a program an agent builds for you decide without you?** What it lets in. Is a credit, an amount below zero, a mistake? Does one bad invoice hold up every payment? Who is told? How long does it wait for a slow answer? A program settles these at its **edges**, the places where data comes in from outside. These are places in the program, not the edge cases of [13.10](../programming-fundamentals/judgment.md). Today's agents often write a check at each edge without being asked. If you know what a check can do, you set its rules. If not, the agent sets them, from the first day's data.

**Where do I set those rules?** Mostly before any code exists, in your brief, as in [Chapter 13](../programming-fundamentals/overview.md). Say where each kind of data comes from and what a bad record must do. Your "Done when" can name the cases the first week's data will not have: "Done when a credit lowers that vendor's payment, and a bad amount stops the run with a list of every bad invoice."

**What does an edge not catch?** A wrong value in the right shape. `48250`, where `482500` was meant, is still a whole number of cents, so it passes ([14.4](data-models-and-schemas.md#what-can-a-schema-not-check)). Your count and total ([12.1](../agentic-coding/from-chat-to-coding-agent.md)) and your tests ([13.9](../programming-fundamentals/tests-first.md)) still matter.

After this chapter you can plan a program of several files with a coding agent, in TypeScript or Python. You can say where its data comes in, what each edge refuses, and what a bad record does. You can plan a call to another company's service: what to send, how long to wait, and when to try again. And you can find your way around a project an agent split into files. Use the tabs to pick one language, and follow it through the lessons. The lab uses both.

## Why it matters

Marcus runs accounts payable for a restaurant-supply distributor in Fort Wayne, Indiana. Every Thursday a script downloads about 2,000 approved invoices from a vendor portal and builds the payment file for the bank: 40 vendors, about $6 million in all. An agent wrote the script in an afternoon and, without being asked, added a check at the edge: each amount must be a whole number of cents, such as `482500` for $4,825.00, and more than zero. The script ran without trouble for months.

One Thursday a poultry supplier sent a credit for $450.00, money it owed back for a short delivery. The portal listed it among the week's invoices, as an amount of `-45000`. The check refused it and stopped the run: "amount -45000 is not a positive whole number of cents". No payment file was written. About $6 million waited on a $450.00 credit, while Marcus worked out what the program should do with it.

The agent had chosen "more than zero" from the first week's data, which held no credits. Marcus knew that a credit lowers what his company owes that vendor. One sentence in his brief would have said so, and his "Done when" could have tested it. So how do you decide what a program lets in, before it runs without you?