# 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-02T13:55:25Z
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://agentfactory.panaversity.org/docs/python-crash-course
generated:
  at: 2026-11-02T13:55:25Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:e1fbcb7d9a8f8b9b7cb96875022325c02c9ba4be94cef13b301cbd39a9edad85
dirty: true
ksor_version: 0.0.60
---

## The point

**If the agent writes all the code, why learn how it is put together?** Because almost every program an agent writes for you, and the code companies publish for their services, is split into many files, each with one job. Knowing that shape lets you find your way, and find where data comes in.

**What protects a program when its data changes?** A check at its **edges**, the lines where a file or another program's answer comes in. These are places in the code, not Chapter 13's edge cases. There, a schema, a written description of valid data, checks every record on every run. It stops the run with a list of every bad row. Marcus's script, below, had an edge with no check.

**What is left for me to decide?** What valid data looks like, what the program does when data is bad, and the cases each test checks, with their answers. The agent writes the code from your decisions, and you read the lines that carry them.

After this chapter you can find the edges of a program an agent wrote, and say what each edge refuses. You can also find your way around a project an agent split into files, and write down which values your data may hold. You can call another program over the web, and read code that waits for several slow answers at once.

## Why it matters

Marcus runs accounts payable for a restaurant-supply distributor in Fort Wayne, Indiana. Every Thursday a script downloads the week's invoices from a vendor portal and builds the payment file for the bank. An agent wrote the script in an afternoon, and it ran without trouble for months.

One week the portal changed one field. The amount, which used to arrive as a whole number of cents, such as `482500`, now arrived as text with a currency sign, such as `"$4,825.00"`. That Thursday the script ran as it always did, and nobody was reading it. His company checks every delivery at its loading dock, but his script checked nothing that came in. It converted each amount with a function that returns "not a number" for text it cannot read. A later line turned "not a number" into zero. The script loaded all 2,000 invoices, reported success, and wrote a payment file in which every amount was $0.00. The bank rejected nothing, because every line of the file had the right format. Forty vendors went unpaid, and Marcus spent the next week calling them.

Not one line of the script had changed since the afternoon it was written. Only its input had. Three lines at the edge of the program, saying what a valid amount looks like, would have read that input on that Thursday. They would have stopped the run before any payment file was written. The report would have started with "line 2, amount: expected a whole number of cents, got text". This chapter teaches you to look for that edge in every program an agent writes.