At the beginning of 2026, AI coding tools had crossed an important line.

They were no longer just autocomplete. They could write real features, move around a codebase, debug build errors, reason through deployment problems, and take a vague product idea surprisingly far.

But there was still a more interesting question:

Could AI help build an actual production application?

Not a landing page. Not a toy demo. Not a vibe-coded prototype that works once on localhost and falls apart the moment a real user touches it.

A real product, with accounts, data, imports, SEO, public pages, deployment, edge cases, and enough polish that it felt like software instead of an experiment.

That was the real question behind Save.Cooking.

I wrote the original launch post as a holiday tech support story. Six months later, the more useful version is not really about recipes. It is about what AI was good at, where it was misleading, and what the project taught me about the future of software development.

The project started with a small real problem

The original problem was simple: my parents had years of recipes trapped in MasterCook, an old recipe application that was being decommissioned. They needed a way to move that archive somewhere else.

That could have been a utility script. It could have been a one-time migration. Instead, it became a full recipe-management app because AI made the cost of building the bigger version feel dramatically lower.

That is one of the first lessons.

AI changes the perceived cost of trying things. When implementation feels cheaper, bigger ideas become tempting. Sometimes that is great. Sometimes it is dangerous.

Save.Cooking became a useful proof point because it went far beyond the “make me an app” demo. It had legacy imports, public recipe pages, user accounts, search, recipe browsing, sharing, structured content, and a Chrome extension for saving recipes from other sites. It looked and behaved like a real product.

But the more interesting question is not “what features did it have?”

The more interesting question is: which parts did AI actually help with, and which parts still required human judgment?

AI was excellent at implementation drag

The biggest win was momentum.

A production app is mostly the boring middle: weird data formats, metadata, fallbacks, layouts, permissions, routes, configuration files, deployment failures, and the hundred small details that make the difference between a demo and something people can use.

AI was genuinely helpful there.

A good example was the MasterCook import problem. MasterCook’s export format was not a clean, well-documented modern API. It was an old file format that needed to be inspected, guessed at, parsed, tested, and mapped into a database-oriented structure.

That could have become a deep manual time sink. Instead, the AI could open the files, look for patterns, infer the structure, write parsing code, test assumptions, and iterate until the recipes imported correctly.

That is exactly the kind of work where AI feels like magic. Not because it has product taste, but because it is willing to grind through the messy mechanical parts faster than a human wants to.

The same was true for a lot of SEO plumbing.

With the right prompting, I could push the AI into implementing things like structured recipe data, clean HTML, alternate markdown-style recipe formats, Open Graph metadata, canonical URLs, and even the small operational files like robots.txt that help search engines understand what to crawl.

Those are not glamorous features. They are also not optional if the goal is a public content-driven application.

AI made them cheap enough to do.

But AI did not magically know what “good SEO” meant

This is where the nuance matters.

If you naively ask an AI system for “SEO,” you will usually get shallow advice: use headings, write good titles, add keywords, make sure the page has structured HTML.

That is not wrong, but it is not enough.

For a recipe site, real SEO includes things like Recipe schema, canonical pages, social metadata, crawl behavior, internal linking, public indexable pages, image metadata, and content formats that machines can understand. You need to know enough to ask for those things, or at least to recognize them when the model points in that direction.

The AI was helpful once the target was clear. It was much less useful when the target was vague.

That is a pattern I keep seeing with AI software work. The model can produce a lot of code, but the quality of the result depends heavily on whether the operator knows the language of the domain.

You do not need to personally write every line anymore. But you still need enough background to ask for the right system.

AI was too optimistic about the business

The part AI did not help with was strategic judgment.

It never really pushed back on whether a recipe website was a good business idea.

And in hindsight, that is the obvious weak spot.

In the age of AI, why does someone need a recipe website for many everyday cooking use cases? If you need a Caesar salad for two people, you can ask ChatGPT, Claude, Gemini, or whatever assistant is sitting on your phone and get a custom answer instantly.

The entire category of recipe websites is getting squeezed from multiple directions: search changes, AI answers, Pinterest fatigue, ad overload, and the fact that on-demand generation is often more convenient than browsing.

