No emojis, no comments, no console log statements, no read me file, no error handling. Act as a senior developer working with other experienced developers.

Otherwise it happily generates bunch of trash that is unreadable. Error handling generated will most of the times just hide errors instead of actually dealing with them.

also: I clean the chat and start over sometimes, because results may differ.

100% of my positive experiences with agent coding are when I don't have reason to care about the intrinsic qualities of the code (one-off scripts or genuine leaf node functions that can't impact anything else.

Think of the AI like an outsourced consultant who will never say no. It'll always do everything it can to solve the problem you've given it. If it doesn't know how, it'll write a thousand lines when a single additional dependency and 2 lines of code would've done it.

My successful AI written projects are those where I care solely on the output and have little to no knowledge about the subject matter.

When I try to walk an agent through creating anything about which I have a deeply held opinion of what good looks like, I end up frustrated and abandoning the project.

I've enjoyed using roo code's architect function to document an agreed upon approach, then been delighted and frustrated in equal measure by the implementation of code mode.

On revelation is to always start new tasks and avoid continuing large conversations, because I would typically tackle any problem myself in smaller steps with verifiable outputs, whereas I tend to pose the entire problem space to the agent which it invariably fails at.

I've settled on spending time finding what works for me. Earlier today I took 30 minutes to add functionality to an app that would've taken me days to write. And what's more I only put 30 minutes into the diary for it, because I knew what I wanted and didn't care how it got there.

This leads me to conclude that using AI to write code that a(nother) human is one day to interact with is a no-go, for all the reasons listed.

Now, I have the best luck in my personal project codebase, which I know extremely intimately so can be very surgical with.

Work, which has far less comments and is full of very high level abstractions that I don't know as well.. it struggles with. We both do.

It's a fine pair programmer when one of the pairs knows the codebase extremely well. It's a bad companion elsewhere.

Here is how to do this: Have it generate something. That first 2000 lines of not so great first attempt code, don't even think about understanding all of that, or, worse, about correcting it.

Review it loosely. You are not dealing with a human! There is absolutely no need to be thorough or nice. You are not hurting any feelings. Go for 80/20 (or the best ratio you think you can get).

Then, think:

- Anything you missed to inform the AI about? Update your initial prompt

- Anything the AI simply does not do well or to your liking? Write general instructions (all of the IDEs have some way of doing that) that are very explicit about what you don't want to see again, and what you want to see instead.

Then revert everything the ai did, and have it go again from the start. You should approach something that's better.

2. The point is, that you are training the AI through this process. You can do pair programming afterwards (or not). Aim to instruct it to give you ballpark answers first, and take it from there.

At this point AI generated code absolutely requires review by a human so LOC is still an important metric.

This ensures the LLM has a complete understanding of the overall goals, along with a step by step list of tasks to get there. It also allows me to quickly get the LLM back up to speed when I need to start a new conversation due to context limits.

Meeting-based programming. No wonder management loves it and thinks it should be the future.

Forget about overall goal. I have this simple instruction that i send on every request

"stop after every failing unit test and discuss implementation with me before writing source code "

but it only does that about 7 times out of 10. Other times it just proceeds with implementation anyways.

I guess you also think that we should get rid of checklists for pilots because they would never ignore an instruction they were clearly given during training except on purpose?

Pilots ignore items in checklist 4 times out of 10? wtf

  > I have it create 2 documents, initialprompt.txt and TODO.md.

I'm using Claude Code on a large legacy monstrosity, and don't have this problem. There are problems and my flow automatically has it reviewing its own work in phased implementations, but even in the worst situations it's easy to get back on track.

This is the gist of what I've always wanted from a programming mentor, instructor, or tutor.

It can be surprisingly hard to find. Knowing that current LLMs still struggle with it perhaps helps explain why.

This matches my experience exactly, but worse than working with a human on their first day, day 100 for an AI is still like working with them on their first day. Humans have effectively infinite context windows over a long enough period of time, AIs context windows are so constrained that it's not worthwhile to invest the effort to 'teach' it like you would a junior engineer.

Memory even in a text heavy field like programming is not only text based so it’s often hard to describe for example an appropriate amount of error checking in prompt.md. Giving a person with anterograde amnesia a book of everything they know - no matter how well indexed or how searchable will not fix the lack of long term memory.

Specifically, their recommended workflow is "first ask it to read the code, then ask it to make a plan to implement your change, then tell it to execute". That sounds like the workflow you're asking for - you can read its plan and make adjustments before it writes a single line of code.

One of the weird things about using agents is that if they're doing things in a way you don't like, including things like writing code without first running the design by you, you can simply ask them to do things a different way.

[1] https://www.anthropic.com/engineering/claude-code-best-pract...

Instead of a writing a blog post about how they didn't guess how you wanted things done?

I#m wondering how some can complain about ClaudeAI: - its actually enlightening - it saves a lot of time - by intuition, i did whats written in this blog from the beginning on

YES: - sometimes the solution is rubish because i can see that its "randomly" is connecting/integrating stuff - ...but: In about 95% of the cases the output is exactly what i asked for

Most of what you're describing does apply to humans on the first day, and ais on their first day. If you aren't capturing these preferences somewhere and giving it to either a human or the ai, then why would they somehow know your preferences? For ai, the standard thats forming is you create some markdown file(s) with these so they only need to be explained once, and auto provided as context.

That said, I also value not becoming too dependent on any service which isn't free and efficient. Relying on a CNC machine when you never learned how to whittle strips me of a sense of security and power I'm not comfortable with.

That’s a you problem, not an AI problem. You have to give it small tasks broken down the same way you would break them down.