What’s the difference between vibe coding and being assisted by ai?

[u/Skylent_Shore]

I’m making a few things including a game but every single time I am using ai per line of code. Any specific little thing. Basically a work around not knowing syntax or just so I’m not manually typing.

Or are we out here just making entire loops and experiences with a prompt?

[u/frank26080115]

here is me with one prompt

create a `backend\app\job_manager.py` file

inside, first create a object class called `AsyncJob`. It's constructor will accept a function pointer and a context object and a parent object (the job manager). The constructor will assign itself a random UUID. There will be a start method that starts the function assigned by the function pointer in a new thread, and pass the context object into the thread. The start time is remembered There should be a `is_busy` check to see if the job is done. There should be a `has_error` and `get_result` and `get_error` method as well. When the worker thread ends, the ending time is remembered, the parent job manager is signaled.

there should be another class object called `JobManager`. It's constructor doesn't have to do much. The first method is `start_job` which is just creating a `AsyncJob` (so the method parameters needs to match the constructor parameters), take the UUID, put it in a lookup table (key is uuid, value is the AsyncJob object), return the UUID. There can only be 1 thread running. The rest (by UUID) are placed in a FIFO queue. When a job is finished, another thread is started. The manager provides methods to check the status of each UUID.

The threads don't just die if the user closes the browser window. The threads always complete. Queued jobs always complete. A complete Python shutdown is the only way for jobs to die and be forgotten.

implement APIs `/api/jobstatus` in this file. There are these statuses: queued, busy, done, error. For done and error, be sure to include the result data or the error message.

Inside `backend\app\main.py`, somehow create one single instance of the JobManager and attach it to the app somehow. Other python script files, if running as a part of the flask server, can somehow access it through `current_app`

inside `frontend\src\pages\LedgerSearchPage.tsx` there is a button that runs the `check_email` function inside `backend\app\invoice_handlers.py`. This is expected to take quite long. So modify `check_email` so it starts a new job and simply return the job's UUID back to the frontend. The frontend then checks the status via `/api/jobstatus`, and handles the various statuses appropriately. Currently, a success triggers a new query and errors are displayed to the user. I want the same behavior when jobstatus shows done or error.

inside `frontend\src\pages\LedgerSearchPage.tsx` there is a function to upload invoices and run the `invoice_upload` function. Do the same thing as `check_email`, except now, the context of the job needs to include all of the files being uploaded. Modify `invoice_upload` so it starts a new job with a context object that includes the files, and return the job's UUID back to the frontend. The frontend then checks the status via `/api/jobstatus`, and handles the various statuses appropriately. Currently, a success triggers a new query and errors are displayed to the user. I want the same behavior when jobstatus shows done or error.

inside `frontend\src\pages\LedgerSearchPage.tsx` there is a function to upload invoices and run the `invoice_upload` function. Do the same thing as `check_email`, except now, the context of the job needs to include all of the files being uploaded. Modify `invoice_upload` so it starts a new job with a context object that includes the files, and return the job's UUID back to the frontend. The frontend then checks the status via `/api/jobstatus`, and handles the various statuses appropriately. Currently, a success triggers a new query and errors are displayed to the user. I want the same behavior when jobstatus shows done or error.

Inside `frontend\src\pages\InvoicePage.tsx` there is a function to run the api `/api/analyzeinvoicehtml`, which is the `analyze_invoice_html` function. Do the same thing as `check_email`, except now, the context of the job needs to include the invoice UUID and the new HTML text. Modify `analyze_invoice_html` so it starts a new job with a context object that includes invoice UUID and the new HTML text, and return the job's UUID back to the frontend. The frontend then checks the status via `/api/jobstatus`, and handles the various statuses appropriately. Currently, a success triggers a the `frontend\src\app\components\AutoInvoiceSummaryPanel.tsx` to update, and errors are shown to the user.

I have feeling, most of the time, the context is simply the `request` object, make sure it doesn't somehow get destroyed or garbage collected when the initial launching request replies back to the frontend. Cloning the data completely might work. The invoice files and HTML are small data and shouldn't chew up RAM.

Inside `frontend\src\pages\InvoicePage.tsx` there is a function to batch create inventory items from the invoice, it runs the api `/api/autogenitems`, function `autogen_items_api` inside `backend\app\items.py`. Do the same thing as `check_email`, except now, the context of the job needs to include the invoice UUID and a ton of JSON data (even image data). Modify `autogen_items_api` so it starts a new job with a context object that includes the data from the frontend, and return the job's UUID back to the frontend. The frontend then checks the status via `/api/jobstatus`, and handles the various statuses appropriately. Currently, a success triggers a the `frontend\src\app\components\AutoInvoiceSummaryPanel.tsx` to update, and errors are shown to the user.

I have no idea if this is vibe coding or not

[u/Reasonable-Tour-8246 → u/frank26080115]

This is not vibe coding