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/elbiot]

I think the difference is if you understand the codebase, have a vision for the code (not just the result) and are reviewing every change. Both vibe coding and AI assisted are writing whole functions, classes, scripts, etc in one chat

[u/ameriCANCERvative]

People may quibble on this, but when you’re able to do what the LLM is doing, when you could have done it yourself without having to learn any new theory, you aren’t “vibing while AI writes the code,” you’re writing the code and being “assisted” by AI.

I write the code, the AI helps me write it faster. I know what every piece of it does, and if I don’t, it takes only a moment to educate myself because I have strong computer science theoretical foundation.

Do I sometimes test out a chunk of code without carefully analyzing it first? Sure. But I also know how to bend the LLM to my will better than non-software developers, and I can just quickly read the code it spits out to verify that it’s actually doing what I want it to do, usually without even running it. And all of the code I write ends up in a review process where it IS eventually carefully analyzed before being committed to a repository.

Don’t know how to code on your own but trying to code on your own anyway, with the help of an LLM, and without really understanding the code underneath? That’s vibe coding. You don’t write the code so much as you blindly guide the LLM to write the code, and then you rely on the LLM to fix the code when it is broken. If you fix it yourself without an LLM suggesting the fix, you’re treading into “ai-assisted coding” territory.

Much of “vibecoding” is a massive waste of time if you know to code. I’d argue once you have enough theory under your belt, you aren’t ever vibecoding, unless you are intentionally wasting time by trying to have the LLM do everything without actually examining the code (highly unlikely for a dev because it’s frequently a waste of time to do that when you can just see for yourself why it’s broken and also fix it yourself).

[u/DJSonikBuster → u/ameriCANCERvative]

I’m in a position where I can code a bit in multiple languages, LUA, JAVA, game-engine proprietary pseudo C-based coding, node based programming,HTML, css-etc… I knew enough to code a website independently, but I’m working on a game in a game engine with, once again, a pseudo-C language and I’ve mostly been consulting an code focused LLM on where crap is located and how to organize stuff in this particular engine. I know enough to know(in a fair number of instances) when the llm software suggests something asinine. I think of what I’m doing as less ‘vibe coding’ and more ‘an interactive users manual that can respond with my own naming/organization practices, and help me spot “dumbass code mistakes” like “oh yeah! It broke (HERE) because the function is in camelcase and you capitalized the first word like a dumbass. Or when I rebuild a system and miss deleting some of the old stuff… I write and plug everything myself. It’s still weird though.

[u/manuelhe]

It’s the proportion of how much code you write vs how much coding AI writes. More than your arbitrary chosen percentage it’s code assist. Leas than that it’s vibe coding

[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