"The AI tested it for us"

I think LLMs are neat and useful tools in some circumstances. So I don't hate "AI", I hate the billionaires who are pushing it down our throats, or trying to replace us.

"AI" isn't artificial intelligence...LLMs are a chat bot with a database the size of the world and the resource usage of a country for every prompt.

Its just another way for rich cunts to show off their small dicks and large wallets - look what my money can buy?

How about solving world hunger and not playing with toys.

These miscreants are fucking evil.

History will not judge them well, or anyone who buys into their lies.

Yeah, we are falling into a little bit of this where I work right now. It’s a bit of a change of mindset to begin thinking that you can’t trust a PR even a little. Yes, you should be able to but humans are humans and we get lazy and trusting the magic pattern machine is gonna impact everyone’s life in a lot of ways

Yeah, we have some basic problems in there.

The documentation was from the framework. Basically the thing was misconfigured, it was said that it would do something, but that something is impossible and some of those config variables don't even exist. On top of that, the microservice got a lot worse because of the configuration (losing information kind of worse), it would have been better with the defaults.

Same here, I just keep my phone off while off work. Let them hallucinate a solution.

I recently read this blog post and gave it a try. After a little bit of tweaking, I found that it became a useful tool for me while still letting me enjoy coding. It doesn’t fix everything that is wrong with AI development but it does help a lot in my day to day.

TLDR: Add this to your copilot_instructions.md or whatever you use.

When the user gives you a task specification:

1. Explore the codebase to find relevant files and patterns
2. Break the task into a small number of steps. Each step should include:
    a. a brief, high-level summary of the step
    b. a list of specific, relevant files
    c. quotes from the specification to be specific about what each step is for
3. Present the steps and get out of the way.

When the user says "done", "how's this", etc.:

1. Run git status and git diff to see what they changed
2. Review the changes and identify any potential problems
3. Compare changes against the steps and identify which steps are complete
4. Present a revised set of steps and get out of the user's way.

Important:
- Be concise and direct, don't give the user a lot to read
- Allow the user to make all technical, architectural and engineering decisions
- Present possible solutions but don't make any assumptions
- Don't write code - just guide
- Be specific about files and line numbers
- Trust them to figure it out
- Do not offer to write code unless the user specifically requests it. You are a teacher and reviewer, not a developer 
- Include checks for idiomatic use of language features when reviewing 
- The user has a strong background in C, C++, and Python. Make analogies to those languages when reviewing code in other languages

The last three points are my addition as I am currently do a lot of development in Rust which I have no experience with.

Same here. It's the first time in 30 years that I'm considering doing something different.

Has that helped you? whenever I'm trying to find a niche problem I come across it and it tends to just reiterate the same information I already knew in a more roundabout way. Maybe I'm biased because clicking on links that don't solve my problem tend to make me more pessimistic, but it feels to me like those sites that used to just be keyword packed lists of links to get themselves higher in the search results.