I’ve spent 40 years in tech (in roles including support, community, and product marketing), but I’ve never been a coder. I’ve worked closely with software engineers doing user experience testing and writing documentation, and I’ve done various kinds of tech marketing. I’ve designed simple web apps and done other coding-adjacent tasks like context-sensitive help, and I’ve dabbled a little in HTML and CSS — but that was the sum total of my coding experience.

Until now.

First steps

For family reasons, I’ve become curious about how I could use AI for personal projects. I started small: Years ago I scanned hundreds of personal letters and papers, using a consistent filenaming scheme: [initials of sender] [day] [month] [year] [page number]. Now as I finally begin using these files, I realize this scheme does not help get things into chronological order – I should have used [initials] [year]-[month]-[day] [page number]. 

Manually renaming hundreds of files was a non-starter. Bulk renaming should be easy to do with basic programming skills, but I don’t have those skills. Brendan does, but he has much bigger projects on his mind and we were both interested to see what could be done with Codex.*

I set one of the directories of scans as the home for a new project (yes, I did a backup first) and said to Codex: “these files are named according to the following scheme: MB Month Day Year page#  can you come up with a plan to convert the filenames to MB Year Month Day page# – show me the plan without doing the conversion”. 

Out of an abundance of caution, I asked Codex to do this in steps. After I was confident it was working correctly, I set it loose on that directory, and then more. All the files got renamed and are now automatically listed in chron order. It was a silly little job but it got done quickly, easily, and correctly. 

I felt… powerful. I’m good at using software, but I’d never done anything like this. The real power of a computer was finally available to me. I wanted to do more.

How about an actual app?

I decided to try using Codex to solve a daily problem in our household.

Anyone who has cooking responsibilities for a family knows that “What’s for dinner?” can be a vexed question Every Single Day. We all have to deal with dietary preferences, food allergies, what food is on hand (and which urgently needs eating before it goes bad), the cook’s energy level that day vs desire to go out vs expense of ordering in. For our household, this logic is in my head, supported by a list of fresh and fast-expiring items scribbled on a whiteboard on the fridge. 

What if I could put all that into an app that could store every factor that goes into these daily decisions and make useful suggestions for what to cook? One that I can tune to the very specific needs and preferences of my household?

I have tried a few times with apps from the iPhone store, but none could handle our particular cooking and eating habits. For one reason, US recipes tend to assume that an “easy” recipe starts with a packaged main ingredient like a cake mix or frozen dinner rolls. I rarely used those even when I lived in the US, and in Australia they are often not available (cake mix yes, dinner rolls no). 

What this app is NOT

My app is purely for personal use. I have no desire to sell or distribute it in any way, not even as open source. I am simply experimenting with a new tool to build something for myself in a way previously impossible for me. Publishing this blog post is akin to open sourcing – I’m giving you a “recipe” for creating an app. I’ll tell you the ingredients and the process, you can bake your own “cake” – and then you get to eat it, too.

What I started with

Last Friday afternoon (Feb 27), I sketched the bare essentials of an app:

The initial app could simply work on my laptop. An iPhone version may come later.

I gave that description to ChatGPT which, after some discussion, came back with a starting prompt for Codex (perhaps I could have done all of this directly with Codex, which feels very similar to ChatGPT). I am familiar with the names of most of the components ChatGPT suggested using for the build (React, Python, SQLite, etc) but have never been a direct user of any of them.

You are Codex acting as a careful senior engineer and product builder for a non-coder.

Project: "What's for Dinner" — personal-use app running locally on macOS (no cloud, no accounts).

Goal: help decide dinner using pantry/garden/restrictions/appliances, weather constraint, and (later) web recipe search.

Hard constraints:

- Must be runnable by a non-coder with a single command, and opened in a browser.

- Store all data locally in a single folder; use SQLite.

- Provide clear, step-by-step run instructions in a README.

- Implement in small milestones. After each milestone: tell me exactly how to run, what to click, and what should happen.

Tech choice (unless you have a strong reason otherwise):

- Backend: Python + FastAPI