That does not mean recipe tools have no future. But it does mean the default “recipe site with public pages and SEO traffic” strategy is much less attractive than it used to be.

AI did not steer me away from that.

It was happy to help build the thing. It was not especially good at saying, “This category might be structurally declining, and the business case is weaker than the implementation plan makes it feel.”

That distinction matters.

AI can make the cost of building something much lower. It does not automatically make the thing worth building.

The human job moved up a layer

The real lesson from Save.Cooking is not that AI can write code. That part is increasingly obvious.

The lesson is that AI can tackle meaningful software problems, but the operator still needs to know what to ask for, what to inspect, and what “good” looks like.

A non-technical person can absolutely get further than ever before. That is real. AI can fill in gaps, explain concepts, write scaffolding, and produce working software from plain-English direction.

But production code contains a lot of “you don’t know what you don’t know.”

Security. Data modeling. SEO. Deployment. Background jobs. Auth. Permissions. Crawlability. Performance. Observability. Error handling. Content formats. Migration paths. Maintainability.

If you do not know those categories exist, you may never ask for them. If the AI gives you a plausible answer, you may not know whether it is actually right.

That is why software engineering experience still matters. Computer science still matters. Product judgment still matters. The value moves from typing code to directing systems.

This is also why I have been thinking more about agentic-first development. As agents become more capable, the bottleneck becomes less about whether a model can implement a function and more about whether a human can structure the work, define the right boundaries, and keep the system coherent.

The codebase got bigger than one person should want

There is another uncomfortable lesson here.

AI can generate an order of magnitude more code than one person would normally choose to write and maintain.

That sounds like productivity. And it is.

But it also creates a new maintenance problem.

If one person can produce the surface area of a small team, someone still has to understand that surface area later. Someone has to debug it, refactor it, secure it, migrate it, update dependencies, handle production issues, and decide what should be removed.

In a world where AI keeps accelerating software creation, I do not think we need fewer software engineers.

We may need more of them.

Not necessarily more people typing boilerplate from scratch, but more people who can keep AI-built systems working. More people who understand architecture, tradeoffs, debugging, production reliability, and how to translate a business problem into the right technical shape.

The job changes. It does not disappear.

Six months later

Looking back, Save.Cooking feels like a snapshot of a specific moment in AI development.

At the time, building a full-stack product this way felt like a frontier experiment. Six months later, the tools are already better and the expectations are higher.

The takeaway is not “everyone should build a recipe app.”

The takeaway is that AI can now absorb a massive amount of implementation drag. It can reverse engineer old formats. It can scaffold real products. It can implement complicated technical requirements when the operator knows how to describe them. It can help a single builder push far beyond what would have been reasonable a few years ago.

But it still needs direction.

It still needs judgment.

It still needs someone who knows when the answer is plausible but shallow, when the architecture is getting messy, when a feature is technically correct but strategically pointless, and when the business problem has changed underneath the software.

Save.Cooking may have started as a recipe project, but the real experiment was bigger than recipes.

It was a test of what happens when AI turns implementation from the bottleneck into raw material.

That is powerful. But it makes taste, experience, and technical judgment more important, not less.

Most software teams are about to run into a weird problem: they are going to ask for “agent support” and nobody is going to know what that means.

Not the product manager. Not the developer. Not even the AI model doing half the implementation.

The word agent is still too fluid. Sometimes it means a chatbot. Sometimes it means a background job with an LLM call in the middle. Sometimes it means a coding assistant with tools. Sometimes it means a workflow that can make decisions, call APIs, and keep going without a human clicking every button.

That makes it hard to build software for agents.

If you tell a coding agent, “make this more agentic,” you will often get something vague. Maybe it adds an API endpoint. Maybe it adds a prompt. Maybe it writes a README. Maybe it creates a single hard-coded instruction like “analyze this data and return insights.”

That is not enough.

The better question is more practical:

How would an agent actually use this feature five minutes after it was built?

That question changes the development loop.

The old loop is too human-centered

Most application development still assumes a human user.

You build a feature. You open the browser. You click around. You see if the form works. You check the page. You fix the obvious bugs. Eventually you may add API endpoints, documentation, admin commands, or automation hooks around the edges.

That works if the primary user is a person with a screen, patience, and enough context to infer what the software is supposed to do.

