1. Prompt the agent

2. The agent gets too work

3. Review the changes

4. Repeat

This can speed up your process significantly, and the UI clearly shows the changes + some other cool features

EDIT: from reading your post again, I think you could benefit primarily from a clear UI with the adjusted code, which Cursor does very well.

1) Thoroughly define step-by-step what you deem to be the code convention/style you want to adhere to and steps on how you (it) should approach the task. Do not reference entire files like “produce it like this file”, it’s too broad. The document should include simple small examples of “Good” and “Bad” idiomatic code as you deem it. The smaller the initial step-by-step guide and code conventions the better, context is king with LLMs and you need to give it just enough context to work with but not enough it causes confusion.

2) Feed it to Opus 4.5 in planning mode and ask it to follow up with any questions or gaps and have it produce a final implementation plan.md. Review this, tweak it, remove any fluff and get it down to bare bones.

3) Run the plan.md through a fresh Agentic session and see what the output is like. Where it’s not quite correct add those clarifications and guardrails into the original plan.md and go again with step 3.

What I absolutely would NOT do is ask for fixes or changes if it does not one-shot it after the first go. I would revise plan.md to get it into a state where it gets you 99% of the way there in the first go and just do final cleanup by hand. You will bang your head against the wall attempting to guide it like you would a junior developer (at least for something like this).

Things I personally find work well.

1. Chat through with the AI first the feature you want to build. In codex using vscode I always switch to chat mode, talk through what I am trying to achieve and then once myself and the AI are in "agreement" switch to agent mode. Google's antigravity sort of does this by default and I think it's probably the correct paradigm to use.

2. Get the basics right first. It's easy for the AI to produce a load of slop, but using my experience of development I feel I am (sort of) able to guide the AI in advance in a similar way to how I would coach junior developers.

3. Get the AI to write tests first. BDD seems to work really well for AI. The multiplayer game I was building seemed to regress frequently with just unit tests alone, but when I threw cucumber into the mix things suddenly got a lot more stable.

4. Practice, the more I use AI the more I believe prompting is a skill in itself. It takes time to learn how to get the best out of an Agent.

What I love about AI is the time it gives me to create these things. I'd never been able to do this before and I find it very rewarding seeing my "work" being used by my kids and fellow nostalgia driven gamers.

Basically a good multiplier, and an assistant for mudane task, but not a replacement. Still requires the user to have good understanding about the codebase.

Writing summary changes for commit logs is amazing however, if you're required to.

The more specific and concise you are, the easier it will be for the searcher. Also, the less modification, the better, because the more you try to move away from the data in the training set, the higher the probability of errors.

I would do it like this:

1. Open the project in Zed 2. Add the Gemini CLI, Qwen code, or Claude to the agent system (use Gemini or Qwen if you want to do it for free, or Claude if you want to pay for it) 3. Ask it to correct a file (if the files are huge, it might be better to split them first) 4. Test if it works 5. If not, try feeding the file and the request to Grok or Gemini 3 Chat 6. If nothing works, do it manually

If instead you want to start something new, one-shot prompting can work pretty well, even for large tasks, if the data is in the training set. Ultimately, I see LLMs as a way to legally copy the code of other coders more than anything else

(I'm not a particularly slow typer. I can go 70-90 WPM on a typing test. However, this speed drops quickly when I need to also think about what I'm saying. Typing that fast is also kinda tiring, whereas talking/thinking at 100-120 WPM feels comfortable. In general, I think just this lowered friction makes me much more willing to fully describe what I want)

You can also ask it, "do you have any questions?" I find that saying "if you have any questions, ask me, otherwise go ahead and build this" rarely produces questions for me. However, if I say "Make a plan and ask me any questions you may have" then it usually has a few questions

I've also found a lot of success when I tell Claude Code to emulate on some specific piece of code I've previously written, either within the same project or something I've pasted in

2. Tell it you want to refactor the code to achieve goal Z. Tell it to take a look and tell you how it will approach this. Consider showing it one example refactor you've already done (before and after).

3. Ask it to refactor one thing (only) and let you look at what it did.

4. Course correct if it didn't do the right thing.

5 Repeat.

I would open a chat and refactor the template together with cursor: I would tell it what I want and if I don’t like something, I would help it to understand what I like and why. Do this for one route and when you are ready, ask cursor to write a rules file based on the current chat that includes the examples that you wanted to change and some rationale as to why you wanted it that way.

Then in the next route, you can basically just say refactor and that’s it. Whenever you find something that you don’t like, tell it and remind cursor to also update the rules file.

I've had very good results with Claude Code using this workflow.

put an example in the prompt: this was the original Django file and this is the rewritten in SvelteKit version.

the ask it to convert another file using the example as a template.

you will need to add additional rules for stuff not covered by the example, after 2-3 conversions you'll have the most important rules.

or maybe fix a bad try of the agent and add it as a second example

Use mind altering drugs. Give yourself arbitrary artificial constraints.

Try using it in as many different ridiculous ways you can. I am getting the feeling you are only trying one method.

> I've had a fairly steady process for doing this: look at each route defined in Django, build out my `+page.server.ts`, and then split each major section of the page into a Svelte component with a matching Storybook story. It takes a lot of time to do this, since I have to ensure I'm not just copying the template but rather recreating it in a more idiomatic style.

Relinquish control.

