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.