Agents are different.

An agent does not “just know” that the button in the top-right corner starts the workflow. It does not automatically understand which endpoint is safe, what order commands should run in, which fields are optional, or how to recover from a partial failure.

A human can poke around and build a mental model.

An agent needs that mental model handed to it.

That is why building AI-operable systems is not just about exposing a few commands. The software has to be shaped so an agent can discover it, operate it, verify its work, and recover when something goes wrong.

Agentic-first development means testing with an agent immediately

The loop I have been using is simple:

1. Build the feature.
2. Build the API, CLI command, or skill that describes how an agent should use it.
3. Ask an agent to use the feature immediately.
4. Watch where it gets confused.
5. Improve the feature, the interface, and the skill together.

The important part is timing.

Do not wait until the feature is “done” and then bolt agent support onto it later. The best feedback happens while the implementation context is still fresh. The model knows what was just built. The developer knows what tradeoffs were made. The rough edges are still visible.

So after a feature lands, ask the agent something like:

Use the feature you just implemented as if you were an agent trying to complete a real task. Do not explain how it should work. Actually exercise it. Tell me where the interface, API, command output, docs, or skill file made your job harder.

That prompt surfaces a different class of bug.

Not just “does the endpoint return 200?”

More like:

• Could the agent find the right command?
• Did the command output include enough context?
• Was the failure mode understandable?
• Did the skill explain the safe path?
• Was there a dry-run option before a destructive action?
• Did the agent know how to verify success?
• Did the API require hidden knowledge from the developer’s head?

That is the kind of feedback normal QA often misses.

The skill is part of the feature

This is the part that took me a while to appreciate.

If an agent is going to use your software, the skill file is not documentation after the fact. It is part of the product surface.

A human-facing feature might include:

• UI
• copy
• error messages
• onboarding
• docs

An agent-facing feature needs its own equivalent:

• tool descriptions
• command examples
• safe operating rules
• expected outputs
• verification steps
• known pitfalls
• recovery instructions
• examples of good and bad usage

That context is not decorative. It is how the agent becomes competent.

This is the same pattern behind bring your own agent. The useful part is rarely one magical prompt. The useful part is the accumulated operating system around the work: the tools, memory, examples, rubrics, and habits that let an agent perform reliably in a specific environment.

So when you build a feature, build the skill at the same time.

If the feature has an admin command, the skill should explain when to use it, which flags matter, what a successful result looks like, and what to do if it fails.

If the feature has an API, the skill should show real request and response examples.

If the feature triggers background work, the skill should explain how to check job status, inspect logs, and retry safely.

If the feature can modify production data, the skill should include dry-run behavior and warnings.

The skill is the agent’s onboarding document.

Write it like the next user has no memory of the conversation that created the feature. Because usually, that is exactly what will happen.

Fresh-context testing is where this gets useful

The first version of this loop can happen in the same chat where the feature was built.

That is useful, but it is not enough.

The agent that just wrote the feature has a huge amount of implicit context. It remembers the architecture discussion. It remembers the files it edited. It remembers the assumptions. It may know how to use the feature because it just created it.

A real future agent will not have that advantage.

A better test is to create an isolated subagent and give it only the skill plus the repo or application access it would normally have.

Then ask it to complete a task.

For example:

Spawn a fresh subagent. Give it the new skill and no extra explanation. Ask it to use the feature to accomplish a realistic task. Report where it got stuck, what context was missing, and what would have made the skill easier to use.

That isolation is valuable.

It simulates the reboot problem. It shows what happens after the development context disappears and all that remains is the actual product surface you created for agents.

If the subagent can use the feature from the skill alone, you probably have something durable.

If it cannot, that is not a failure of the agent. That is product feedback.

Build the context harness, not just the prompt

There is a second side to agentic-first development: building software that contains agents as features.

This is where the terminology gets even less helpful.

If you ask a coding agent to “add an agent that audits this data,” it may create a function with a prompt like:

Analyze this data and return recommendations.

That is not an agent. That is a sentence.

A useful internal agent needs the same thing a new employee would need: context, instructions, examples, constraints, access to the right data, and a definition of good work.

The framing that works better is this:

