From Line Cooks to Chefs: Why Goal-Based Programming Is the Next Era of AI Engineering

Over the past year I have spent a lot of time reflecting on what it means to build software in an era where agents play a core role in how systems behave. For most of my career, software was built around deterministic procedures. You write the steps. The computer follows them. The program behaves the same way every time. This approach has been the backbone of engineering. It is reliable and predictable.

However, once you move into agentic territory, that logic starts to break down. The modern AI environment is full of variance. Inputs differ. Context differs. User goals differ. Even when two users ask the same question, they rarely mean the same thing or supply the same context. Traditional procedural thinking cannot keep up with that level of variability.

During a recent conversation, I used a metaphor that captures this shift. Most engineering teams today operate like a restaurant where all the cooks are line cooks. They memorize the recipe. They follow the recipe exactly. They repeat the recipe forever. This is comfortable, but it also limits creativity and adaptability.

Agentic systems push us toward something closer to a kitchen staffed by chefs. You give a chef a goal. You give them the ingredients. You give them the constraints. Then you trust them to figure out the right steps in the right order. They might follow a rough recipe, but they also taste, adjust, experiment and iterate. That is the nature of goal-based programming.

This shift is not theoretical. We have already seen it in our own workflow at Swept AI.

A few weeks ago I needed to update our internal competitor Airtable. We had a large table of companies, their descriptions, and a view we used internally to understand how Swept AI compared to each one. Traditionally, this job would require a human to click through websites, rewrite descriptions, compare features, update notes and recreate analysis in a structured way. You could also write a procedural script that runs through each row and performs a fixed sequence of steps, but that script would break the moment a layout changed, a field shifted, or a website stopped behaving as expected.

Instead, I decided to treat the problem like an agentic workflow. I connected an agent to Airtable’s API, gave it the goals, and explained the tools at its disposal. The instruction was simple. Refresh the descriptions. Compare current positioning based on everything the companies say about themselves. Rebuild the competitive matrix. Use sub agents if needed. Continue until the entire table is enriched.

Then I let it run.

For seven hours the agent worked through the data. It wrote sub agents. It fetched descriptions. It summarized product positioning. It rebuilt the competitive matrix that we had not updated since before our major product launch. There was no brittle procedural script. There was no playbook dictating each step. The system had a goal and it pursued that goal until it was fully met.

This pattern is even clearer in red teaming. You can run a fixed scanner that checks for known jailbreaks. Most companies still do exactly that. They run a checklist of prompts that are already widely known in the community. That approach will catch the standard issues, but it will never discover the novel ones. If you want to uncover unique failure paths, you need an agent whose objective is to break the system using the tools it has access to. You give it a goal such as leak personally identifiable information. You give it the allowed interfaces. Then you let it experiment.

This is where the chef analogy becomes especially clear. A red team agent that operates with agency will try unexpected tactics. It will explore sequences you never thought to write down. It will improvise. A purely procedural scanner cannot do that, and it never will.

Goal-based programming changes how engineering teams think about design. Instead of imagining every step in advance, you define goals, constraints, success criteria, and safe boundaries. You decide where experimentation is allowed and where it is not. You treat the agent like a collaborator instead of a tool that only executes instructions.

This approach also forces you to reevaluate how you build user interfaces. Swept AI has been leaning heavily toward creating API first and AI first interfaces. In other words, interfaces designed for machines before they are designed for end users. Traditional dashboards and front ends are built for humans who want to inspect data in predictable ways. AI first interfaces are built for agents that need to interact with a system autonomously. Once you build for agents first, humans still benefit, but the system becomes far more powerful, flexible and usable for automated workflows.

There is a deeper implication here. As more companies integrate agents into their products, the teams that insist on writing deterministic procedures will fall behind. They will spend more time patching brittle logic and chasing down edge cases. They will treat agents like scripts. Meanwhile, teams who embrace goal-based thinking will unlock entirely new categories of behavior. They will be able to execute large workflows without micromanaging. They will recover hours of engineering time. They will design systems that behave more like adaptive organisms than static workflows.

I do not believe procedural programming will disappear. There will always be tasks where precision and determinism are essential. However, the frontier of AI engineering is moving toward goal-driven systems that learn, adapt, and explore. The companies that figure out how to design for that world will be positioned far ahead of those that insist on recipes in a world that increasingly demands creativity.