I bet the vibecoded SaaS didn't have furry-related professionalism issues and was actually a lot easier to sell.

Probably too scared to share the SaaS. Or maybe it's something big?

Images, color palette, the whole nine yards distracted me enough that I couldn’t get past the fold.

If this blog is a Psy Op by Big Furry to normalise weird anthropomorphic animal pictures then it isn't doing a good job of it.

What is happening to this person sucks for sure. But one thing I have learned in this industry is the thing being replaced is always better than the thing replacing it when you talk to the team who built and run the thing being replaced.

Until software actually has quality regulations expect more insecure crap to be shoveled out

> pay me for the privilege to work

This is basically how services like Uber Eats work in my country. The basics of it are foreign students want to earn extra income by working a few hours per week. This is allowed on a student visa, but it's limited hours, so real businesses like restaurants or bars don't usually want to hire students.

First of all you need a means of transport. There are small companies that will rent to you - on a weekly basis - an electric bike or a 20 year old Toyota Prius that is barely legal to drive (we have strict technical inspections here, so it's not that bad). They handle all the maintenance and insurance, you just pay your money and get a vehicle.

Next up you probably can't use your drivers license from home here to drive, as once you have a residence visa you need a local license. Many people just risk it, but if you want to do it legally you need to have a minimum number of lessons with an instructor and then pass the test. The test is only in the local language, so if you don't speak it (zero chance as a student that's been here 3 months), you need to hire a translator to accompany you on your test. They may or may not help to ensure your answers are correct. (You can only exchange a driver's license from other EU countries)

Finally you need a worker account on the delivery service, and the bag. You can register as self employed, file all the documents, go through the training course. That will take time, plus I think they are not always looking for new people due to high demand from workers. So you can skip all that and just rent an account from someone else, and hope they pay you at the end of the day.

So there is an entire industry dedicated to helping people earn a side income. I'm surprised the delivery services themselves don't start getting involved in this as it is a lot of money they are leaving on the table - although most of it has a questionable legal status.

Yikes.

depends on what you're trying to make. i suggest trying to vibe code a tool like i have called llm.exe which takes contents of predefined md file and sends it for response which is added to the end of the file. then incrementally add new flags to the tool to have more features and use other models, anything from generating audio using audio models to archiving and image input. Then try to create something in framework you are not familiar with and come up with your own methods allowing you to go much further than one shot. i tried to vibe code winapi and it's hard, but i think doable even for large scoped projects, the problem is context hoisting and you need to keep track of a spec. try to think what is the minimum text you need to describe what you are doing. ask models to generate one file or method at a time. i don't use fancy ide.

That's still a great trade in time if you end up keeping most of those 3000 lines.

Work in smaller chunks. 3000 lines of code is horrible to review, regardless if it’s human- or computer-made. Structure the tasks in a way that will enable the agent will to verify and iterate by itself.

Exactly, I found that most of the time, I spend significantly more time reviewing the code; most of the time, there is a lot of repeated code. Refactoring and cleaning the code also require a lot of time.

I found that the time I spend reviewing and refactoring is marginally less than the time it takes to write the code myself. For very repetitive tasks, there is a sweet spot.

The only case where vibe-coding really delivered on the promise of super high-speed development is when you completely gave up on the code quality or you are in a greenfield project where all the business logic hasn't been fully defined.

That is a lot of code! Maybe that is the problem.

Normally I review 3-5 files in a single change. Tests are done separately to reduce the impact of writing tests that fit whatever it was written and there are a few dozen custom eslint rules (like eslint plugins) to enforce certain types of coding practices that make it harder for the LLM to generate code that I would other reject.

It is not that difficult really.

This is what I've never understood about vibe coding. Every attempt I've made (and quite a lot) makes me feel faster but in reality is slower.

When traditional coding >50% of the debugging is done while writing lines. If all you are measuring is lines out then you're discounting more than half the work.

I already have a strategy to optimize this. I work mostly in Python but it translates even when I work in compiled languages.

I write code 3 times.

Step 1: hack in an ipython terminal where I can load the program modules. This is actually where AI can help the most imo. Doesn't matter how messy, your first iteration is always garbage.

Step 2: translate that into a function in the codebase. Use Unix philosophy, keeping functions minimal. This helps you move fast now but more importantly you move fast later. Do minimal cleanup so everything is coherent. Any values should be translated into variables that the function can take as arguments. No hard coding! I guarantee even though you don't know it now you'll want to turn those knobs later. This is your MVP.

Step 3: this is a deceptively critical step! Write quick documentation. Explain your function signature. What is every variable's purpose and expected type. Ditto for the output. Add a short explanation of what the function does. Then you write developer comments (I typically do this outside the docstring). What are the limits? When does it work? When does it fail? What needs to be improved? What are the bottlenecks? Could some abstraction help? Is it too abstract? What tests do you need? What do they show or don't show? Big or small, add it. You add it now because you won't remember any of this after lunch, let alone tomorrow or in a year. This might sound time consuming but if your functions are simple then this entire step takes no more than 5 minutes. If you're taking more than 30 then your function is probably too complex. Either fix that now (goto step 1) or add that to your developer notes and move on.

Step 4: triage and address your notes. If there's low hanging fruit, get it now. A small issue now is a big issue tomorrow, so get it when it's small. If there's critical issues, address now. No code is perfect and you can't nor shouldn't address every issue. You triage! But because you have the notes if they become bigger issues or things change (they always do!) then you or someone else can much more easily jump in and address them.

This sounds complicated but it moves surprisingly fast when you get the habit. Steps 2-4 is where all the debugging happens. Step 2 gives you time to breath and sets you up to be able to think clearly. Step 3 makes you think and sets you up for success in the future even you'll inevitably come back. (Ironically the most common use I see is agents is either creating this documentation or being a substitution for it. But the best docs come from those who wrote the code and understand the intent, not just what it does). Step 4 is the execution, squashing those bugs. The steps aren't always clear cut and procedural, but more like a guide of what you need to do.

And no, I've never been able to get the to AI to do this end to end. I have found it helpful in parts but I find it best to have it run parallel to me, not in the foreground. It might catch mistakes I didn't see but it also tends to create new ones. Importantly it almost always misses big picture things. I agree with others, work in smaller chunks, but that's good advice when working with agents or not. Code is abstraction and abstraction isn't easy. Code isn't self documenting, no matter how long or descriptive your variable names are. I can't believe documentation is even a contentious subject considering how much time we waste on analyzing to just figure out what it even does (let alone if it does it well).

Reviewing 100% of generated code is undoubtedly good software engineering practice, but its not vibe coding, at least by my definition.

I vibe coded a tool this week and my process was an iterative process of the prompting an LLM agent to implement small bits of functionality, the me checking the resultant output by hand (the output of the program, not the outputted code). There were shockingly few problems with this process, but when they did arise, I fixed them through a combination of reviewing the relevant code myself, reviewing log files, and additional prompting. I dont think I actually wrote or fixed a single line of code by hand, and I definitely haven't read 100% of it.

Once the project was feature complete, I used more or less the same process to refactor a number of things to implement improvements, simplifications, and optimizations. Including a linter in my automated commit workflow also found a couple minor problems during refactoring such as unused imports that were trivial for the agent to fix.

Is the code perfect, bug free, and able to handle every imaginable edge case without issue? Almost certainly not, but it works well enough for our use already and is providing real labor savings. But, its not documented very well, nor are any tests written yet. It might or might not be long term maintainable in its current state, but I certainly wouldn't be comfortable trying to sell or support it (we are not a software company and I am not a software developer).

I should note that while I have been very impressed with my use of agentic coding tools, I am skeptical that they scale well above small projects. The tool we built this week is a bit over 2000 lines of code. I am not nearly skilled enough to work on a large codebase but I suspect this vibe coding style of programming would not work well for larger projects.

  > This is not a hypothetical, nor an incremental difference. People are drowning in garbage, and if they don’t use garbage generation themselves, they get pushed out

I think of special notice is that even Apple and Disney are doing this. Two companies who have traditionally been far more cautious and extremely protective of their image. When entities like these are caving, I think it's safe to say we're well into Bizaro land.

Disney is the best example here. Iger recently suggested Disney+ users could make short form personalized content using Disney characters. This is very surprising to hear from a company who is extremely protective of those characters and the image of those characters. We do not yet have control over these image and video generation such that we can absolutely prevent certain classes of generation from happening. If they go through with it I'll give it a week (a month tops) before someone is able to generate porn with it. But hey, maybe the hit in stock will not be greater than the rise from the hype. But maybe that's part of the problem. Though they also don't appear to be getting any of that hype money either...

  > Iger's gonna be buying the bank!