470

True story that might have happened today (lemmy.dbzer0.com)

submitted 1 day ago by your_paranoid_neighbour@lemmy.dbzer0.com to c/programmer_humor@programming.dev

31 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] orca@orcas.enjoying.yachts 14 points 1 day ago

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.

[-] BartyDeCanter@lemmy.sdf.org 6 points 1 day ago* (last edited 1 day ago)

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.

[-] orca@orcas.enjoying.yachts 2 points 14 hours ago

This is clever. Thanks for sharing! I’ve been kinda doing this manually using Cursor. I put it into “Ask” mode and it walks me through bits. If it’s coding work that I prefer doing (I’m a frontend guy but can do backend), I write the code myself. That way I’m still retaining the knowledge like you’re doing.