Application

“The purpose of software is to help people.” — Max Kanat-Alexander

Context

This is a strategic pattern, the starting point for everything else in this book. Before you can talk about requirements, architecture, testing, or deployment, you need to name the thing you’re building. That thing is the application.

In agentic coding workflows, this matters right away. When you sit down with an AI agent to build something, the first question is always: What are we making? The clearer your answer, the better the agent can help. A vague idea produces vague code. A well-understood application produces focused, useful work.

Problem

People often jump straight to implementation (choosing frameworks, writing code, configuring tools) without first establishing what the application actually is. This leads to software that solves the wrong problem, serves the wrong audience, or accumulates features without coherence.

How do you define the boundaries of what you are building so that every subsequent decision has a frame of reference?

Forces

• You want to start building quickly, but premature coding leads to rework.
• An application must serve real users, but their needs may be unclear or evolving.
• Software touches many concerns at once (behavior, data, interfaces, performance, security) and you need a container concept that holds them all together.
• In agentic workflows, the agent needs a mental model of the whole to make good decisions about the parts.

Solution

Define the application as a named system with a clear purpose, a target audience, and a set of boundaries. An application isn’t just code. It includes behavior (what it does), data (what it knows), interfaces (how users and other systems interact with it), constraints (what it must respect), and operational realities (where and how it runs).

You don’t need a detailed specification on day one. But you do need enough clarity to answer basic questions: Who is this for? What problem does it solve? What is it not trying to do? These answers form the gravitational center that holds your requirements, tradeoffs, and design decisions in orbit.

When working with an AI agent, articulate the application’s identity early in your conversation or project instructions. Agents work best when they understand the whole before generating the parts.

How It Plays Out

A developer asks an agent to “build a task manager.” The agent produces a generic CRUD app with a database, a REST API, and a web frontend. But the developer actually wanted a lightweight CLI tool for personal use. The mismatch happened because the application was never defined: its audience, platform, and scope were left implicit.

Contrast this with a developer who begins by writing: “We’re building a command-line task tracker for a single user on macOS. It stores tasks in a local JSON file. It has no network features. It should feel fast and minimal.” Now the agent has a frame of reference. Every subsequent decision (file format, error handling, interface design) can be evaluated against that definition.

Consequences

Defining the application early gives every participant, human and agent alike, a shared reference point. It reduces drift, prevents scope creep, and makes tradeoff decisions easier because you can ask “does this serve the application’s purpose?”

The cost is that you must make decisions before you have complete information. Your initial definition will be wrong in some ways. That’s fine — the definition is a living document, not a contract. Update it as you learn. The goal isn’t perfection but orientation.

Related Patterns

• Enables: Requirement — requirements describe what the application must do.
• Enables: Constraint — constraints define what the application must respect.
• Enables: Tradeoff — the application’s purpose guides which tradeoffs to make.
• Refined by: Acceptance Criteria — criteria make the application’s goals testable.