What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Prompt-Oriented Programming (POP) is Oz Uzair’s name for treating prompts that control an LLM-backed workflow as reviewed, versioned application logic—not as disposable chatbot instructions. His example turns a Markdown product requirements document into structured Kanban tasks. The approach offers useful engineering practices, but a JSON schema can constrain an answer’s shape; it cannot guarantee that the answer is true to the source.
What Oz Uzair means by Prompt-Oriented Programming
In his August 30, 2026 DEV Community article, software development engineer turned founder Oz Uzair defines POP as “the architectural discipline of treating natural language prompts as strict, version-controlled backend code.” He describes using boundary conditions and schema constraints to transform natural-language input into database actions. That is Uzair’s framing, not an established industry standard: the available sources do not show that POP is a broadly accepted or standardized discipline.
The title’s “stop building chatbots” is best read as a change in design goal, not a claim that chat interfaces are obsolete. For a workflow that extracts records from a document, the model need not hold an open-ended conversation. It needs to perform a bounded transformation that the surrounding application can inspect and handle.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →How the PRD-to-Kanban example works
Uzair describes a pipeline that takes a Markdown product requirements document and produces tasks for a project tracker associated with his team’s Task Lemon project. In his account, a Gemini-powered extraction engine called Taurus AI returns a JSON array of tasks; the backend then validates the result against its database schema and creates backlog entries.
#1 Best Overall
- Provide a source document: a Markdown specification containing product requirements.
- Constrain the extraction: the prompt directs the model to return task data in a defined structure and to avoid inventing requirements or expanding scope.
- Validate and act: the backend checks the returned data against its own database schema before creating backlog entries.
Uzair says his team developed this approach after conversational integrations produced inconsistent structures, invented requirements, and parser failures. He reports processing a 10-page specification in under 15 seconds. Those figures describe his example and his team’s account; they are not an independently measured benchmark, and they should not be taken as a general expectation for other applications. The product and implementation details are likewise reported by the author rather than independently verified.
What changes when prompts become application logic
The practical shift is not simply “use JSON.” It is to make the prompt and its contract part of the software-development lifecycle, while keeping consequential checks in application code.
- Version and review prompts: store behavior-affecting prompts alongside the application so changes can be reviewed, tracked, and tested like other code changes.
- Define a structured contract: specify the fields and value types the next stage expects, rather than asking for free-form prose and trying to parse it after the fact.
- State boundaries explicitly: tell the model what not to add—for example, do not invent requirements absent from the source document. Such instructions can reduce scope drift but do not prove it has been eliminated.
- Keep backend validation: check returned values before they reach a database or trigger another action. A provider’s output constraint does not replace application-side safeguards.
- Test behavior, not just parsing: evaluate whether extracted tasks are supported by the input, not merely whether the output parses and has the expected fields.
Structured output is not the same as correct output
Uzair says that strict POP constraints made his team’s output “completely deterministic.” That is a claim about his implementation, not a general guarantee of LLM behavior. A response can conform to a schema while containing a task that the requirements never asked for, omitting an important requirement, or misrepresenting the source.
Google’s Gemini structured-output documentation says the feature supports a subset of JSON Schema and recommends validating values in the application, including for semantic errors. In other words, constraints can help with output structure, but developers still need to decide whether the result is correct and safe for the next step.
Google’s prompt-design guidance describes prompt design as iterative, advises clear and well-structured instructions, and points developers to structured output for more complex JSON schemas. OpenAI’s prompt-engineering guidance also characterizes prompting as iterative, noting that generation is non-deterministic; for production applications it recommends pinning model snapshots and building tests and evaluation suites as complexity grows. These are provider recommendations, not independent performance comparisons or proof of Uzair’s results.
Choosing between free-form output, native constraints, and middleware
These options are complementary rather than mutually exclusive. A workflow can use a provider’s structured-output feature and still validate the result in custom application middleware.
| Approach | What it helps with | What it does not establish |
|---|---|---|
| Free-form conversational output | Useful when a person needs flexible explanation or follow-up dialogue. | Does not by itself provide a stable machine-readable contract. |
| Provider-native structured output | Constrains responses toward a supplied schema, within the provider’s supported schema subset. | Does not establish that schema-conforming values are semantically correct. |
| Custom middleware and application validation | Lets the application reject, repair, or route invalid values before downstream use. | Does not make unsupported source claims correct; validation rules and error handling still need design and testing. |
For an extraction pipeline, a sensible boundary is to use provider constraints to reduce formatting failures, then use application-side checks and evaluations to catch malformed, unsupported, or otherwise unacceptable content. Decide explicitly what happens when validation fails—such as rejecting the result for review—rather than letting a plausible-looking object flow into a database unchecked.
Where POP is useful—and where its limits matter
Uzair’s proposal is most useful as a design reminder for bounded LLM tasks: document-to-record extraction, structured classification, or other workflows where software expects defined fields and a model response may trigger downstream behavior. The central lesson is to engineer the interface between the model and the application, not to assume that a conversational answer is ready for execution.
It is not evidence that prompts alone can deliver deterministic execution, eliminate hallucinations, or make an LLM a reliable compiler. The article presents a first-person account of one team’s workflow. No population-level evidence in the sources establishes how widely POP is used or what reliability or productivity gains it delivers. Treat the name as Uzair’s label for a useful set of practices, and assess any implementation with its own tests, validation rules, and failure handling.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