Build this as if we are delegating the task to a smart junior employee who is new to the company. Give them enough context to act like a senior employee. Do not be afraid of a large prompt. Use dynamic, templated context pulled algorithmically from the application where possible.

That produces a different implementation.

Instead of a tiny hard-coded prompt, you start building a context harness:

• current user or account context
• relevant records from the database
• recent activity
• available tools and actions
• policy or brand rules
• examples of high-quality output
• domain-specific terminology
• constraints and safety rules
• scoring rubric or acceptance criteria
• exact output schema

Some of that context should be static. Some should be templated. Some should be pulled from the application at runtime.

The important distinction is that context assembly should be mostly algorithmic, not another vague agentic step. The software should know where to retrieve the account details, prior activity, relevant documents, and configuration. Then the LLM receives a rich work packet instead of a bare instruction.

Modern LLM context windows can hold a lot. That does not mean you should dump everything in blindly, but it does mean developers should stop being afraid of giving the model enough information to do the job well.

A one-sentence prompt is rarely delegation.

It is more like shouting a task at somebody as they walk past your desk.

Treat agents like employees, not magic functions

The employee analogy keeps helping.

If you hired a junior employee and said, “audit this customer account,” you would not expect great work unless you also gave them:

• what the company does
• what the customer is trying to accomplish
• what tools they can use
• what good and bad accounts look like
• where to find the data
• what risks to watch for
• what format the answer should take
• when to escalate

Agents need the same treatment.

This does not make them human. It just gives developers a better abstraction.

A function needs parameters.

An agent needs context.

A function returns a value.

An agent performs work against a goal, using judgment inside constraints.

If you build the feature as if the agent were a function, you tend to under-specify the work. If you build it as if you were delegating to a new employee, you naturally include the missing context.

That is the difference between “LLM integration” and an actually useful agentic feature.

Two kinds of agentic-first software

There are really two related ideas here.

The first is software an agent can use.

That means APIs, CLI tools, skills, structured outputs, safe commands, dry runs, logs, and verification steps. It means the application is operable by an AI assistant in the same way it is operable by a human.

The second is software that uses agents internally.

That means LLM-powered audits, cleanup jobs, recommendations, workflows, summaries, monitors, and decision-support features. It means the application itself can delegate pieces of work to model-driven components.

Those are different design problems, but they reinforce each other.

When you make a feature easier for an external agent to operate, you often make it easier for your internal agents to call safely too. When you build richer internal context harnesses, you often expose clearer concepts that external agents can use.

This is where agent teams and adversarial review loops become more than a creative workflow. The same idea can apply inside software development: one agent builds, another exercises, another reviews, and the product improves because the agents are forced to use the thing rather than merely describe it.

What this looks like in practice

A practical agentic-first feature might ship with a checklist like this:

1. Human UI works.
2. API endpoint exists.
3. CLI command or tool wrapper exists.
4. Command output is structured and includes enough context.
5. Errors include recovery suggestions.
6. Destructive actions support dry-run.
7. A skill explains how and when an agent should use the feature.
8. A fresh subagent can complete a realistic task using only that skill.
9. The built-in LLM prompt uses a rich context harness, not a one-line instruction.
10. Verification steps prove the work succeeded.

That checklist is not complicated.

But it changes what “done” means.

Done is no longer only “a person can click it.”

Done becomes “a person can click it, an agent can operate it, and the application’s own agents have enough context to use it intelligently.”

The terminology will catch up later

Right now, everyone is still inventing words for this.

Agentic support. AI-native software. Agent-operable systems. LLM-powered workflows. Human-in-the-loop automation. Delegated intelligence.

The names are messy because the category is still forming.

That is why the practical loop matters more than the vocabulary.

Build the feature. Build the skill. Ask an agent to use it. Isolate the test. Watch where it fails. Improve the interface and the context harness. Repeat.

That loop creates better software even if nobody agrees on the perfect terminology.

The applications that win in the next phase will not just have AI sprinkled on top. They will be designed around the reality that some users are human, some users are agents, and some features are agents doing work on behalf of both.

That is what agentic-first development means in practice.

Not “add an agent.”

Build the application so agents can understand it, operate it, and meaningfully participate in the work.