GPT presents: the fake it till you make it, 'make things up as you go'-driven development methodology
TL;DR: just pretend some code repo exists, interact with it, and GPT will happily fill in the blanks.
To start, let's clone an imaginary vet app repo and start its API server:
Dec 16, 2022 · 11:57 PM UTC
Now we can start playing with the API🧑💻
The schema and data state are mostly consistent through its use -- to the point that it refuses to add pets with duplicate names to the same customer!
I found it useful to add a 'fields' parameter with the fields you want in the response.
Ok, nice. So let's see what it created in the repo so far.
GPT chose to build the backend with express and lowdb, and came up with a short description for it:
And here's webserver.js (full code: gist.github.com/shesek/e4422…)
The code was near flawless on first try -- the only fix needed was to use `require('uuid').v4` (it provided code for older uuid release)
With this, I can `npm start` to get a working(!) API server w/ all the endpoints
How about some tests? Easy peasy
Let's have it use mocha and fetch by installing them first. Then we can run the tests and `cat` them to see what it came up with.
(Full code: gist.github.com/shesek/4f90f…)
How about switching to postgres instead of lowdb?
Just install `pg` (in a separate session) and GPT will happily do the rest. It'll even join information from multiple tables for the GET /customers endpoint
(Full code: gist.github.com/shesek/d9d94…)
Or maybe SQLite instead? Unlike lowdb, its pretty similar to postgres and the changes should be quite minor
Can we see how that might look like?
Yeah we can - just `git checkout` an imaginary branch with an appropriate name and view the last commit
How about a CLI utility for backups, written in Bash?
Just make up whatever arguments the CLI should accept and it can figure out the rest, complete with usage help text and parameter parsing/validation code
(Full code: gist.github.com/shesek/9e03c…)
How about a README?
You can basically just assume that files with typical names (or that are otherwise deductible in context) already exists (even if they don't show up in `ls`)
(Full file: gist.github.com/shesek/fad72…)
The API docs in the README are rather minimal, lets get some more fully specified docs
(Full file: gist.github.com/shesek/fad72…)
(In case this wasn't clear, this is intended for use after the famous 'act as a linux terminal' preface: github.com/f/awesome-chatgpt…)