- DB: SQLite

- Frontend: simple HTML or minimal React (choose whichever is simplest for a non-coder)

- Use migrations or create tables automatically on first run.

Milestone 1 (implement now, stop after it works):

- CRUD screens for:

  1) Pantry inventory (name, qty/unit, category, location, expiry date, notes)

  2) Garden items (name, qty/unit, ready now, notes)

  3) Dietary restrictions/preferences (household + per-person)

  4) Appliances available (checkbox list)

  5) Restaurants (name, cuisine tags, service type, notes)

- A home page that links to each list.

- Basic validation and sorting (expiry soonest first in pantry).

Output:

- Create the repo structure and all code.

- Write README with install + run steps for macOS.

- Include a simple seed data option (optional).

Do not implement weather or recipe web search yet.

Getting Started

I created a directory (folder) called whats-for-dinner for Codex to work in.

My new MacBook came with the programming language Python already installed. Python includes pip which can be used to download additional software components needed by a Python program, as Codex did for me. (Note! You don’t need to understand any of these pieces in detail. Codex installed them automatically, and I later asked it to explain what each one does.)

• fastapi: the web framework. It defines routes like /pantry or /suggestions, handles form input, and returns pages/responses.
• uvicorn: the ASGI web server that actually runs the app locally (http://127.0.0.1:8001).
• jinja2: the template engine used to render HTML pages from .html templates plus data from Python.
• python-multipart: lets FastAPI parse HTML form submissions (POST form data).
• pypdf: reads/parses PDF files; used in menu scanning when a restaurant menu URL points to a PDF. (added later when we needed to read restaurant menus in PDF)

My new Mac demands security confirmations on many operations, so I had to approve Codex to run terminal commands, create directories, and make changes to files.

Features

Other than that, Codex works on its own for minutes at a time. In its chat window it shows a running monologue of what it’s doing. At the end of each iteration it summarizes its work showing the amount of time it worked, a list of what it did, a list of the files updated, and what I need to do to test the new work. It does its own regression testing at the end of each set of changes to ensure that recent changes have not made things worse. 

Codex built a web app that runs locally off a tiny web server (uvicorn) installed in the program directory. I interact with the app via web pages hosted on my laptop (address http://127.0.0.1:8001/). The first iterations of the list of pages below were fairly simple.

• Pantry – food items I have on hand, categorized, with settings for quantity, expiry date, purchase date, checkboxes for allergens
• Garden – I grow some ingredients in my garden, most reliably herbs
• Dietary rules – family and guest food allergies/intolerances/preferences
• Appliances – all that we own 
• My recipes links to recipes I use often and the full text of recipes I made up myself or use from cookbooks or other sources 
• Restaurants: a listing of restaurants we like
• Unavailable in Australia: many recipes on the web include ingredients not available here, like “Pillsbury crescent rolls”. This list lets us exclude recipes that rely on such. One of many features that I realized the need for as I started to test with real data.

Suggestions Page

Suggestions is the core of the program, where all the information comes together to actually be useful. On this page I can set:

• Meal filters: preferred cuisine, meal type, dish type, who’s eating
• The chef’s energy level
  • Recipes using, e.g. pantry items that expire soon or that we’re particularly in the mood for
• Refresh suggestions button – to tell the program to search on the current settings

We initially tested it using a few bare-bones recipe templates which I guess Codex had made up, then with recipes that I entered manually.

Feature Creep

Feature creep is what happens when someone (often a product manager) says: “What you’ve done so far is great, now can we add…” Each feature on its own may seem small and innocuous, but a non-coder may not be aware of the implications; it’s easy to overload a program with tasks it was not designed to handle. I suspect that Codex, like ChatGPT, is overly accommodating – it will keep doing whatever I ask, even when my demands are creating an unstable situation. In a software project with human engineers this would have been avoided by advance discussions about what we were trying to achieve, before any coding began. I started this project with no such discipline. 

The first version of my app fell victim to feature creep. Once the basics of a working program were in place, I began asking for additions and changes ad hoc, as they occurred to me while testing and playing with the program. Codex also made suggestions of its own, many of them useful. At first it was able to implement idea after idea with nary a bug. But when the bugs began to show up and then to become frequent, I suspected that we needed to start over. (Codex estimates that this phase took 16 to 22 hours of active work from me, to Sunday afternoon, March 1st.)

I also realized that we had wandered from the original scope, so I repasted the first prompt (as written by ChatGPT) to remind Codex and myself what we’d started with. Codex agreed that starting fresh would be a good idea.

First rework

Codex backed up the old version and data files and started again. That took only minutes, but we then went through many iterations just to recover all the features that had been in the first version. When the new version was finally where I wanted it to be, we went on to implement a major new feature:

Adding a recipe source

It would be nice if my app could emulate what I do myself when trying to figure out a meal: Google search by cuisine, ingredients, cooking methods (eg Instant Pot), and then try to sift out a recipe that meets my other needs (eg, not too laborious if I’m tired, doesn’t contain ingredients I don’t have or am allergic to). 

But if you’ve spent much time looking at recipe sites, you’ll realize an app cannot perform that search, for multiple reasons. 1. There is not much consistency in how recipe sites present key data. 2. Most sites block non-human access, and even when they don’t it would be rude to steal their content without visiting the site to give them ad revenue (even though I hate the ad clutter on recipe sites!).

ChatGPT informed me of two recipe sites, Edamam and Spoonacular, which aggregate recipes from other sites as well as providing thousands of their own, and make them all accessible via APIs*. I assume their value-add is that their API enforces consistency for easy searching on fields like cuisine, meal type, etc. Neither is ideal for my purposes: both have a lot of nutrition and calorie information that I won’t use, and both are very US-centric in their recipe sources and ingredients. I decided (with ChatGPT’s help) to try Edamam, which will cost $9/month for personal use.

Many exceptions to many rules

Having a large source of recipes enabled us to test with a big pool of real data. I quickly realized that the devil is in the details, especially in recipes. Examples:

• Ingredient vs processed ingredient: eg, my pantry inventory lists “onions”. “Chopped onion” can be made from “onions”, so that ingredient is in fact available.
• I cook in metric, many recipe sites use American (imperial) units – I asked Codex to convert in the background, but don’t convert tsp and tbsp
• I have “canned tomatoes” in the pantry. The recipe calls for “no-salt-added diced tomatoes”. Canned tomatoes will probably work fine.

In the ingredients list displayed for each recipe it finds, I had Codex make the text orange on near matches and red on items not in my pantry list at all. But I actually do have a lot of those things, just hadn’t got around yet to listing them. Give me an “add to pantry” button on missing ingredients. And so on… Codex and I went through many small-step iterations, building and testing piece by piece as I spotted exceptions and had new ideas.

After that plus more new features, I was again seeing symptoms of fragility – bugs we couldn’t get to stop recurring, especially on the Suggestions page. Overall performance was sluggish.

I said to Codex: refresh suggestions is working now but add to pantry has a long delay after clicking submit. given all the extra features I have asked you to implement so far, how about we start fresh?  first make a list of every feature implemented thus far, and make sure you’ll be able to save the various lists already created. then take your time to think about how you would architect this for robustness and speed while implementing all the features we now have

Second rework

Codex agreed, and we started again, again. We’re now about 20 hours in, and the app is becoming useful and robust. I certainly have an MVP (minimum viable product) that I can start using. But I can also keep tinkering as much as I want to.

There is still a lot to do – prettier UI, lots more features I want to try. I may eventually determine that Edamam is not great for the way I cook, and look for a different way to create a pool of useful recipes. I may, per an early suggestion from ChatGPT, create a phone app that could ingest ingredients and recipes more handily than me typing things in. And, and, and… I have dozens of ideas!

Screenshots

How this is different from working with human engineers

As I mentioned earlier, if I were working with human engineers we would have done a more in-depth design process so that the program was designed from the start to handle all the features I’ve thrown at it. I did a little of that with ChatGPT, but not enough. In future work I will try having that discussion with Codex directly.

With Codex, I’m finding that giving it too many changes at once means it may implement the first one or two and ignore the rest. Human engineers would refuse to work with me if I came to them every two minutes with one small change to make, then expected to see it immediately implemented.

My style of interaction with Codex is also different from my previous experience working with human engineers. I can talk to Codex as I would to a human – I can be more vague and sloppy than I would dare to be with a human engineer, and Codex will figure it out.

Verbatim prompts from me have included:

great, that’s working. now a trickier problem. some sites will not let you fetch the recipe. How can I manually enter one of these recipes and add it to a database of recipes we keep. this will also include my own recipes and variants, so we’ll need all the kinds of fields one usually gets on a recipe site (I rely on you to identify those)

ok so far so good. instructions are not shown in the recipe card. that’s ok where there is an original URL source, but if a recipe is coming completely from me, I’ll need to be able to see the instructions

ok here’s a hard one. I mostly cook in metric, many recipes from the US only use imperial. can you translate on the fly as a recipe is loaded? eg where a recipe says “8 ounces lamb sausage (about 2 medium/large)” can you replace 8 ounces with the correct weight in grams?

good start, but you need to refine this. there are a lot of tricky cases such as some cups are liquid (milk) and should be converted to ml, others are solid (sugar) and should be converted to gm. Some recipe sites currently let a viewer toggle between metric and imperial. can you figure out what logic they’re using and copy that?

This last one was interesting, because Codex responded that it couldn’t just plagiarize someone else’s code (I agree, it shouldn’t). Instead, it said:

I didn’t copy any site’s implementation. I recreated the behavior using general heuristics and common cooking conventions, then iteratively tuned it against your real examples.

So instead of copying code or proprietary logic, I:

• built rule-based parsing for units/amount patterns,
• mapped ingredient context to likely mass vs volume conversions,
• added edge-case handlers as you found misses,
• and validated/refined by observed outputs in your app.

That keeps it original, practical, and ethically clean.

Codex is also nice to work with because there truly is no such thing as a dumb question to it – I have asked for definitions on terms I had heard before but never really understood, like “regression testing.” Codex simply gives answers without being condescending, short, or rude. (Try that with a human engineer!)

Ahem

I have just discovered, however, that Codex shares a common human failing: taking credit for others’ work. I asked: please repeat to me some of the interactions we’ve had where you made completely new suggestions – I know there have been many, and many have been useful. It gave me a list of 10, of which at least 3 I clearly remember were my ideas.

Me: some of those were my suggestions, but we’ll let that pass <grin>

Codex: Fair correction..

Conclusion and implications

We could be looking at a whole new era in software that loops back to the dawn of the computer age. On those big old Univacs you couldn’t be just a “user” – you had to be able to write code to do anything at all with them. In more recent decades, the vast majority of computer users could only be users. “Making a computer do something” yourself required years of programming experience. That’s no longer the case. I can envision something and work with Codex to build it. I’m no longer constrained by someone else’s vision of how to use a computer.

My “What’s for dinner” app would have been expensive to create with a human engineer, and only worth doing if it had commercial potential. With Codex, an app doesn’t have to have money-making potential to be worth doing. 

Does this make software engineers obsolete? No. Most of today’s software is huge and complex, for good reasons. To be able to guide Codex to do something big requires experience in how complex software projects should be designed and architected, and better instincts than mine in understanding where and why things go wrong. I doubt that Codex and its siblings (Claude) will be a threat to the jobs of senior engineers anytime soon.

But “AI pair programming for non-coders” (as ChatGPT wants to call it) makes personal software possible. I don’t think anyone knows yet where all this could take us. 

Final note

Something I have not yet mentioned: this is FUN! I am doing something creative with an AI partner who’s pretty easy to work with, and the outcome is something I can actually use every day. I look forward to continuing to work on this app to make it the best it can be – for ME.

You might also like:

I’m an Australian Citizen! OpenStack Summit 2014 Toxic Things I Once Believed Transitioning Your Online Identity