[scorpioxy]

I have been taking on "rescue" projects for a while through my business. Previously, the barely-functioning code was usually being generated via outsourcing agencies but it seems the new source is now going to be LLMs.

I imagine it will be the same set of issues really. Just a different way of cost cutting measures. There can be good reasons to take shortcuts but, in my experience, the problems start when you're not mindful that there's a price to pay for taking these shortcuts. Whether it comes from managers, employees or outsourced personnel, it's the same result.

I haven't thought about advertising it as a separate type of service(for vibe coded platforms) yet but maybe I should. The Australian software market is small so haven't been hearing much about the results of those experiments.

[tgsovlerkhgsel]

One of the issues with vibe coding vs. outsourcing agencies is the sheer volume of code it can produce in a short amount of time.

I vibe-coded a simple helper script. If I wrote it myself it would have been 1/3rd the lines, not covered most edge cases (some of which were completely irrelevant, some of which actually useful), and it would have taken me way longer than just checking if the vibe-coded code works (this was the "either it works or it doesn't" kind of task, not something where subtle errors could reasonably be introduced).

I skimmed the code and removed the line that deletes temp files to reduce the risk that it accidentally wipes my home dir and ran it. As I was trying to work with the data deeper, I noticed missing temp files, and realized that there were two other temp file deletion lines that I missed.

It's simply too much code for a human to reasonably read, but the speed benefits are real.

(My plan for the future is not reading the code more carefully, it's putting it in a sandbox and letting the AI play.)

[DevDesmond]

I like to keep a personal recipe book of prompt modifiers. For bash scripting I often write my prompt and then copy-paste the following to prompt:

``` When making edits to the script, ensure the script remains

- Idempotent - Functional after a fresh install of a virtual machine

Additionally, keep things stupid simple and avoid:

- Unnecessary error checks - Defining colors and custom logging functions - Bells and wistles - Backups - Branching Paths - Script Arguments ```

I find it helps cull back the LLM 's overenthusiasm for abstractions.

[SOLAR_FIELDS]

In general I usually toss “follow KISS principles” into nearly every plan prompt. If you tell it that, it helps cut out a lot of the noise and only focuses on the core functionality

[dotancohen]

I'd love to see some more of that recipe book. If you don't want to share here, my Gmail username is the same as my HN username.

Thank you!

[mattmanser]

Try this one, it works 100% of the time:

X. Don't write stupid code.

Replace X with your prompt.

[herdcall]

There's a BIG difference, at least with tools like Claude Code: plan mode. I'm now using Claude Code a lot at at work, and the first thing I do is enter plan mode where I can have a "conversation" asking it explain how it would implement. Just a few back/forth later I end up refining its plan to conform to good (or what I think is "good") design, after which it will tell me exactly what it is going to do (with code diffs), which I sign off on (again, potentially after a few iterations). It's only then that it generates the code.

By contrast, on one project many years ago I was reviewing the code generated by an overseas team, and I couldn't make head or tail of it, it was an absolute tangled mess that was impossible to fix.

[nickserv]

Probably a good idea to at least add some vibe-coding terms to your website for SEO.

[scorpioxy]

Might be a good idea, though word of mouth and networking is how I get work and SEO has stopped being a useful avenue for a project pipeline quite a while back.

[mhfu]

I was thinking of doing something like that, but how does it work for the company in the end? If they vibe coded their project and now have shitty code full of bugs, you come in, fix the bugs and organize the code better and that's it? How do they continue to maintain it if they didn't have the knowledge to set it up in the first place?

[scorpioxy]

They would try to hire and/or build the team they need to move forward, if they have the money.

Knowledge is usually not the problem, it is the shortcuts(or short-term decisions) that got them to a place where they can no longer operate the platform they need to survive. Often this is the cause of prioritizing velocity over anything and everything else. This is choosing the do it fast and do it cheap options with the assumption that it is always correct. That assumption of course is almost never true.

By the way, most cases where I've seen this there's usually an investor involved and they need to impress them.

[Tuna-Fish]

The pattern I've seen repeatedly in real life is that a company does something they don't expect to be important and impactful, cutting every corner they possibly can to shovel out something that minimally meets the requirements. And then that software surprises everyone by actually being wildly successful, and now they have to support it and modify it to a state where they can build upon it. Which might be hard if the product is an unholy mess made by people who knew little of what they were doing and cared about it exactly as much as they got paid for it (that is, not much).

And cutting every corner to get the cheapest possible product out might not have even been the wrong call! Presumably most things made this way fare just as well as they were expected to and die quickly after being made, not spending scarce resources on making them better was probably the right thing to do.

It just sucks when you end up having to maintain strict backwards compatibility to something that was made in two weeks by one guy who took every shortcut on the way to duct-tape together something that technically does what was asked for. (Yes I'm thinking of you, javascript.)

[A4ET8a8uTh0_v2]

This. Based on what I have seen so far in my company so very anecdotal.

Assuming they know and/or have the capability to do it, between the cost of correcting the issue and push to use AI into everything meaning raising any issue now, politically speaking, is a direct criticism of someone major VP pet projects. I personally simply started to log stuff.

The first thing they need to do first is acknowledge there is a problem to begin with. I am so glad I am not an actual programmer though. It would drive me nuts.

[scorpioxy]

There's definitely a lot of politics involved in such projects. So I've learned that a break is necessary between major engagements to decrease the risk of burnout.

The environment that creates "rescue" projects is usually not one where long term thinking is prevalent. It would be a pet project of someone who's still there or someone who left but where the ultimate decision maker is still there. Either case, you need to walk on egg-shells and be mindful that dealing with the technology problems is the easiest part of such an engagement. I'm not ashamed to admit that I've learned that lesson the hard way.

[Lu2025]

I was about to ask whether engaging with this kind of people is even worth it. I've seen enough of Jamie Dimon-like power trips to stay away.

[scorpioxy]

That's a good question that I sometimes ask myself. But if you want the money, you have to do what it takes. There's a limit of course and lines that I do not cross(illegal, unethical etc). There were plenty of times where I had to say that this is not going to work and chose to end the relationship with a handover. During those times, the technology wasn't the problem.

[kelvinjps]

I think if they are interested on fixing it it's because the project provide business value, so then now it's worth it to build the software development team or make a contract with software development agency

[HPsquared]

I suppose a lot of the same kinds of skills will be required for both outsourcing, and LLM driven development.

That is, the "engineering" side of things (requirements gathering, communication, stakeholder management, defining specifications, testing, documentation, and generally managing chaos)