True Story. One of the development teams showed how they “re-wrote” our registration process with AI in a week as their team demo. They have not tested it since we laid off the QA department two weeks ago.
I have no hope their launch will be smooth. I expect it to be as steady as a car in an cross country race.
“The AI tested it for us”
“Why does everyone hate AI?!?!”
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.
They’re not trying to replace you, they’re trying to devalue you. See how that’s different? You thought that they were indifferent towards you, but it turns out that they actually hate you. How fun!
Exactly. They know they actually can’t fully replace programmers with AI, but they will pretend they could to get away with paying lower salaries.
I don’t think that is a very helpful talking point either. Replacing workers with machines has been a thing for centuries and isn’t by itself a bad thing.
Using unverified AI for anything actually business critical is a very bad management decision though and any company that does that deserves the consequences. Using AI as replacement for eg. stock photos or video CGI? That is not a bad idea at all.
Forgetting AI for a moment, I am always shocked when I am reviewing a coworker’s code and it’s obvious that they themselves didn’t review it.
Like, they sent me a PR that has a whole shitload of other crap in it. Why should I look at it when you haven’t looked at it? If you don’t review your own review requests, you’re a failure of a
programmerhuman.And I would be a failure if I approved such a request.
Getting back to the post, where is all of the review? The coworker should have reviewed the AI shit, whether it was code or documentation. The person who approved the PR should have reviewed it, as well.
Every business with more than one programmer should have at least two levels of safeguards against this exact thing happening. More if you include different types of test suites.
This post describes a fundamentally broken business, regardless of the AI angle, and so it’s good if everything is broken. With such a lack of discipline and principles, I say let the business fail.
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
I feel like my life is writing prompts to AI now. If you don’t fall in line, you’re basically out of a job. A human can’t keep up. If the goal was to completely ruin my desire to write code, they’ve succeeded.
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 languagesThe last three points are my addition as I am currently do a lot of development in Rust which I have no experience with.