Also, if you have very particular ways of doing things, give it samples of before and after (your fixed output) and why. You can use multishot prompting to train it to get the output you want. Have it machine check the generated output.

> Simple prompting just isn't able to get AI's code quality within 90%

Would simple instructions to a person work? Esp a person trained on everything in the universe? LLMs are clay, you have to mold them into something useful before you can use them.

1. If there is anything Claude tends to repeatedly get wrong, not understand, or spend lots of tokens on, put it in your CLAUDE.md. Claude automatically reads this file and it’s a great way to avoid repeating yourself. I add to my team’s CLAUDE.md multiple times a week.

2. Use Plan mode (press shift-tab 2x). Go back and forth with Claude until you like the plan before you let Claude execute. This easily 2-3x’s results for harder tasks.

3. Give the model a way to check its work. For svelte, consider using the Puppeteer MCP server and tell Claude to check its work in the browser. This is another 2-3x.

4. Use Opus 4.5. It’s a step change from Sonnet 4.5 and earlier models.

Hope that helps!

Tale as old as time. The expert gets promoted to manager, and the replacement worker can’t deliver even 90% of what the manager used to. Often more like 30% at first, because even if they’re good, they lack years of context.

AI doesn’t change that. You still have to figure out how to get 5 workers who can do 30-70% of what you can do, to get more than 100% of your output.

There are two paths:

1. Externalized speed: be a great manager, accept a surface level understanding, delegate aggressively, optimize for output

2. Internalized speed: be a great individual contributor, build a deep, precise mental model, build correct guardrails and convention (because you understand the problem) and protect those boundaries ruthlessly, optimize for future change, move fast because there are fewer surprises

Only 1 is well suited for agent-like AI building. If 2 is you, you’re probably better off chatting to understand and build it yourself (mostly).

At least early on. Later, if you nail 2 and have a strong convention for AI to follow, I suspect you may be able to go faster. But it’s like building the railroad tracks before other people can use them to transport more efficiently.

Django itself is a great example of building a good convention. It’s just Python but it’s a set of rules everyone can follow. Even then, path 2 looks more like you building out the skeleton and scaffolding. You define how you structure Django apps in the project, how you handle cross-app concerns, like are you going to allow cross-app foreign keys in your models? Are you going to use newer features like generated fields (that tend to cause more obscure error messages in my experience)?

Here’s how I think of it. If I’m building a Django project, the settings.py file is going to be a clean masterpiece. There are specific reasons I’m going to put things in the same app, or separate apps. As soon as someone submits a PR that craps all over the convention I’ve laid out, I’m rejecting aggressively. If we’ve built the railroad tracks, and the next person decides the next set of tracks can use balsa wood for the railroad ties, you can’t accept that.

But generally people let their agent make whatever change it makes and then wonder why trains are flying off the tracks.

https://open.substack.com/pub/sleuthdiaries/p/guide-to-effec...

1. Define the work.

2. When working in a legacy code base provide good examples of where we want to go with the migration and the expectation of the outcome.

3. Tell it about what support tools you have, lint, build, tests, etc.

4. Select a very specific scenario to modify first and have it write tests for the scenario.

5. Manually read and tweak the tests, ensure they’re testing what you want, and they cover all you require. The tests help guardrail the actual code changes.

6. Depending upon how full the context is, I may create a new chat and then pull in the test, the defined work, and any related files and ask it to implement based upon the data provided.

This general approach has worked well for most situations so far. I’m positive it could be improved so any suggestions are welcome.

I still find chat interface generally more useful than coding assistant. It allows you to think and discuss higher level about architecture and ideas before jumping into implementation. The feedback loop is way faster because it is higher level and it doesn't have to run through your source tree to answer a question. You can have a high ROI discussion of ideas, architecture,algorithms, and code, before committing to anything. I still do most of my work copying and pasting from the chat interface.

Agents are nice when you have a very specific idea in mind, but I'm not yet hugely fond of them otherwise. IME the feedback loop is too long, they often do things badly, and they are overly confident in their oytput, encouraging cursory reviews and commits of hacked-together work. Sometimes I'll give it an ambitious task just in the off chance that it'll succeed, but with the understanding that if it doesn't get it right the first time, I'll either throw it away completely, or just keep whatever pieces it got right and pitch the rest; it almost never gets it right the second time if it's already started on an ugly approach.

But the main thing is to start small. Beyond one-shotting prototypes, don't expect it to change everything overnight. Focus on the little improvements, don't skip design, and don't sacrifice quality! Over time, these things will add up, and the tools will get better too. A 10% improvement every month gets to be a 10x improvement in (math...). And you'll be a lot better positioned than those who tried to jump onto the 10x train too fast because you'll not have skipped any steps.

But I can't even shit on Claude AI, because I used it to rewrite part of the tests, and analyse the solution to fix the race condition (and how to test it).

It's a good tool, but in the last few weeks I've been more and more mad about it.

Anyway. I use it to generate a shell. No logic inside, just data models, and functions prototypes. That help with my inability to start something new. Then I use it to write easy functions. Helpers I know I'll need. Then I try to tie everything together. I never hesitate to stop Claude and write specific stuff myself, add a new prototype/function, or delete code. I restart the context often (Opus is less bad about it, but still). Then I ask it about easy refactoring or library that would simplify the code. Ask for multiple solutions each time.